Overview
A Solutions Architecture aims to address specific problems and requirements, usually through the design of specific information systems or applications, and typically accommodates many different audiences as it addresses direct business and technical concerns without dropping down to the nuts and bolts of the software architecture.
Note, that I provided a link to Wikipedia’s definition, but I have expanded that definition to be more specific regarding its intended audiences and provided level of detail.
It should be noted, that my intention is not to advocate a Solutions Architecture as another tedious task in the software development process, but to provide a software architecture practice that is
- practical and useful by a broad audience,
- flexible in its composition, and
- well understood, especially by business and technical folks.
Many times, I’ve seen the impedance mismatch, e.g., technical jargon, business jargon, expectations, communications, etc…, go unnoticed, or ignored, far too long. A Solutions Architecture provides a proven strategy to effectively guide architecting software systems.
In this post, I delve into the concept of Current State Architecture and Future State Architecture and how identifying these help guide us to the ultimate goal, the Solutions Architecture. If it is discerned through the Solutions Architecture, that the current state architecture is unacceptable, work can begin on creating the future state software architecture.
Please click on the link if you are looking for information on helping you determine
“When is it time to revisit my current software architecture?” - another post by B. Buikema
Solutions Architecture
A Solutions Architecture is typically written as slides, e.g., a powerpoint presentation, not straight-up, highly-textual, documentation. It is comprised of content and diagrams that provide a 360 degree view of a software architecture as a total solution. Details such as algorithms, code snippets, detailed designs (i.e., UML class, sequence, state, etc…) are typically omitted.
NOTE: Companies typically have business and engineering folks whose tolerance for documentation is either small or large, and this is driven by the company culture. I recommend that the Solution Architecture is kept as tight and to-the-point as possible to match this tolerance. However, make sure that any items deemed important by folks are, in fact, included to ensure buy-in by all parties. I will also identify those items I believe are absolutely necessary.
Typical items found in a Solutions Architecture are
- Statement of Work (SOW)
- Goals
- Considerations
- Use Cases
- Conceptual Architecture
- Logical Architecture
- Security Architecture
- Information Architecture
- Physical Architecture
- Network Operations Center (NOC) Requirements
- CURRENT STATE: Discussion of Business and Technical Gaps
- FUTURE STATE: Solutions to Business and Technical Gaps
- Non-Functional Requirements (NFR’s)
- Engineering Development Staffing Requirements (e.g., roles/skills)
- NOC Staffing Requirements (e.g., roles/skills)
- Operations Staffing Requirements (e.g., roles/skills)
SOW
This is the statement of work and is usually a paragraph or two describing the intent of the system or application.
Goals
Provide key goals important to both the business and engineering.
Considerations
Key considerations include, but are not limited to
- targeted business markets/consumers
- targeted technologies/platforms
- keeping legacy features (or not)
- short and/or long-term business plans
- short and/or long-term technical plans
- user privacy policies
- sensitivity to cost and time
Use Cases
These are typically high-level and include all major actors and relevant use cases. Include all roles and responsibilities, and, if you’re unsure, it is better to include than exclude.
Conceptual Architecture
This is the loosest of the architecture diagrams, but can set the stage for understanding the other architectural views.
The Conceptual Architecture provides a view depicting high-level, conceptual systems, subsystems, and/or applications, and their importance to the actors and use cases. This is commonly just arrows from the actors to a high-level component and stating the high-level use case it represents. There are typically no hard and fast rules in creating a Conceptual Architecture, but it is useful when discussing the high-level architecture.
Logical Architecture
The Logical Architecture depicts the logical view of the system or application and commonly identifies the main software components as follows:
- systems
- subsystems
- applications
- servers (such as email and web servers)
- services
A Logical Architecture need not concern with the attributes of the physical environment.
Security Architecture
The Security Architecture typically includes details on
- data in flight
- data at rest
- authentication and authorization
Information Architecture
The Information Architecture may include core data schemas, data flows, transactions, workflows, etc,… NOTE: It’s advisable not to delve to deep on these, keep them at high-level to satisfy the use cases and come of the other architecture diagrams.
Physical Architecture
This depicts a diagram(s) the physical environment(s) of the components the system or application is hosted on. Server nodes, clusters, firewalls, databases, are just some of the components identified. Details to the physical hosting and interfacing are well established.
NOC Requirements
NOC requires various deployment and topological network diagrams for each environment they maintain to host the system or application. This usually includes Production, Testing, Staging, and Development.
Discussion of Business and Technical Gaps
This is relevant to the Current State Architecture only (see below).
The business gaps can commonly be captured in a table format, identifying the feature, the problem/challenge, the folks affected, and the priority of importance.
The technical gaps are similar, but describe the technical difficulty, of course.
You can also see how useful this becomes when you map the two together to form an end-to-end understanding of why the business problems/challenges occur.
Solutions to Business and Technical Gaps
This is relevant to the Future State Architecture only (see below).
Taking the details discussed in the Discussion of Business and Technical Gaps, each item should be identified and given a description of the solution along with a measurement of how well the solution solve the actual problem/challenge,
For example, you can adopt 0 – 5, where
- 0 represents no solution,
- 1 represents 20% solved and
- 5 represents 100% solved.
NFR’s
NFR’s typically include details that are not always given to engineering, but are critical to operations
- availability
- disaster recovery
- performance and scaleability
- elasticity
- instrumentation
- data backup and retention
Representing a Solutions Architecture Through States
In order to effectively compare and contrast different solutions architectures, it is necessary to provide a baseline, also known as the current state architecture. And new solutions known as the future state architecture. This nicely allows us to describe the state of the union as we see it today, and optional solutions that are possibilities for the future.
Current State Architecture
Simply stated, this is the current state of the software architecture. In addition to the architectural specifics, the gaps in both business and technical are included.
In addition to the typical items listed above, the following are specific to the current state:
- Business Gaps in the Current Architecture
- Technical Gaps in the Current Architecture
The exercise in creating the Current State Architecture is rewarding as the results make it much easier to justify arguments made in the past that were harder to prove.
Future State Architecture
This is the future state software architecture. In addition to the architectural specifics, the solution to the gaps in both business and technical are included. Also, technology research, proof-of-concept, and technology selection details are provided.
In addition to the typical items listed above, the following are specific to the future state:
- Technology Research, Proof-of-Concept, and Selection
- Solving Business Gaps in the Current Architecture
- Solving Technical Gaps in the Current Architecture
Recommendations
I recommend the following, at a minimum, as I strongly believe they are core to defining a Solutions Architecture:
- Statement of Work (SOW)
- Goals
- Use Cases
- Logical Architecture
- Security Architecture
- Information Architecture
- Physical Architecture
- NOC Requirements
- Non-Functional Requirements (NFR’s)
- CURRENT STATE: Discussion of Business and Technical Gaps
- FUTURE STATE: Solutions to Business and Technical Gaps
The actual details for each of the above can be brief, as long as any details that can affect the final decision are surfaced enough for clear discussion. For example, identifying high-level data schema(s) are suffice for the Information Architecture as long as key data stores (e.g., databases) are present in the diagram.
Using the Current and Future State Architectures to Identify the Winning Solutions Architecture
This is where the rubber hits the road and the real decisions can be made.
Now all of the facts are within easy reach to do comparisons and open up discussions that can include both business and technical folks. This proves fruitful for a company’s future, as the business can share its short and long-term needs and engineering can understand its limitations, if any, and together well-informed decisions can now be made going forward.
Moving Forward
Coming up in the near future, I will discuss using the Solutions Architecture to drive creation of the Software Architecture.
Please click on the link below if you are looking for information on helping you determine
“When is it time to revisit my current software architecture?” - another post by B. Buikema
I also have many other posts regarding
- software architecture
- mobile (Android) development
- enterprise development
- design patterns
- and much more…
so look me up.
See you soon!


