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
- Scope & Responsibilities
- External Dependencies
- 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:
- USER to be fixed. The user (actor) using the product becomes the center all brainstorming
- Take the product which was the blackbox in the context diagram
- Break it into layers that have specific objective
- Eg: Layer with UI objective, only consists of projects technically to produce the UI
- The output of the Informational view,viz. Information categories + Identifiers + Mappings, place it in Business Logic Layer as it is.
- Each layer technically can multiple projects in multiple frameworks
- Run usecases captured in the context view to finalize the modules / sub-systems in the tiers.
- Highlight the technology / frameworks used in each project of the layers
- Include data flow and call flow
- Identify if model is linear or reactive
The end output should look something similar to the diagram below.
STAGE 2:
- Use the context diagram that addresses external dependencies
- First draw a box around the existing tiered architecture, scoping the product as a system.
- Capture external dependencies with its flow
- 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.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
the changes from Github on your local machine
