What is an Engagement Model
The Iasa Engagement Model are the combined activities, deliverables, and work that an organization of architects use to achieve a mature and valuable architecture practice. The goal of the engagement model is to make the best use of architecture teams work to deliver on business technology strategy.
Lifecycles, Weave(s) and Threads
The Iasa Engagement Model includes many practical activities which help architects develop and grow their architecture capability. These activities are often labeled Weaves or Threads to help isolate specific activities in the engagement model. We use the term thread to delineate a specific arrangement of activities that is somewhat smaller than a Weave which has a much larger/multi-team-based usage.
Business to Solution Architecture – The Value Weave
This method is built to optimize value streams and large solutions which require deep strategy to execution understanding throughout the lifecycle. Note: while the timeline is written sequentially, this is NOT considered a waterfall activity, it is simply the limitation of graphics and navigation lending itself to a somewhat sequential order. It should be understood that many of these activities happen concurrently, iteratively and with multiple team members leading and participating.
Usage and Value
Usage and Value is achieved after a product/project is deployed. Many architects and organizations ignore the measurements of how well the product measures against the objects and key results that were used to justify it in the first place. The ITABoK heavily suggests usage information measured on dashboards against OKRs in retrospectives against the deployed system.
Assessment
Architecture Assessments are the methods employed to design, review and assess architecture choices against options and to review the choices made in relation to the outcomes expected in the product/project. The goals of assessment are to find missing elements of architecture, things that wont meet quality attribute requirements or design tradeoffs that are not effective for the intended purpose.
Agile DevOps
Agile DevOps delivery is the heart of most development and IT shops. The ITABoK makes plenty of room for both agile and traditional methods. The basis for the ITABoK is bottom up architecture, meaning architects are actively involved during delivery not in up front design. This means that architects are actively engaged with teams, projects, products and value streams in the business.
Viewpoints
Views and Viewpoints give the architect different ways to look at an architecture using different decision making and design paradigms. For example, one might look at the information view of an architecture to understand the data, information and entities in the system or systems. The availability of views is a hallmark of great architecture thinking and communication.
Quality Attributes
Quality Attributes are the cross-cutting concerns of an architecture related to its structure and quality attribute requirements. Scalability, usability, flexibility, etc are all considered as a part of the quality attribute assessments and design activities. Each area impacts the others so quality attribute design can be a very powerful tool in understanding the overall functioning of the system. Quality attributes also feed directly into the architecture assessment methods presented by Iasa and organizations like the SEI.
Decisions
Decisions are the heart of architecture. Understanding why a decision was made, how it impacts the solution, how it interacts with other decisions is the core of a great architecture. Being able to trace decisions to cost, benefit and outcome is the pinnacle of delivery and design. The ITABoK is centered on making decisions easier, more relevant and more timely. Decisions relate to requirements, quality attributes, views, structure and complexity, and architecture descriptions in their context.
Options
Decisions are the heart of architecture. Understanding why a decision was made, how it impacts the solution, how it interacts with other decisions is the core of a great architecture. Being able to trace decisions to cost, benefit and outcome is the pinnacle of delivery and design. The ITABoK is centered on making decisions easier, more relevant and more timely. Decisions relate to requirements, quality attributes, views, structure and complexity, and architecture descriptions in their context.
Requirements
Requirements management is a full art and science but what the architect is interested in are Architecturally Signficant Requirements. These requirements come in many shapes and sizes but the architect is interested in requirements that impact structural issues (mostly quality attributes), value (measurable benefits and cost), and constraints (standards, compliance, risk).
Stakeholders
The BTABoK is driven by a Stakeholder Led Approach which provides many tools for the architect and team to create a rigorous stakeholder community.
Team Design
Product and project team assignments and structure are deeply important to the success of any solution. Aligning the competencies of the architect(s) and the team(s) will have a huge impact on the outcomes. The goal of the Team Designer, Assignments and prioritization activities go together very well whether using agile or more traditional methods of delivery.
The Red Thread
For smaller solutions and products, the Red Thread will generally be enough to ensure the product delivers value and is aligned with the technology strategy and outcomes of the organization.
Usage and Value
Usage and Value is achieved after a product/project is deployed. Many architects and organizations ignore the measurements of how well the product measures against the objects and key results that were used to justify it in the first place. The BTABoK heavily suggests usage information measured on dashboards against OKRs in retrospectives against the deployed system.
Agile DevOps
Agile DevOps delivery is the heart of most development and IT shops. The ITABoK makes plenty of room for both agile and traditional methods. The basis for the ITABoK is bottom up architecture, meaning architects are actively involved during delivery not in up front design. This means that architects are actively engaged with teams, projects, products and value streams in the business.
Viewpoints
Views and Viewpoints give the architect different ways to look at an architecture using different decision making and design paradigms. For example, one might look at the information view of an architecture to understand the data, information and entities in the system or systems. The availability of views is a hallmark of great architecture thinking and communication.
Quality Attributes
Quality Attributes are the cross-cutting concerns of an architecture related to its structure and quality attribute requirements. Scalability, usability, flexibility, etc are all considered as a part of the quality attribute assessments and design activities. Each area impacts the others so quality attribute design can be a very powerful tool in understanding the overall functioning of the system. Quality attributes also feed directly into the architecture assessment methods presented by Iasa and organizations like the SEI.
Decisions
Decisions are the heart of architecture. Understanding why a decision was made, how it impacts the solution, how it interacts with other decisions is the core of a great architecture. Being able to trace decisions to cost, benefit and outcome is the pinnacle of delivery and design. The ITABoK is centered on making decisions easier, more relevant and more timely. Decisions relate to requirements, quality attributes, views, structure and complexity, and architecture descriptions in their context.
Options
Decisions are the heart of architecture. Understanding why a decision was made, how it impacts the solution, how it interacts with other decisions is the core of a great architecture. Being able to trace decisions to cost, benefit and outcome is the pinnacle of delivery and design. The ITABoK is centered on making decisions easier, more relevant and more timely. Decisions relate to requirements, quality attributes, views, structure and complexity, and architecture descriptions in their context.
Requirements
Requirements management is a full art and science but what the architect is interested in are Architecturally Signficant Requirements. These requirements come in many shapes and sizes but the architect is interested in requirements that impact structural issues (mostly quality attributes), value (measurable benefits and cost), and constraints (standards, compliance, risk).
Business Case
The BTABoK is driven by a Stakeholder Led Approach which provides many tools for the architect and team to create a rigorous stakeholder community.
Objective Key Results
Objectives and key results is a technique used to derive measurements of success and goals on a specific set of capabilities and the enterprise.
Introduction to the Red Thread
The red thread represents the minimum architecture steps which provide traceability, rigorous decision making and value management measured against real business outcomes. This should be the minimum architecture applied to every product/project in an enterprise that meets minimum size/complexity requirements (for example maintenance work would not need this level).
Building an Engagement Model
What is essential in understanding the architecture engagement model and its relationship to digital transformation is that the architect team is the primary driver for true digital transformation. The team is not the only party involved in delivering such fundamental changes in the enterprise but is the core professional kernel of that activity.
The engagement model is divided into three primary rings which represent the architect team mandate, the components they use, and the outcomes that the enterprise will achieve achieve if the team delivers.
You may utilize the engagement model in two primary ways. First click on any element in the engagement model be taken to directly to that section. The second way is to use the navigation on the right to journey through the implementation of an engagement model.