Identify architectural goals

Architectural goals provide the motivation and rationale for decisions. These goals are often driven by the software requirements, particularly in Supporting Requirements Specification, because they are not always obvious from the use cases alone [ALL02].

Architectural goals define how the system needs to respond to change over time. Consider these questions when writing your goals:

• What is the expected lifespan of the system?
• Will the system need to respond to technological changes over that time, such as new versions of middleware or other products?
• How frequently is the system expected to adapt to change?
• What changes can we anticipate in the future, and how can we make them easier to accommodate?

These considerations will have a significant effect on the structure of the system.

Identify architecturally significant requirements

Some of the requirements will be more significant than others when considered from an architectural perspective. Identifying them will define the subset of requirements that will generally need to be satisfied before the architecture can be stabilised. Furthermore, the system will generally be more sensitive to changes against architecturally significant requirements than others, so identifying and communicating ths subset will help others understand the potential implications of change.

Requirements can be explicitly or implicitly architecturally significant. Implicitly significant requirements may define the essence of the functional behaviour of the system (for example, making a purchase from an on-line store). Explicitly significant requirements are often overtly technical in nature, such as performance targets; the need to interface to other systems; the number of users that must be supported; or security requirements.

See Determine Architecturally Significant Requirements for more information.

Identify constraints on the architecture

Gather information about the existing environment and identify any constraints in the solution. This will ease integration with the environment; and may reduce risk, cost and duplication of solution elements.

Architectural constraints can arise from various factors:

For example, if the company uses only one type of database, you will probably try to use it as much as possible to leverage the existing database administration skills, rather than introducing a new one.

These architectural constraints, combined with the requirements, help you define an appropriate candidate for the system architecture.

Survey, assess, and select from available assets

To assess and select assets to reuse on your project, you need to understand the requirements of the system's environment. You also need to understand the scope and general functionality of the system that the Stakeholders require. There are several types of assets to consider, including (but not limited to): reference architectures; frameworks; patterns; analysis mechanisms; classes; and experience. You can search asset repositories (internal or external to your organization) and industry literature to identify assets or similar projects.

You need to assess whether available assets contribute to solving the key challenges of the current project and whether they are compatible with the project's architectural constraints. You also need to analyze the extent of the fit between assets and requirements, considering whether any of the requirements are negotiable (to enable use of the asset). Also, assess whether the asset could be modified or extended to satisfy requirements, as well as what the tradeoffs in adopting it are, in terms of cost, risk, and functionality.

Finally, decide, in principle, whether to use one or more assets, and record the rationale for this decision.

Define approach for structuring the system

Structuring your system helps you manage its complexity by using the well-known "divide and conquer" strategy. By breaking the process into smaller and more manageable pieces, you make development easier.

Layering  is one of the most commonly used approaches for structuring and decomposing systems. Each layer groups similar classes or components, which communicate insofar as possible only with adjacent layers.  See Guideline: Layering for more information.

You do not define which layers contain which classes or components. Instead, you define how many layers you will need and which kinds of layers you will use. For example, if you are developing a new middleware system, you probably do not need a business layer. Later, during design activities, you decide which classes and components will populate these layers.

Define approach for deploying the system

Develop a high level overview of how the software is deployed. For example, determine if the system needs to be accessed remotely, or has requirements that suggest distribution across multiple nodes. Some sources of information to consider are:

• users at geographical locations
• organization of business data
• service level requirements
• constraints (such as requirements to interface with legacy systems)

Validate that the deployment overview supports users (especially those users at remote locations if this is required) performing typical usage scenarios while satisfying nonfunctional requirements and constraints. Validate that the nodes and connections are adequate to support the interactions between components on different nodes, and between components and their stored data.

Identify key abstractions

Requirements and analysis tasks usually uncover key concepts and behaviors that the system must be able to handle.

The concepts manifest in design as key abstractions. Key behaviors should correlate with the scenarios identifed as part of the architecturally significant requirements and represent the important interactions between key abstractions.

The Vision and Glossary work products are good sources for key abstractions. These abstractions are often easily identified because they represent things that are significant to the business. For example, Customer and Account are typical key abstractions in the banking business.

The abstractions that are identified at this point will also probably change and evolve during the course of the project. The purpose of this step is not to identify the complete set of classes and relationships that will survive throughout design. Rather, it is to identify the important concepts that the system must handle. The value in calling them out early in the project is that everyone on the team understands the importance of these concepts and develops coherant software to handle them consistently.

Don't spend too much time describing abstractions in detail at this initial stage, because there is a risk that spending too much time will result in identifying classes and relationships that the solution does not actually need. When identifying key abstractions, it can be useful to also define any obvious relationships that exist between them. These can be captured in a table or in diagrams (in a tool or whiteboard), and create a short description for each abstraction. In general, it is not worth agonizing over defining a highly detailed set of relationships at this early stage in design. The relationships will become more concrete and detailed later and will probably modify these early assumptions.

Identify architecture mechanisms

See Concept: Architectural Mechanism.

Capture architectural decisions

It is often useful to record key architectural decisions and working assumptions on an architectural overview diagram to make it easier to communicate the architecture to the project team and stakeholders. This information should be part of the description of the architecture, but it can vary in format to suit the needs of the project. For example, on an agile and low-ceremony project the overview diagram can be an informal picture story board or a graph with icons on either a whiteboard or a drawing tool. The illustration needs to show the nature of the proposed solution, convey the governing ideas, and represent the major building blocks.

Architecture decisions should be captured in the Artifact: Architecture Notebook.

If a more complex system is required, then the architecture can be represented as a more comprehensive set of views that describe the architecture from a number of viewpoints. See Architectural View for more information.

Capture architectural decisions (Visual Modeling)

You will find it useful to develop these three Unified Modeling Language (UML) diagrams at this stage:

• Layer map (represented as a class diagram using packages) that describes the upper-level layers of the architecture
• Draft deployment diagram that outlines the expected network topology
• Simple class diagram that shows the key abstractions and any obvious relationships among them