|
Identify architectural goals
Work with the team to describe the remaining goals for the architecture and identify which ones are appropriate to
address for this iteration. Look at the requirements and speak to the people asking for them to
make sure that the critical goals for this iteration are well understood. These goals will prioritize and
guide the approach to important technical decisions.
It's important to regularly review the status of these goals throughout the project to make sure that they are still
valid and that the system is on track to deliver them.
For more information, see Concept: Architectural Goals.
|
Identify architecturally significant requirements
Identify which of the current requirements are architecturally significant. Explore and refine those that must be
implemented in order to realize the architectural goals for the current iteration. See Concept: Architecturally Significant Requirements for more information.
|
Identify constraints on the architecture
List any constraints on the architecture and any trade-offs between competing requirements and resources. Decide how
the architecture will meet these issues. Justify each of the decisions made and capture this information. Regularly
review the list of constraints to make sure that they are still valid and that no new ones have appeared.
For more information, see Concept: Architectural Constraints.
|
Identify key abstractions
Identify the key concepts and abstractions that the system needs to handle. The requirements are good sources for key
abstractions. Don't spend too much time describing abstractions in detail at this initial stage, because
there is a risk that spending too much time will result in identifying classes and relationships that the solution does
not actually need.
When identifying key abstractions, it can be useful to also define any obvious relationships that exist
between them. These can be captured in a table or in diagrams (in a tool or whiteboard. 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 these
early assumptions.
For more information, see Concept: Key Abstractions.
|
Identify reuse opportunities
Survey, assess, and select available assets. Identify assets from other areas that may be reused in the current
architecture. For more information, see Guideline: Software Reuse.
|
Define approach for partitioning the system
Decide how to partition the software, both in logical and physical terms. Partitioning 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.
As a minimum, decide on:
-
How to partition the software when managing development (the use of layering as a partitioning strategy, for
example). For more information, see Guideline: Layering.
-
How the software will be composed at run time.
For each software partition, briefly describe
-
Its name and purpose.
-
Its relationships to other partitions.
At this point, you do not need to identify the elements that should be placed in each of these partitions.
Instead, you define how many partitions you will need and how they should be related. Later, during design
activities, you decide which elements will populate these partitions.
|
Define approach for deploying the system
Outline how the software will deploy over the nodes on the network. Work with stakeholders such as network support and
deployment teams to ensure that the proposed approach is a good fit for the wider technical environment.
|
Identify architectural mechanisms
Make a list of the technical services that the system needs to provide and capture some basic information about
each item on the list. It's generally a good idea to make an initial list of all the mechanisms required for the
project and then prioritize the development of those that need to be delivered to achieve the architectural goals.
At this point, usually only the analysis mechanisms are defined. However, specific Architectural Constraints may mean that some of those mechanisms can be
described as design mechanisms (even at this early stage).
For more information on architectural mechanisms, see Concept: Architectural Mechanism.
|
Identify interfaces to external systems
At this point, identify the external systems with which this system must interact. An external system may be
anything from software to hardware units that the current system will use, such as printers, terminals, alarm devices,
and sensors.
Describe those interfaces at a high level, concentrating on the information that must pass between the systems.
|
Verify architectural consistency
| Work with the team to verify that the architecture is consistent with the requirements and that the descriptions of
the architecture are complete, meaningful, and clear. |
Capture and communicate architectural decisions
| Capture important decisions about the architecture in the Architecture Notebook for future reference. Make sure that the team
understands the architecture and can deliver it. |
|
