• Analyze Architectural Requirements

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, 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 architectural constraints

Often, the system that you develop will be integrated into an existing environment. To ensure a smooth integration, you need to gather information about this environment and identify any architectural constraints.

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.

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.

Develop deployment overview

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 locations, defined in the Vision and use cases
• organization of business data
• service level requirements defined in the Supplementary Specifications.
• constraints (in the Supplementary Specifications, such as requirements to interface with legacy systems)

Validate that the deployment overview supports users (especially users at remote locations if this is required) performing typical use cases 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

Requirement and analysis tasks usually uncover key concepts that the system must be able to handle. These concepts manifest in design as key abstractions. Your Vision and Glossary work products are good sources for key abstractions. You can often easily identify these abstractions, because they represent things that are significant to the business. For example, Customer and Account are typical key abstractions in the banking business.

When you define the key abstractions, also define any obvious relationships that exist between entity classes. You can capture these in a table or on UML class 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 your initial assumptions.

The classes that you identify at this point will also probably change and evolve during the course of the project. The purpose of this step is not to identify a set of classes and relationships that will survive throughout design. Rather, it is to identify the key concepts that the system must handle. Don't spend too much time describing entity classes in detail at this initial stage, because there is a risk that you will identify classes and relationships that the use cases do not actually need. Remember that you will find more entity classes and relationships when looking at the use cases.

Identify analysis mechanisms

See Analysis 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.

If a more complex system is required, then a more formal and comprehensive set of models that describe the architecture from a number of viewpoints is more appropriate. See Architectural View for more information. 

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