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, as needed. It may be that some new architecturally-significant requirements have been introduced or your architectural goals and priorities may have changed.

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:

• Architecturally Significant Requirements. Highlight the areas of the architecture that participate in realizing, or implementing, the requirements.
• Key Abstractions
• Components that encapsulate the system's interface with external systems.  For more information, see Guideline: Representing Interfaces to External Systems
• Components that implement the Architectural Mechanisms
• Architectural and key design Patterns. Apply the chosen patterns to define a new set of elements that conform to the patterns.

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 componentm be sure to briefly describe the functionality that should be allocated to the components.

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 mecahanism. 

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.

Produce a precise map of deployable software components to network nodes. 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.

Validate that the nodes and connections are adequate to support the anticipated interactions between components on different nodes, and between components and their stored data.