The eternal loop of changing trends-then-back to our roots

We see changing trends, update our way of living, term them as modernization, just to realise that we keep going back  to our roots each time to find solace.

For example, yogic poses if one observes were an integral part of a daily routine like squatting, namaskar, eating food sitting in sukhasana; to see things replaced by its sedentary counterparts in the name of modernized living.

Now decades later, yoga becomes a trend, the same activities are advised to us by trained counsellors.

Common sense became complicated, complex situation and thinking became common trend. Now one needs experts to learn things that were  once common sense.
The trend of home remedies, natural healing, mantra yoga, color and sound therapy which was followed since ages has become a movement.

Thumb impressions were the most authentic identity verification systems since ages, with modernization they got replaced with signatures, later realising that it could be copied, after which came digital signatures  and now biometric identities using fingerprints and retina checks 🙂

You  see, we keep looping and eventually come back to our roots.

Before we blindly adopt a trend in the name of modernization, let's think, analyse to see  if it is really necessary to be part of this bandwagon.

Worth giving it a thought I hope.

Decoding the Development Perspective in Architecture and Solutioning

Visualizing Architecture

Developing an architecture is all about  viewing a blackbox which  is your product from different Perspectives be it Informational, Context, Operational, Functional, Development, Deployment and so on. Unfortunately, one has to open doors of creativity beyond the scope of textbook architecture and solutions. Design thinking is an essential trait here.

Based on my experience on architecting and developing different products or training around a 100  budding enterprise architects,  an architect would enter a product that could be at various stages

1. A new Product

2. Enhancements to a Product that alter the flow and impact on the rest of the system

3. Migration cases for a product, whether to upgrade it to a newer tech-stack, a deployment environment, devops automation, data migration

For each type of system, a specific architectural model (eg: 4+1 architectural model is normally relevant in most products) and collection of allied perspectives (views) work out.

Development as a view for solutioning comes a little later, if the information, its flow and contexts with scope, boundaries, external dependencies and a high-level business usecases are drawn out.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

A lot of modelling and solutioning happens even before we talk design patterns actually. Design Patterns with UML as a  modelling technique can come at Low Level Design using tools like EA or Visio. These tools translate UML at the LLD level offering certain amount of code generation and templating as per design.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

High Level Design uses architectural modelling techniques solutioning information, flow and usecases using Architectural views and viewpoints.

Hence, the Development as a perspective comes at high level design and makes sense only when as an architect solutions the informational view its flow and contexts, scopes.

This is my take on an example solutioning with the informational view for a system

Assuming we have the contexts solutioned in terms of

1. Scope & Responsibilities
2. External Dependencies
3. Frameworks and resources etc.

the product could be solutioned using Top-to-Down through the Development perspective

=======================================================================

ARCHITECTURAL VIEW: DEVELOPMENT

Is all about the flow of the product's though objective-based tiers. We could start with taking the outputs of the previous architecture views considering the product as the blackbox, broken into tiers identifying 

• call flows, 
• data flows
• Flow tendency: linear, non-linear or reactive.

Here we do not confuse this flow with how the product would be placed in the production environment.

Hence keywords like flow, tier-ed architectures, frameworks, process, paradigms keeping the user (actor) using your product become important here.

Keywords like servers, IP addresses, topology, balancers, payloads, horizontal / vertical scaling should not be addressed here. These keywords become important for deployment architecture and its solutioning.

I mention these explicitly as I do get asked questions, so is it N-Tier or Microservices architecture? The comparison in the question is itself flawed.

One should understand that N-Tier is a development architecture, which is different from a deployment architecture. Microservices is taken into consideration where independent loosely coupled subsystems are managed and deployed separately. But this aspect does seem to affect the tiers of development to a certain extent though.

SO, how do you solution it without getting confused between development flows which could vary from deployment flows?

We can use a simple principle where multiple entities need a discovery engine. In this case, If a layer becomes polyglotic (multiple projects in multiple frameworks or languages), we need a common translator / management layer

CASE: Presentation Tier shown in this diagram becomes polyglottic.

SOLUTION:  Introduce Service Layer for common mode of communication to be in sync with the layers below. All projects  in the tier communicate via this service layer using Service Contracts of Service Oriented Architecture (SOA)

CASE: Service layer becomes polyglotic, 

SOLUTION: introduce a service discovery layer (Application Gateway). This is Service Discovery  Pattern at a high level.

Once these principles are clear, we can begin solutioning the product through the Development perspective

Input for Solutioning Development View: Context View Diagrams

  - Scope + Responsibility

- Tech-stack(s)

- Business usecases

- External Dependencies

Expected Deliverable: Dev Architecture Diagram including everything from previous views

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

STAGE 1:

1. USER to be fixed. The user (actor) using the product becomes the center all brainstorming
2. Take the product which was the blackbox in the context diagram
3. Break it into layers that have specific objective
• Eg: Layer with UI objective, only consists of projects technically to produce the UI
4. The output of the Informational view,viz. Information categories + Identifiers + Mappings, place it in Business Logic Layer as it is.
5. Each layer technically can multiple projects in multiple frameworks
6. Run usecases captured in the context view to finalize the modules / sub-systems in the tiers.
7. Highlight the technology / frameworks used in each project of the layers
8. Include data flow and call flow
9. Identify if model is linear or reactive

The end output should look something similar to the diagram below.

