Identify architecturally significant design elements

Consider each high-priority scenario that is within the scope of the project. Walk through the actions that the scenario initiates, and highlight the areas of the architecture that are factors in realizing, or implementing, the requirements.

Identifying components will help hide the complexity of the system and help you work at a higher level. Components need to be internally cohesive and to provide external services through a limited interface. Component identification can be based on architectural layers, deployment choices, or key abstractions. Ask yourself these questions:

What is logically or functionally related (same use case or service, for example)?
What entities provide services to multiple other services?
What entities depend on each other? Strongly or weakly?
What entities should you be able to exchange independently from others?
What will run on the same processor or network node?
What parts are constrained by similar performance requirements?

Each component includes entities from the problem domain, control classes that coordinate complex tasks within components, and interfaces that handle communication with the environment. The interface for each instantiated element is identified. At this point, interfaces do not need to be as detailed as a signature, but they do need to document what the elements need, what they can use, and what they can depend on.

Identified patterns define the types of elements, but not a specific number. Apply the chosen patterns to define a new set of elements that conform to the patterns. Functionality will be allocated to the instantiated elements.

Refine the Architectural Mechanisms

Consider each high-priority quality scenario, and map each of these onto the Architectural Mechanisms. Refine the mechanisms to identify the specific technology that will handle each mechanism within the scope. For example, for the Persistence mechanism, it may be appropriate to use a relational database management system, such as MySQL. Consider the selection of technology in the context of the requirements and constraints.

See Concept: Architectural Mechanism for more information.

Map the software to the hardware

Produce a precise map of deployable software components to network nodes.

Define development and test architectures

The configuration of the environments where the system is developed and tested may be different from the target production environment, and this may have an impact on the solution. For example:

Additional software may needed to be developed to support testing.
Alternative deployment configurations may need to be defined for different environments in response to constraints on development and test hardware.
Multiple environments may be required to support different categories of tests (such as performance testing or user acceptance testing). These will need to be specified.

These scenarios, although not desirable, are often forced on the team through various constraints. Consequently, the architecture for these different environments will need to be specified with particular attention paid to significant differences. Be sure to consider the impact of any differences on the quality of the overall target production architecture.

Validate the architecture

The surest way to validate the architecture is through software. The software developed up to the end of the Elaboration phase is largely aiming to validate the architecture (to the point where it can be baselined), thereby providing some level of stability during the Construction phase.

It can also be useful to perform simple validation by walking through the main design concepts and models, perhaps by using a whiteboard or through other collaborative techniques. This can help refine thinking but will not act as a substitute for building some software.

Communicate decisions

You can document and communicate your decisions as many ways as you wish, for example:

Publication of reference source code
Publication of reference models
Publication of software architecture documentation
Formal presentations of the material
Informal walkthroughs of the architecture