The ability to clearly and concisely describe (and document) the architecture for a solution is a key skill for architects, since the Architecture Description forms the “common language” by which the technical team gains a consistent understanding of the system to be delivered; additionally the Architecture Description is the starting point for other views and perspectives which may need to be created to communicate to other (non-technical) stakeholders. Another important role of the AD is to quickly and consistently bring new members of the technical team up-to-speed with the architecture of the system; as such the AD must be maintained during the SDLC to ensure it reflects the current state of the architecture for the system.
The AD provides detailed architecture communication and acts as a repository of architecture decisions for current and new team members, and for future maintainers of the solution – “If it’s not documented it doesn’t exist”. Architects should not underestimate the level of writing and communication skills necessary to be able to clearly and concisely communicate complex in a clear and understandable manner, since much of a typical AD is made up of narrative text.
Architects must be capable of delivering Architecture Descriptions in the preferred ADL of an organization, and to guide the selection of an appropriate ADL if necessary. The Architect must be able to apply judgment with regard to the level of rigor required for a particular project and the level of detail that the AD must deliver to support the needs of the solution through the entire SDLC. The process of Architecting is contingent on the application of experience and knowledge, not simply following a prescribed set of deliverables – all elements of the AD must add value and contribute to the success of the solution during the relevant phases of the SDLC. As such, the architect must be aware of the purpose and value of each component of the architecture description and be able to recognize (and justify) when to utilize (or not) each component of the AD.
Architecture description is the end-product of an architecture development process that begins with exploring and understanding the context within which a technology solution will be deployed (e.g., business architecture, business drivers, stakeholder concerns), constraints and risks, vision for and purpose of the system, its goal(s), and relevant usage scenarios. The Architecture Description will not contain only models, but also textual and other artifacts which provide context and background to the models, in addition to providing an overall “design narrative” for the architecture.
The AD should support the necessary views and perspectives needed to satisfy the requirements to both model the solution, and communicate the architecture to the key stakeholders (not just technologists). For example, a successful AD should:
- Be suitable for communicating architecture to all interested parties.
- Support the tasks of architecture creation, refinement, and validation.
- Provide a basis for further implementation – so it must be able to add information to the AD to enable the final system specification to be derived from the AD.
- Provide the ability to represent most of the common architectural styles.
- Support analytical capabilities or provide quick generating prototype implementations.
- Provide Architecture vision and views
- Conceptual Descriptions and Notations – Standard notations for representing architectural concepts that help promote mutual communication and understanding of high-level ideas, sketches and solution concepts.
- Logical Descriptions and Notations – Notations and descriptions that promote the embodiment of early design decisions, and creation of a transferable abstraction of a system, comprised of components and connections among them.
- Implementation Descriptions and Notations – Specific, concrete and implementation-ready descriptions of envisioned system that allow analysis, feasibility testing and implementation of architectural design decisions.
- Summarize major competitive products
- Provide an analysis of pros/cons in features and in technical implementations
- Document patterns used
- Document principles
- Explicitly state known constraints and risks
- Describe value to the business
- State existing standards and strategies which will guide the development of the architecture