The Metamodel

1. The Metamodel

2. 4 ‘Big Ideas’ from the Standard • 0. Architecture /= Architecture Description • 1. Architectures exist for systems (including software-only systems) to satisfy known concerns from stakeholders • This ensures the architecture, and its description, are relevant • Stakeholder concerns, often non-functional, drive the architecture 2. Architecture Descriptions are inherently multi-view • No single view addresses all concerns • A view should cover the entire system (with respect to the concerns of interest) 3. Viewpoints (‘what to describe’) are separate from Views (‘this description’) • Represents current practices with ‘viewpoint sets’ such as Kruchten’s “4+1” • Ensures consistency and repeatability, particularly when evaluating alternative architectures

3. Irrelevant architecture • Common problems • Architecture effort focused on the wrong problems • Architecture effort producing the wrong information • Architecture arriving too late • Applying the Standard • Use Stakeholders and Concerns to identify the most critical problems • Hold a Stakeholders & Concerns review early, to get buy-in (e.g. Software Engineering Institute’s “Quality Attribute Workshop”) • Use Viewpoints to make sure the architecture products meet stakeholder expectations • Ensure the Viewpoint has the right notations and content • Ensure the Viewpoint supports analysis and reviews • Consider 2 ‘quality gate’ reviews • Stakeholders, Concerns, Frameworks, Viewpoints, Tools, Schedule, etc • View/Model Content

4. Doing ‘too much architecture’ -Focusing an architecture effort • Common problems • Architecture content not relevant (see previous solutions) • Architecture deliveries poorly understood • Architecture deliveries have wrong content • Architecture content not integrated into other project life cycle activities and repositories • Applying the Standard • Viewpoints provide the ‘document descriptions’ for architecture content • Viewpoints should trace to identified Stakeholder Concerns (relevance) • Viewpoints should define model content and modeling techniques, including tool usage and evaluation/review/qualification • Views and Models provide a basis for estimating architecture effort • Viewpoint tells you what will be in the View and how to produce it • This facilitates planning the effort • Prioritizing Stakeholder Concerns and Models help size the architecture effort

5. Making the (architecture) solution‘fit for purpose’ • Common problems • Requirements and operational context/environment for the system not understood or captured • No early representation of the entire system to use for analysis, review or even ‘walkthroughs’ • Non-functional requirements not considered/not considered early enough • Applying the Standard • Stakeholder Concerns should include ‘how does the system fit in its environment?’ • Includes identifying driving non-functional requirements • Viewpoints should define appropriate analysis/review of non-functional aspects of the architecture, e.g. end-to-end performance models as part of a Performance Viewpoint • Scenario-based evaluation methods such as SEI’s Architecture Trade-Off Assessment Method (ATAM tm) should be part of the architecture process • Viewpoint/Model content should include enough detail for informal walkthroughs of system functions • Connect View content to formal requirements/specifications • Provide appropriate View Correspondence Rules to integrate architecture content

6. Using the Standard to improve architecture practices • Define an Architecture Framework • Capture typical Stakeholders and Concerns in its domain • Identify Viewpoints against those concerns • Identify Models, including content, tool support, evaluation approaches • Identify cross-Model linkages, including how these links are established and maintained • Provide training and maintenance for the organization’s Architecture Framework • Tie the Architecture Framework into the overall development process • Establish an architecture planning process based on • Prioritizing Stakeholders & Concerns • Estimating resources for producing Views, given Viewpoint descriptions and an understanding of the system of interest • Establish architecture reviews • Establish linkages (including tool support) between architecture work products and other process artifacts/deliverables • Provide for maintenance of the architecture over the system life-cycle

7. Sample application of the Standard:Product Lines • Product Lines can/should share a common Architecture Framework • Each product within the Product Line should be a separate (ISO 42010 conforming) Architecture Description • The Architecture Framework can define Models that are shared among all product line instances • The conformance points in the standard are defined in terms of a ‘single system in a point in time when conformance is claimed’ • Consider the ‘architecture’ of each vehicle (built on a common chassis):