The architecture overview is created early in the lifecycle of a project, possibly as early as the inception phase. It reflects early decisions and working assumptions on implementing the Vision, as well as decisions concerning the physical and logical architecture, and nonfunctional requirements of the system. It's produced by the software architect, often in collaboration with the project sponsor, and takes the form of an informal, rich picture storyboard or iconic graph. Conceptually, it illustrates the essential nature of the proposed solution, conveying the governing ideas and including the major building blocks. The level of formality of the architectural overview is project dependent. For example, in a large, high-ceremony project, it might be necessary to capture the architecture overview in the appropriate sections of the Software Architecture document, so it can be formally reviewed.

At this point the architecture overview is a provisional first pass. Do not base commitments on the architecture overview diagram until an executable architectural prototype has validated the architecture, including design, implementation, and deployment concerns.

Consider basing the architecture on a reference architecture, other architectural patterns, or other architectural assets.

Consider whether or not you wish to refine and maintain the architecture overview diagram, to serve as a communication vehicle.

Many systems are constrained to be developed and deployed in an existing environment of hardware and software; for these, the software architect will gather information about the current environment.

For example, in an e-business system development the following information is pertinent:

• existing network logical and physical design
• existing databases and database design
• existing Web environment (servers, firewalls, and so forth)
• existing server environment (configuration, software versions, planned upgrades)
• existing standards (network, naming, protocols, and so on)

Such information can be captured either textually, or in a Deployment Model.

You need to understand the requirements of the environment for which assets are being considered, and the system scope and general functionality required. Search through organizational asset bases and industry literature to identify assets or similar projects. There are several types of assets to consider, such as (but not limited to) industry models, frameworks, classes, and experience. You'll 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 constraints.

You'll want to analyze the extent of the fit between asset and customer requirements, considering whether any of the requirements are negotiable (to enable use of the asset).

Be certain you 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 the asset.

Finally, you'll want to decide, in principle, whether to use one or more assets and document the rationale for this decision.

When the focus is on performing the architectural synthesis during inception, this step is excluded from this task.

Normally the design model is organized in layers-a common architectural pattern for moderate to large-sized systems. The number of layers is not fixed, but varies from situation to situation.

During architectural analysis, you usually focus on the two high-level layers; that is, the application and business-specific layers. This is what is meant by the high-level organization of subsystems. The other lower-level layers are considered in Task: Incorporate Existing Design Elements. If you're using specific architectural patterns, the subsystems are defined around the architectural template for that pattern.

For more on layering, see Guideline: Layering.

When the focus is on performing the architectural synthesis, this step is done to the extent necessary to guide the software architect in selecting assets for the construction of the Artifact: Architectural Proof-of-Concept and to support representative usage scenarios.

Requirements tasks and, when applicable, Business Modeling tasks usually uncover key concepts that the system must be able to handle; these concepts manifest themselves as key design abstractions. Because of the work already done, there is no need to repeat the identification work again during Task: Use Case Analysis.

You can take advantage of existing knowledge by identifying preliminary entity analysis classes to represent these key abstractions on the basis of general knowledge of the system, such as the Requirements, the Glossary, and, in particular, the Domain Model or the Business Analysis Model, if you have one.

When you define the key abstractions, also define any relationships that exist between entity classes. Present the key abstractions in one or several class diagrams, and create a short description for each. Depending on the domain, and the novelty of the system, analysis patterns that capture many of the key abstractions required to model the system might already exist. Use of such patterns (which should already have been successfully employed in the domain) will considerably ease the intellectual burden of identifying the important concepts that must be represented. [FOW97a] presents some analysis patterns that are immediately useful for modeling business systems, but might be applicable in other contexts. Another example is the Object Management Group (OMG), which also attempts to define interfaces and protocols for many domains through the work of its Domain Technology Committee and associated task forces. Inevitably, this work leads to identifying important abstractions in the domain.

The analysis classes identified at this point will probably change and evolve during the course of the project. The purpose of this step is not to identify a set of classes that will survive throughout design, but 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.

This step is included only when performing this task in inception.

The purpose of this step is to identify those interactions, between key abstractions in the system, that characterize or are representative of significant kinds of activity in the system. These interactions are captured as Use-Case Realizations.

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

• users (at locations), defined in User Profiles (in the Vision) and use cases (in the Use-Case Model)
• organization of business data (in the Business Analysis Model and Design Model when available)
• service level requirements (in the Supplementary Specifications)
• constraints (in the Supplementary Specifications, such as requirements to interface with legacy systems)

If a non-trivial distributed system is required, then a Deployment Model can be used to capture the relationship between nodes. This should include provisionally assigning components and data to nodes, and indicate how users access components that access data. Detailed specification of nodes and connections is deferred, except where they are important for estimating or assessing viability. Existing assets can be used, if appropriate assets are available. Although this is the first deployment model produced in the project, and it's produced quickly and at a high level, it might identify actual hardware and software products if they are known, or if it's important to make these selection decisions at this time.

Validate that the deployment model 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.

When the focus is on performing the architectural synthesis during inception, this step is excluded from this task.

Analysis mechanisms can be identified top-down (a priori knowledge) or bottom-up (discovered as you go along). In the top-down mode, experience guides the software architect to know that certain problems are present in the domain and will require certain kinds of solutions. Examples of common architectural problems that might be expressed as mechanisms during analysis are: persistence, transaction management, fault management, messaging, and inference engines. The common aspect of all of these is that each is a general capability of a broad class of systems, and each provides functionality that interacts with or supports the basic application functionality. The analysis mechanisms support capabilities required in the basic functional requirements of the system, regardless of the platform it's deployed upon or the implementation language. Analysis mechanisms also can be designed and implemented in a number of different ways; generally there will be more than one design mechanism corresponding to each analysis mechanism, and perhaps more than one way of implementing each design mechanism.

The bottom-up approach is where analysis mechanisms are ultimately born-they are created as the software architect sees, perhaps faintly at first, a common theme emerging from a set of solutions to various problems. There is a need to provide a way for elements in different threads to synchronize their clocks and there is a need for a common way of allocating resources. Analysis mechanisms, which simplify the language of analysis, emerge from these patterns.

Identifying an analysis mechanism means you identify that a common, perhaps implicit (in that the requirements for the system imply it), subproblem exists, and you name it. Initially the name might be all that exists; for example, the software architect recognizes that the system will require a persistence mechanism. Ultimately, this mechanism will be implemented through the collaboration of a society of classes (see [BOO98]), some of which do not deliver application functionality directly, but exist only to support it. Very often these support classes are located in the middle or lower layers of a layered architecture, thereby providing a common support service to all application level classes.

If the identified subproblem is common enough, perhaps a pattern exists from which the mechanism can be instantiated-by binding existing classes and implementing new ones as required by the pattern. An analysis mechanism produced this way will be abstract, and will require further refinement through design and implementation.

For more information, see Concept: Analysis Mechanisms.

As Architectural Analysis concludes, review the architectural mechanisms, the subsystems, packages, and classes that have been identified to ensure they're complete and consistent. As the results of Architectural Analysis are preliminary and relatively informal, reviews should be informal as well. Scenarios or use cases can be used to validate the architectural choices made at several levels-from the business perspective down to the specific interactions that occur.

See Checklist: Software Architecture Document - Architectural Analysis Considerations for more information on assessing the results of this task.