STAGE 2:

1. Use the context diagram that addresses external dependencies
2. First draw a box around the existing tiered architecture, scoping the product as a system.
3. Capture external dependencies with its flow
4. Identify if model is linear or reactive

The end output should look similar to the diagram below

STAGE 3:

At this stage, it makes sense to identify cross-cutting concerns that cut accross the tiers of the product architecture at Stage 2.

Eg: Cross-cutting concerns like Non-functional requirements (NFRs), SDLC / TDLC / DevOps / Logging solutoins / Monitoring solutions etc

The output at Stage 3 should look similar to the diagram below

This completes the solutioning for the Development view of the product.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Finally,

Every view should be analyzed for Trade-offs and Design Smells to zero-in on any anti-patterns and design debts that could be possible.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Architecture Perspective: Solutioning Informational models

Usecase: A new product 

Approach: Top to Down 

Source of Information: Market Research, Raw information

Perspective of Architecture Analysis: Informational

Let's assume we have captured raw information for a given problem, through the Market research.

At the most primitive level, categorize them into information categories providing relations and mappings to other information categories, shown below.

At this stage, we could come up with possible information models like

Static Models: Information schema doesn't change frequently

Dynamic Models: Information schema keeps changing frequently. Think of self-learning systems using

                              ML and AI.

Volumetric models: Operating of volume chunks of information for example to render graphical data in 

                                 3D formats

Metadata models: Operating on information that needs to be presented to your query audience whether

                              in the form of exploration (search), analytics or reports. For example Tag Clouds,

                              used to depict keyword metadata for exploration search, or the visualize free-form text.

Depending on the kind of model, specific solutioning could be done.

For example, we have a static model, with the evolution perspective that could cause changes in architecture, hence solutioning information view and flow for the following usecase. 

Example Enhancement to an existing QnA system

Eg: QNA system consisting of a single question with unknown number of options, and possibility of more than one correct answers supporting descriptive answers. A common algorithm that renders this data dynamically in graphical format

Initial Possible schema of information

Question | Option 1 | Option 2 | ...? | Answer 1,2,... ?  | UI markup | Settings <*to*>?! === PROBLEM

Let's think of solutions here.

Type: Static Model

Perspective: Evolution

Principle Applied: Open-Close Design Principle, open for extension

Solutioning:

CASE: Part of the system enhancement introduces frequently changing information

Proposed / Existing Storage Model: RDBMS SQL

Technology Vendors: MS SQL Server, Oracle, DB2, mySql

ANS 1 : Pivoting. Create pivot structures such that the dynamic schema which was to be represented as columns, now is represented as rows.

Pivot as a solution

Question | Option | Is Answer | UI markup | Settings

Q1           | Op1     | No            | </>             | {setting:value,...}

Q1           | Op2     | No            | </>             | {setting:value,...}

Q1           | Op3     | Yes           | </>             | {setting:value,...}

ANS 2:  Extension Tables, based on the principle of inheritance /composition / aggregation translating to Primary Key - Foreign key relationships, that would create two or more structures in the model depending on if the extension calls for One-to-One, One-to-Many, Many-to-Many relationship

ANS3: Keeping the schema constant, and the RDBMS approach, suggest extension in algorithm that processes the QNA data.

ANS 3.1: Modifying data added in the schema, without change in existing schema, using json / xml data as row data. Suggested "extension" through extension code contracts not refactoring in existing processing algorithm.

Question | Answer

Q1           | options: [{option:'Op1', 

                        IsAnswer:'No', 

                       UIMarkup: '</>',

                       settings: {setting1:'value', setting2:'value2',...}

                     }]

ANS 3.2: Modifying data added in the schema, without change in existing schema, using links to json/xml templates / data. This solution works well for content management systems.

QuestionBank | Answer

QB1                | link://jsondoc

~~~ jsondoc on Server

[ {question: 'Q1',

     options: [{option:'Op1', 

                       IsAnswer:'No', 

                       UIMarkup: '</>',

                       settings: {setting1:'value', setting2:'value2',...}

                     }],

              {question: 'Q2',

                 options: [{option:'Op1', 

                       IsAnswer:'No', 

                       UIMarkup: '</>',

                       settings: {setting1:'value', setting2:'value2',...}

                     }],

                  ...

]

 

CASE: Change Storage Model Type, convert to self-learning system

Type: Dynamic Model, Volumetric Model, Metadata Model

Storage Model: No-SQL DB

Technology Vendors: MongoDB, Cosmos DB, ElasticDBs, Bigdata

ANS : Extending existing structures to incorporate Json / xml data

[ {question: 'Q1',

     options: [{option:'Op1', 

                       IsAnswer:'No', 

                       UIMarkup: '</>',

                       settings: {setting1:'value', setting2:'value2',...}

                     }]

]

          

OR

 

<Question title='Q1'>

   <Options>

         <Option title='op1'>

            <IsAnswer>No</IsAnswer>

            <UIMarkup>&lt;lasjdf&gt;<UIMarkup>

            <Settings>

                  <Setting title='setting1'>value</Setting>

                  <Setting title='setting2'>value</Setting>

             <Settings>

         </Option>

   </Options>

</Question>

CASE: This is a system for a small set of users supporting upto 100 question banks

Technology Vendors: Access, CSVs, Flat File DBs, Xml Dbs, Excel Dbs, Json file dbs