• Define the Architecture

Identify Architecture Goals

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

Architecture goals define how the system needs to respond to change over time. You should consider questions such as

• what is the expected life-span 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 Architecture Constraints

Often, the system that is developed will be integrated to an existing environment. To ensure a smoother integration as possible, you need to gather information about this environment and identify any architectural constraint.

Architectural constraints can include

For example, if there is just one type of database used in the company, you will probably try as much as possible to use it to leverage the existing database administation skills rather than introducing a new one.

These architectural constraints combined with the requirements will help you define an appropriate candidate 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 environment for which those assets are being considered. You also need to understand the system scope and general functionality required by the system's stakeholders. There are several types of assets to consider, such as (but not limited to) reference architectures; frameworks; patterns; analysis mechanisms; classes; and experience. You can search through asset repositories (internal or external to your organization), and industry literature to identify assets or similar projects.

You will 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 will want also to analyze the extent of the fit between asset and requirements, considering whether any of the requirements are negotiable (to enable use of the asset). You should also assess whether the asset could be modified or extended to satisfy requirements, and what the tradeoffs are in terms of cost, risk, and functionality from adopting it.

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

Define approach for structuring the system

Structuring your system helps you manage its complexity using the well-known "divide and conquer" strategy. By breaking it on smaller and more manageble pieces you make its development easier.

Layering approach is one of the most common used approaches for structuring and decomposing systems. It is based on the concept of "layers", each layer grouping similar classes or components, and communicating as much as possible only with its direct neighbours.

You will not be defining on which layer each class or component will go, but much more how many layers you need and which kind of layers you will be using. For example, if you are developping a new middleware system, you probably do not need a business layer.

It is later during design activities that you decide how these layers will be populated in terms of classes and components.

Identify key abstractions

Requirements and analysis tasks usually uncover key concepts that the system must be able to handle. These concepts manifest themselves in design as key abstractions. Good sources for key abstractions include the Vision and Glossary work products. Key abstractions can often be easily identified, as they represent things that are significant to the business. For example, the banking business domain typically has key abstractions like Customer and Account.

When you define the key abstractions, also define any obvious relationships that exist between entity classes. You can capture them in a table, or on UML class diagrams (in a tool or whiteboard), and create a short description for each abstraction. In general, it doesn't pay to agonise 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 identified at this point will probably also 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 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'll identify classes and relationships not actually needed by the use cases. Remember that you will find more entity classes and relationships when looking at the use cases.

Identify Analysis Mechanisms

See Analysis Mechanisms.

Capture architectural decisions

It is often useful to record key architectural decisions and working assumptions on an architecture overview diagram to make it easier to communicate the architecture to the project team and stakeholders. This information should be part of the architecture description but can vary in format to suit the needs of the project. For example, on an agile and low-ceremony project, the overview diagram can take the form of an informal, rich picture storyboard or iconic graph on whiteboard or drawing tool. Its role is to conceptually illustrate the nature of the proposed solution, conveying the governing ideas and including the major building blocks.

If a non-trivial system is required, then a more formal and comprehensive set of models describing the architecture from a number of viewpoints is more appropriate. See Architecture View for more information. 

Useful UML diagrams to produce at this stage are

• A layer map (represented as a class diagram using packages), describing the upper level layers of the architecture
• A draft deployment diagram, outlining the expected network topology
• A simple class diagram, showing the key abstractions and any obvious relationships between them