Produce a formally documented consensus among the project
stakeholders (e.g., customer, management, developers)
concerning the architectures of the next version [incremental iteration] of the application.
Provide input (e.g., number, size, and complexity of system components):
To the project cost and schedule estimation task.
For the scheduling of the project phases and milestones.
Maximize the quality of the architectures:
Correctness, completeness, consistency, and understandability.
To meet architecturally significant:
Operational requirements
Quality requirements (e.g., extensibility, scalability, performance, operational availability, and security)
Design constraints (e.g., use of existing databases)
Ensures that the system architectural structure is
consistent with the software design approach so that design
entities (e.g., classes, agents, functions) are easily allocatable to major system components.
This team should not be made up of the leaders of the other teams.
Architecting is a full time job and requires a dedicated membership.
Architecture requires more expertise and experience than design.
There may be some overlap between this team and the environments team.
The database architecture is documented in the system architecture document,
software architecture document, and database design document.
The security architecture is primarily documented in the software design document.
The same person often plays multiple architect roles.
The architecture team should work closely with specialty engineering teams that may influence the architecture
to ensure that engineering tradeoffs are made between support for the various quality factors:
The safety team may want to spread data around the system to support recovery, which will lesson security.
The security team may want to create protection layers and security controls that will decrease performance.
The performance team may want to create a tightly-coupled architecture
that will lower extensibility, safety, and security.