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.
Sorry,You have not added any story yet
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.
Introduction
The red thread represents the minimum architecture steps which provide traceability, rigorous decision making and value management measured against real business outcomes.
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. Resources Goals – this article outlines the use of OKRs and KPIs to drive outcomes. Value Management – this article describes methods for describing and deriving value Learning shot
Business Case
The business case provides a codified set of benefits, costs and considerations for a product/project. The ITABoK uses a lean business case tool called the NABC (need, approach, benefits, considerations). This tool is used as an input to prioritization and roadmapping though there is considerable overlap and concurrency in their development. In addition LBC take inputs of benefits and costs estimation. Resources Investment Planning Article Assignment Article Value Methods Article Investment Prioritization LS Valuation LS
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). Resources Article Learning Shot
Options
Options are included hear separately but form part of the ITABoK Design Triumvirate (requirements, options, decisions). Understanding and identifying options for a particular design decision is a part of understanding the industry and maintaining and healthy current knowledge base of available technology and strategy offerings. We have included a modern architecture landscape which includes options and technology impact areas to help design. Resources Design article Views article Requirements article
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. Resources Decisions article Deliverables article Structure and Complexity article Architecture Descriptions LS
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. Resources Quality Attributes article Technical Debt article Requirements article Requirements LS Architecture Assessment LS
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. Resources Views article Design article Deliverables article Context View LS Architecture Description LS
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. Resources Agility article Velocity article Value Streams article Agile at Scale LS DevOps LS
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. Resources Benefits Realization LS
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.
