Solution architecture design
Definition
Solution architecture is a practice of defining and describing an architecture of a system delivered in the context of a specific solution and as such, it may encompass description of an entire system or only its specific parts.
Solution architecture is one of the key methods, by which enterprise architecture delivers value to the organization. Solution architecture activities take place during solution ideation, solution design, and solution implementation. During ideation, solution architecture establishes the complete business context for the solution and defines the vision and requirements for the solution. During design, solution architecture elaborates potential options, which may include RFIs, RFPs, or prototype development. It selects the most optimal option and develops the roadmap for the selected solution. During implementation, solution architecture communicates the architecture to the stakeholders and guides the implementation team.
Download the solution architecture overview.
How to do solution architecture?
A very good way to do this is to put yourself in the stakeholders’ shoes. There are several types of stakeholders in each project who have their own views and their own concerns. This is the biggest difference between the design and the architecture. A designer thinks very technically while an architect can think broadly and can look at a problem from different views. Designers usually make a huge mistake: they put everything in one document. Where I am doing a solution architecture job now, I was given a 21-mega-byte MS Word document which included everything, from requirements to detailed class and database design. Such a document is very unlikely to be understandable by the stakeholders and very hard to use by developers. I reckon that this happens because firstly designers don’t consider the separation of stakeholders and developers' concerns. Second, because it’s easier to write down everything in a document. But I have to say that this is wrong as SAD and design documents (for example, TSD) are built for different purposes and for different audiences (and in different phases if you are following a phase-based methodology such as RUP). If you put everything in a document, it’s like you are cooking dinner and you put the ingredients along with the utensils in a pot and boil them!!
A very good approach for looking at the problem from the stakeholder’s point of view is the 4+1 approach. At this model, scenarios are the base and we look at them from a logical view (what are the building blocks of the system), Process view (processes such as asynchronous operations), Development (aka Implementation) view and Physical (aka Deployment) view. There are also optional views such as Data View that you can use if you need to. Some of the views are technical and some of them are not, however they must match and there must be consistency in the architecture so that technical views can cover business views (for example, demonstration of a business process with a UML Activity Diagram or State Diagram).
I believe that each software project is like a spectrum that each stakeholder sees a limited part of it. The role of an architect is to see the entire spectrum. A good approach to do so is to include a business vision (this might not be a good term) in your SAD. It can be a bulleted list, a diagram, or both, which shows what the application looks like from a business perspective. Label each part of the business vision with a letter or a number. Then add an architectural overview and then map it to the items of business vision indicating which part of the architecture is meant to address which part of the business vision.
In a nutshell, Architecture is early design decisions, it is not the design.
What to put into SAD?
There are a whole bunch of SAD templates on the Internet, such as the template offered by RUP. However, the following items seem to be necessary for each architecture document:
- Introduction: This can include Purpose, Glossary, Background of the project, Assumptions, References, and so on. You should explain what kind of methodology you are following. This will avoid lots of debates.
It is very important to clear the scope of the document. Without a clear scope not only you will never know that when you are finished, but you also won’t be able to convince the stakeholder that the architecture is comprehensive enough and addresses all their needs.
- Architectural goals and constraints: This can include the goals, as well as your business and architectural visions. Also, explain the constraints (for example, if the business has decided to develop the software system with Microsoft .NET, it is a constraint). Mention the components (or modules) of the system when you mention your architectural vision. For example, say that it will include Identity Management, Reporting, and so on. Explain your strategy to address them. As this section is intended to help the business people to understand your architecture, try to include clear and well-organized diagrams.
A very important item that you want to mention is the architectural principles that you are following. This is even more important when the client organization maintains a set of architectural principles.
- Quality of service requirements: Quality of service requirements addresses the quality attributes of the system, such as performance, scalability, security, and so on. These items must not be mentioned in a technical language and must not contain any details (for example, the usage of Microsoft Enterprise Library 5).
- Use Case View: Views basically come from the 4+1 model so if you follow a different model you might not have it. However, it is very important that you detect key scenarios and mention them in a high-level. Again, diagrams help.
- Logical View: The logical view demonstrates the logical decomposition of the system, such as packages that build it. It will help the business people and the designers to understand the system better.
- Process View: Use activity diagrams as well as state diagrams (if necessary) to explain the key processes of the system (for example, the process of approving a leave request).
- Deployment View: The deployment view demonstrates how the system will work in a real production environment. Put two types of diagrams: one (normal) human-understandable diagram, such a Visio Diagram that shows the network, firewall, application server, database, and so on. Also, a UML deployment diagram that demonstrates the nodes and dependencies. This will again help the business and technical people to have the same understanding of the physical structure of the system.
- Implementation View: This part is the most interesting section of the techies. I like to include the implementation options (for example, Java and .NET) and provide a list of pros and cons for each of them. Again, technical pros and cons don’t make much sense to business people. They are mostly interested in Cost of Ownership and availability of the resources and so on. If you suggest technology or if it has already been selected, list the products and services needed in a production environment. It’ll be good to include a very high-level diagram of the system.
Also, I would like to explain the architectural patterns that I’m going to use. If you are including this section in the Implementation View, explain them enough so that a business person can quite understand what that pattern is for. For instance, if you are using Lazy Loading patter, explain what problem it solves and why you are using it.
Needless to say that you have to also decide which kind of Architecture style you are suggesting, such as 3-Tier and N-Tier, Client-Server, and so on. Once you have declared that, explain the components of the system (Layers, Tiers, and their relationships) by diagrams.
This part also must include your implementation strategy for addressing the Quality of Service Requirements, such as how will you address scaling out.
- Data View: If the application is data-centric, explain the overall solution of data management (never put a database design in this part), your backup and restore strategy as well as a disaster recovery strategy.
Be iterative
It is suggested that the architecture (and as result the Software Architecture Document) be developed through two or more iterations. It’s impossible to build a comprehensive architecture document in one iteration as not only Architecture has an impact on the requirements, but also architecture begins in an early stage and many of the scenarios are likely to change.
How to prove that?
Now, after doing lots of endeavors, you have prepared your SAD, how will you prove it to the stakeholders? I assume that many of business people do not have any idea about the content and structure of an SAD and the amount of information that you must include in it.
A good approach is to prepare a presentation about the mission of the system, scope, goals, visions, and your approach. Invite the stakeholders to a meeting and present the architecture to them and explain how the architecture covers their business needs. If they are not satisfied, your architecture is very likely to be incomplete.