This article presents the outline of a method for developing Software Architectures. Even though developing Architectures seems to be – and to some extent is – a creative process it is important to approach it in a structured way. This ensures that all important aspects of the architecture – and therefore the client’s non-functional requirements – are covered.
Developing Software Architectures is an iterative process. Initially, inputs – called requirements – are collected and used as the basis for developing the Software Architecture.
Sound Software Architectures do not just require our own experience but should draw the best from a number of other sources, such as: methodology, software engineering, available assets, technologies and products, best practices or patterns.
Just as important as the development is the documentation of the architecture itself. Documentation plays an essential role in communication of the rationale, validation against the requirements, and as master-design.
This article outlines briefly how Software Architectures can be developed using a structured, methodological.
Software Architectures are developed based on requirements, which are raised by the stakeholders. The Architect may play a facilitating role in identifying and collecting those requirements.
It is the responsibility of the Architect, or the team of Architects, to develop a Software Architecture that meets the criteria defined by the requirements. Requirements are typically raised by a stakeholder or client. Developing Software Architecture is an iterative process, where the Software Architecture is iteratively refined until its characteristics meet the criteria defined by the requirements. If necessary, the requirements themselves are refined as well.
Important to remember is that a Software Architecture is not a uniquely valid solution to a problem statement. There is always more than one possible architectural solution, depending on the choices made throughout the process.
The process of developing Software Architectures are multiple iterations over the steps listed below:
- Identify new and/or refine requirements
- Categorize the requirements
- Iterate over, and refine, the architectural model
- Document the Software Architecture
- Reiterate, starting at step one
3. The process of developing a Software Architecture
Identify and/or refine the requirements
At the start of the Software Architecture development-cycle, different sources of requirements will be available. Software Architectures are primarily developed based on non-functional requirements.
Functional requirements are considered in that the target Software Architecture has to be able to provide the functionality required. Some functional requirements will have direct impact on Software Architecture as they generate additional non-functional requirements.
It is essential for this step to extract those requirements that most strongly influence the Software Architecture.
Categorize the requirements
Software Architectures have characteristics. Characteristics I frequently encounter are: Capacity, Performance, Scalability, Availability, Security, Operability, Maintainability, and Usability.
Some characteristics can be found more often than others, and some of them apply to particular kinds of Software Architectures only and not to others. If you are interested in more detail on this please refer to [Albin 2003], [Garland 2003], or [Software Architectures.com 2009].
Each particular architectural characteristic has specific design properties associated with it. For example, design for scalability will result in the application of specific architectural patterns, such as clustering.
It is now important to assign the architectural requirements to those categories. This way you group architectural requirements around clusters of architectural characteristics. The clusters of requirements formed drive primarily how each architectural characteristic will be addressed from a design point of view.
Iterate over, and refine, the architectural model
The Software Architecture is defined in a series of iterations where design decisions are made based on the requirements and their classifications. Even though the development of Software Architecture is dynamic in nature it contains recurring, important activities. Ones important to me are:
- Make feasible and comprehensible architectural/design decisions
- Select technologies, products and/or reusable assets applicable to your product
- Identify suitable best practices and patterns
- Follow a formal, documented methodology
- Document the decisions made throughout the process
Making comprehensible, well founded design decisions is the most important aspects of developing Software Architectures. The most important question to ask is: “How will it work?”. For every requirement an explanation of how it will work is required. As long as there are is an unanswered question it is likely that the definition of the Software Architecture is not complete.
Successful Software Architectures avoid re-inventing the wheel and draw from existing experience. Existing experience is available in many forms, such as technologies, even the integration of products is possible, experience of colleagues, best practices and patterns just to name some.
Even though the process is creative and dynamic in nature, it is important to base the development on a formal methodology. This ensures a particular level of quality and bases the development on software engineering principles. Of particular importance is that the decisions made as well as the impact it has on the Software Architecture are documented throughout the process.
Document the Software Architecture
The Software Architecture of a particular system is a model. Documenting Software Architecture is like visualizing this model using different views. Which views you need depends on the intended purpose of the Software Architecture.
As you can imagine, the necessary documentation elements of a Reference Architecture will differ from the necessary documentation elements for Software Architecture of business applications.
Documentation of Software Architectures serves as an important visual aid in communicating the rationale to the project team members and stakeholders, but also assists in other – less obvious – important purposes. It
- is the master design-blueprint and serves as guideline to the team,
- documents agreements between the project team and stakeholders, and
- is the basis for validating the architecture against the requirements.
While some views are highly specialized and are found in some cases only, I found that particular views are of significant importance and need to be present in every Software Architecture:
- Architecture overview, describing the key design points
- A log of the significant design decisions made while designing the architecture
- A description of all interfaces to other systems
- A component model describing technical and functional components, and how they are connected
- Design blueprints for all architectural characteristics of the system as guidance to the design team
- Deployment- and operational aspects, building the bridge to the infrastructure- and operational view
- User interface guidelines, building the basis for uniform user interfaces
- The architecture will contain the data-aspect one or the other way, either as logical data model or as part of the component model
- In Service Oriented Architectures, a definition of the service interface is of essence
Software Architecture fills the gap between the business need of an organization and the technical reality in a software development project. This article outlines how Software Architectures can be developed from business requirements in a structured approach.
Developing a Software Architecture should value theoretical software engineering principles and be more concrete than theoretical. It is important to avoid overloading the Software Architecture with an overabundance of information. This means that design decisions should be captured clearly, avoiding optional or ambiguous definitions. The more precise and clear it is the easier it will be to keep it up to date and consistent.
Very important is to keep your Software Architecture simple, but not limited. In particular this means avoid overloading your Software Architecture with unnecessary technical complexity. This can be achieved by continuously focusing and refocusing on the business goal(s) the Software Architecture is aiming to satisfy. Successful Software Architectures have more focus on addressing the business need, than on shiny new technologies.
A key element in the process of designing the architecture of a software solution is the acceptance of the Software Architecture by the project- and stakeholder-team. This requires continuous communication, adoption and work on it in order to make sure that it stays current and is followed upon.
[TOGAF 2006] The Open Group. 2006, “Welcome to TOGAF™ — The Open Group Software Architecture Framework: Frequently Asked Questions”, The Open Group [online] available at http://www.opengroup.org/Software Architecture/togaf8-doc/arch/
[CMUSEI 2010] Software Engineering Institute. “Software Architecture”, Carnegie Mellon University” [online] available at http://www.sei.cmu.edu/Software Architecture/
[Somerville 1995] Sommerville, I. 1995, Software Engineering Fifth Edition, Addison-Wesley, Essex
[Albin 2003] Albin, Stephen T. 2003, “The Art of Software Architecture: Design Methods and Techniques”, John Wiley & Sons
[Garland 2003], Garland, Jeff, Anthony, Richard. 2003, „Large-Scale Software Architecture: A Practical Guide using UML”, John Wiley & Sons
[Software Architectures.com 2009] SoftwareArchitectures.com. 2009, “Quality Attributes”, Software Architectures.com [online] available at http://www.softwarearchitectures.com/go/Discipline/DesigningSoftware Architecture/QualityAttributes/tabid/64/Default.aspx
Copyright © 2010 Michael Pichler