Refine the architectural goals and architecturally-significant requirements
Work with the team, especially the stakeholders and the requirements team, to review the status of the Architectural Goals and Architecturally Significant Requirements and refine them as needed. It may be
that some new architecturally-significant requirements have been introduced or your architectural goals and priorities
may have changed.
The development work performed so far will also inform the decisions and goals you've identified. Use information from
designing and implementing the system so far to adjust and refined those decisions and goals.
Identify architecturally significant design elements
Identify concrete design elements (such as Components, classes and subsystems) and provide at least a name and brief
description for each.
The following are some good sources for design elements:
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. 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.
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 others?
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?
When you identify a component be sure to briefly describe the functionality that should be allocated to the components.
Refine architectural mechanisms
Refine the applicable Architectural Mechanisms, as needed to support the design. For example,
refining an analysis mechanism into a design mechanism and/or refining a design mechanism into an implementation
Define development architecture and test architecture
|Ensure that the development and test architectures are defined. Note any architecturally significant differences between
these environments and work with the team to devise strategies to mitigate any risks these may introduce.
Identify additional reuse opportunities
Continue to look for more opportunities to reuse existing assets. Where applicable, identify existing components
that could be built to be reused.
For more information, see Guideline: Software Reuse.
Validate the architecture
|Make sure that the architecture supports the requirements and the needs of the team.
Development work should be performed to produce just enough working software to show that the architecture is viable. This
should provide the definitive basis for validating the suitability of the architecture. As the software should be developed
iteratively, more than one increment of the build may be required to prove the architecture. During the early stages of the
project it may be acceptable for the software to have a incomplete or prototypical feel, as it will be primarily concerned
with baselining the architecture to provide a stable foundation for the remaining development work.
Map the software to the hardware
Map the architecturally significant design elements to the target deployment environment. Work with hardware and
network specialists to ensure that the hardware is sufficient to meet the needs of the system; and that any new
hardware is available in time.
|Ensure that those who need to act upon the architectural work understand it and are able to work with it. Make sure that
the description of the architecture clearly conveys not only the solution but also the motivation and objectives related to
the decisions that have been made in shaping the architecture. This will make it easier for others to understand the
architecture and to adapt it over time.