Red Thread

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

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

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 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 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 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

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 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 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