The following table lists the types of output & types of engagement delivered during each stage in the lifecycle the type is referenced throughout the engagement model indicating how an architect will be involved.
||Office document (Word, Excel, PowerPoint etc.)
||Meeting (e.g. ARB, Roadmap envisioning)
||Description or representation of a business, process or system
||Formal advice delivered from ARB
||Architecture Repository, Lifecycle Mgmt, Project Mgmt Tooling
||Decision made by appropriate governance structure (e.g. ISLT, ARB)
||Any business contact where architecture can be promoted leveraged or presented in the context of delivering business value.
Views and Viewpoints
See Views and Viewpoints Capability
The concept of views and viewpoints is widely used across the architectural community, having originated back in the 1970’s where Ross’s Structure Analysis and Design Technique used them, the concept of Views became widely accepted following the development of Kruchten’s 4 + 1 architecture view model, they have since been formalized in the ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description.
The principles of views and viewpoints are defined in slightly different ways in different places; the definitions adopted by Iasa are:
- An architectural view is a representation of one or more aspects of an architecture that illustrates how the architecture addresses the concerns held by one or more of its stakeholders.
- A viewpoint is a collection of patterns, templates, and conventions for constructing one type of view. It defines the stakeholders whose concerns are reflected in the viewpoint and the guidelines, principles, and template models for constructing its views.
An example would be to use an operational viewpoint to create a view targeted at the Help Desk manager. The viewpoint is the template that contains information relevant to the operations of the system, and a view is the end product delivered to someone interested in maintaining the operational capability.
IT architects must have the ability to compare/contrast concept of views, viewpoints, and perspectives, understand the differences between them and how they work together to describe an architecture. They must be able to discern various stakeholder groups typical of IT development projects, describing the typical viewpoint of each group, and determine the set of views needed to satisfy project requirements.
The architecture repository is the mechanism the team uses to store, share and update architecture artifacts.
Figure Architecture Repository