The software architecture design process

Early attempts to capture and explain software architecture of a system were imprecise and disorganized – often characterized by a set of box-and-line diagrams. During the 1990’s there was a concentrated effort to define and codify fundamental aspects of the discipline. Initial sets of design patterns, styles, best practices, description languages, and formal logic were developed during that time. The software architecture discipline is centered on the idea of reducing complexity through abstraction and separation of concerns.
To bring a software architecture user’s perspective into the software architecture, it can be said that software architecture gives the direction to take steps and do the tasks involved in each such user’s speciality area and interest e.g. the stake holders of software systems, the software developer, the software system operational support group, the software maintenance specialists, the deployer, the tester and also the business end user. In this sense software architecture is really the amalgamation of the multiple perspectives a system always embodies.
Architectural design occurs immediately after requirements analysis and before detailed design. An architectural design is concerned with structural, functional, and behavioral issues of a system by modeling the problem and the outline solution. Structural issues that influence design decisions include organization and control structures; communication, synchronization, and data access protocols; physical distribution of functions of design elements; future developments, etc.

The software architecting process can be described through the following steps:

Requirements from an architectural point of view: You take the system requirements and abstract the ones that are relevant from the view of an architecture design. So, with business objectives, you can determine that the architecture being planned is capable of supporting the desired architecture. The requirements in turn drive the generation of use cases, and it is these use cases that determine whether the architecture meets them.

Definition of the architecture specification: This is the phase that ultimately results in the documentation of the architecture design. At the end, you get a document that details the models and views, the assumptions, explanations, different alternatives viewed and a reasoning for the one selected, references, etc. As a part of this process, you take the following steps.
1. Architecture vision: This is extremely important, since it will guide the rest of the design process. During this step, you will have to spend time on research, evaluating many alternatives, looking at existing architectures, and then finally deciding on the architecture vision that you are sure will meet your needs.
2. Conceptual architecture: The system is decomposed into components and the responsibilities of each component, and interconnections between components are identified. The intent of the conceptual architecture is to direct attention at an appropriate decomposition of the system without delving into the details of interface specification and type information. Moreover, it provides a useful vehicle for communicating the architecture to non-technical audiences, such as management, marketing, and many users.
3. The logical flow of the architecture:
The logical architecture is the detailed architecture specification, precisely defining the component interfaces and connection mechanisms and protocols. It also provides contextual information about the components and how they should be used in assembling systems. The logical architecture is used by the component designers and developers, as well as component users (i.e., those that assemble components into systems).
4. Execution Architecture: An execution architecture is created for distributed or concurrent systems. It is formed by mapping the components onto the processes of the physical system. Different possible configurations are evaluated against requirements such as performance and scaling.
5. Final analysis of selected architecture vs others: It is worthwhile challenging the team’s creativity to expand the solution set under consideration, and then evaluating the different architecture alternatives against the prioritized architectural requirements.

Validating the architecture: The architecture validation phase involves additional people from outside the architecting team to help provide an objective assessment of the architecture. In addition to enhancing confidence that the architecture will meet the demands placed on it, including the right participants in this phase can help create buy-in to the architecture. Architecture assessment involves “thought experiments”, modeling and walking-through scenarios that exemplify requirements, as well as assessment by experts who look for gaps and weaknesses in the architecture based on their experience. Another important part of validation is the development of prototypes or proofs-of-concept.

Iterations: It is more and more clear nowadays that it is impossible to have all the requirements in complete form right in the beginning, and it is only when you do multiple iterations that you get closer to the desired software product. Same way with the architecture, you need to not try for a perfect model in the beginning, but recognize that the architectural model will get refined as you move again through the various steps, and you may need to do multiple iterations.