Solution Architecture - Technology Architecture

Thank you for reading my latest article here.

Here at LinkedIn, I regularly write about data architecture, Business Architectures Business Concepts and technology trends. To read my future articles simply join my Newsletter on LinkedIn or follow me on 'Rohan Rekhi | LinkedIn

In the last article in my Solution Architecture series, I touched upon various aspects of Enterprise Application Architecture. Today Let's talk about various facets of Technology Architecture.

Conceptual Architecture

The conceptual view is used to show inter system relationships, dependencies, and new architectural components that will be part of the solution.? When capturing this view, keep it very high level, as it relates to the architecture (this will vary depending on the program/project/effort).? Teams have, in some cases, decided to include additional context to assist in the communication when showing high level components and dependencies.? However, inclusion of individual Use Cases, is again another avenue to clearly communicate the intent of the solution

Current State & Target Views

The Current state view should be used to clearly communicate the state the architecture as it is today and then showing the "what is changing" in the Target state.? The Target state changes may be in; technologies used, services, or even a new data store being introduced.??Whatever the Target changes are highlight them by using the appropriate color as defined in the legend, so it clearly stands out.??

In some cases, showing the alignment to the Blueprint or Technology Strategy, may help communicate the solution intent.?

Decommissioning

In the case of an acquisition in which application function is being migrated, the "Current State" should depict the existing systems that will receive the migrated functionality. The "Target State," diagram should depict the changes to the "Current State" as a result of the migration.

What should It Capture?

• A current state (AS-IS) high level picture?(birds eye view)
• A Target state high level expansion of what changed
• 3rd party usage (i.e. inclusion of vendor technology solutions)
• Major Dependencies from (no deeper than L2 of the Enterprise Capability Models.)
• Region (i.e. Data Centers, Cloud, Hybrid)
• Additional diagram to conceptually show the high-level data construct for the application

What should It not Capture?

• Business process
• Detailed API information
• Specific technology stack products and versions

** Don't use vendor diagrams as your diagrams as they do not show how this will be used and implemented

Giving below some Reference pictures and templates to help with this.

Conceptual Diagram - Legend

Conceptual Diagram - Template

Example Technology Context View - Current (incl. Blueprint)

Example Technology Context View - Target (incl. Blueprint)

Example New Technology project with support of Blueprint

Use Case Diagram Template

Additional Views

At times there is a need for additional views to convey the message and/or significant design decisions, which is fine.? However, use that standard template for consistency and ease of understanding.? Cautionary, to many diagrams may cause confusion, you may want to review what has been done, to ensure completeness.? Keep it simple and easy to follow.

Critical Risks & Assumptions

This section represents significant architectural topics which?summarize the solution including key architectural or design decisions made or outstanding.? Generally, these topics will include interfaces, technology or vendor use/reuse, security, pattern use, non-functional decisions (e.g. use of shared environments), assumptions and deviations from target technology strategy.? Some risks to the quality attributes of a solution are accepted in a design in order to meet business needs (cost, risk, value).? This section should capture those risks which are being accepted and provide a rationale for accepting them.

These topics should NOT include incremental changes, minor feature additions, continued use of existing patterns.? ?In addition, it is recommended to including these items Conceptual diagrams.??

?

Exceptions:??

This section identifies any previous exceptions granted and any New Exceptions being sought.? ?Either way, they are to register in Sirus as Self-Identified Findings

Non-Functional Requirements (NFR)?

The NFR's are in place to define how the system is supposed to operate, whereas the functional requirements define what the system is supposed to do.? The NFR's define the boundaries or constraints of the solution.? By understanding how you expect this solution to perform under any condition, will in turn provide a stable solution for the consumers.? ?In many cases, the focus is primarily on the functional requirements, and the NFR's are an afterthought, until degradation or failure occurs.??

This section is focused on the "...ileitis". Using the provided expansion reference in the SAD, determine what your expected Availability is and Class of Service.? Do this in perspective and understanding of the full technology stack and location.? If compensating requirements for the solution is required, be sure to call those out in the Deployment Diagram.? If Availability is high, and Class of Service is high this will have an impact on the cost of the solution.? Be sure to capture these additional costs in the Cost Section of the SAD.

Each question listed is specifically designed to capture Disaster Recovery, Day 2 operations and compliance.? These should all be embedded into the appropriate diagrams, to show how the architecture will support each.? Assuming these will just be handled after release, is never a good idea.

Operational readiness questions:? This section is to help ensure the solution being presented has captured Day 2 operational concerns.? As mentioned before, if these things are not thought about prior to engineering it could have consequences for Enterprise and it's clients

For Reference:? Availability Matrix

For Reference:? Class of Service

The Class of Service (CoS) describes the level of reliability, performance, redundancy and fault tolerance within a given zone. Applications that run on Class A+ or Class A deliver the highest level of redundancy and host the most critical applications. The highest level of resiliency is delivered by the highest CoS, and is meant to support the most critical applications. The level of redundancy and resiliency decreases for lower CoS’, as shown below:

*** Understand what the technology is being deployed on and the requirements it needs to provide the performance and resiliency as expected?

In next article, I will zoom into few more aspects of Technology Architecture.

#technologyarchitecture #rto #rpo #reliability #performance #resiliancy #contextdiagram

To stay up to date with my latest articles in, make sure to subscribe to my newsletter follow me on LinkedIn, and if you or anyone in your network is interested in taking a deeper dive into some of these topics or looking for help with your initiatives and programs, please feel free to reach out to me. For wider reach please share.

You can also follow me on Medium and Subscribe to my articles there.