Develop Architecture Overview
To facilitate system envisioning by exploring and evaluating high-level architectural options.
To convey an early understanding of the high-level structure of the intended system to the sponsor,
development teams, and other stakeholders.
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
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.
Survey Available Assets
To identify assets that might be relevant to the project.
To analyze the fit and gap between assets and project requirements.
To decide whether to base areas of the system on assets.
To locate and list assets that are potentially reusable on the project.
To perform a preliminary evaluation to ensure that necessary support is potentially available.
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
Define the High-Level Organization of Subsystems
To create an initial structure for the Design Model.
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.
Identify Key Abstractions
To get prepared for analysis by identifying the key abstractions (representation of concepts identified
during business modeling tasks when applicable and requirement tasks) that the system must handle.
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
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.
Identify Stereotypical Interactions
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
Develop Deployment Overview
To provide a basis for assessing the viability of implementing the system.
To gain an understanding of the geographical distribution and operational complexity of the system.
To provide a basis for early effort and cost estimates.
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
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
Identify Analysis Mechanisms
To define the analysis mechanisms and services used by designers to give "life" to their objects.
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
For more information, see Concept: Analysis Mechanisms.
Review the Results
To ensure that the results of architectural analysis are complete and consistent.
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
See Checklist: Software Architecture Document - Architectural Analysis Considerations
for more information on assessing the results of this task.