We are in Public Review!
Welcome to the BTABoK 3.0 (formerly known as the ITABoK), the next release of the BTABoK focused equally on business and technology for architects. We are taking feedback for the full release and are now entering the review cycle so we welcome your comments. The previous published version can always be accessed at ITABoK version 2.0
Benefit: ‘an advantage or profit gained from something’
calculated using Benefit = Value – Cost (See Value Methods)
- an act of becoming fully aware of something as a fact
- the achievement of something desired or anticipated
- the conversion of an asset into cash.
The process of organizing and managing, so that potential benefits, arising from investment in change, are achieved
Benefit is a measurable improvement resulting from an outcome which is perceived as an advantage by a stakeholder
Benefits are anticipated when a change is conceived.
Value methods are the techniques in benefits realization (BR) that feed the economic framework, operating measures, as well as soft measures such as management preferences, which are used to guide and deliver and measure positive change in a company.
Traditional value based approaches used cost accounting, return on investment and other financial measures to value decisions and activities and compare options for investment or action. They use financial value methods to decide between two or more activities.
When the article refers to value model, it is referring to the set of repository elements or stored tracking of a value register, the set of tools used to create them. Value methods are on the other hand the techniques used to derive them. Benefits realization is the overall approach to managing the outcomes, costs, benefits, and value methods in use by an architecture practice.
If there is no benefits management:
- Lack of proven benefits realised
- Poor benefits identification planning
- Inappropriate investment decisions
- Inability to set priorities
- Lack of alignment
The purpose behind a benefits realization is to ensure the capability model of digital transformation creates value for the organization in question. A highly financial focused value model for example, would likely be too formal and weighty for a lean startup or a company the values independence and operating outcomes with direct line management control whereas a bank or larger architecture practice will likely lean towards more financial measurements. In addition, governments, non-profits and charities focus more on a mission based set of models to understand value.
The value method approach will impact decision making in critical areas across the organization from strategic investment to capability-based investment prioritization and planning and product trade off analysis as well as even many of the most technical decisions. As the architect organization matures it will find these methods necessary and will become adept at tracing value created throughout technology strategy and execution.
There are a number of decision types which must be considered as a part of the value method approach. The table below summarizes value impact areas in the operating model.
|Decision Point||Impact Area||Description|
|Innovation Threshold||Innovation Lifecycle||The decision to invest in a particular innovation for the organization.|
|Portfolio Investment||Strategy, Portfolio||Management of portfolios of investments.|
|Capability Investment||Business Capability, Technical Capability||Capability based value analysis|
|Objective Setting||Objectives||Decisions to contribution and measurement|
|Product Investment||Business Case, Product||Product based value analysis|
|Architecture Component Selection||Solution Architecture, Design||Component based value analysis and selection|
|Product Optimization||Simplicity, Automation||Product optimization decisions|
Innovation, Transformation and the Long-Term Work Together
The value model must be designed to allow for three types of activities which do not traditionally play well together:
- Disruptive Innovation and Experimentation: Value model is experimentation driven, where the search is for long-term new revenue or value sources or paradigm change in non-revenue focused environments. Value model should target goals and capabilities which are extremely fast-paced and dynamic using lean and startup approaches. The people model should be balanced toward toward high risk appetite and comfort with uncertainty.
- Strategic Long Term Roadmaps: Value model is portfolio and product driven with a strong focus on achieving cross organization roadmap milestones and capability advancement across a balanced portfolio of work. Value method techniques focus on measurable outcomes over stable periods and should use financial and operational measures primarily. People model should be risk-averse and focused on structural and integration based approaches.
- DevOps Style Incremental Innovation and Product Features: Combines methods for one and two to create ownership at the edges of technology delivery. Value model should primarily focus on fast-paced product team measurements with the focus on feature outcomes for customers. Requires a large pool of architects or a well educated extended team.
Value models can differ drastically between each of these types of activities and maybe drastic enough to warrant different engagement models for each if the architecture team can handle the scale and complexity of multiple engagement models (maturity model should be well established at level 2+). The architecture lifecycle and formal engagement model approach allows for differing value models based on an organized approach to product and program value streams and capabilities.
Architecture teams must communicate and understand their value model through common goals. Goal setting is a fundamental priority for the team both at a team and an organizational level. There are a number of objective types to work on for architect team maturity. Objectives primarily fall into organizational levels, those that have value to the business or stakeholders and architecture team objectives which are based on engagement model outcomes to further the maturity of the practice.
Integrate and Stretch Capabilities
Organization capabilities have taken center stage as a primary architect tool and artifact. Both business capabilities and technical services help a company understand its primary and secondary business model and connect with customer journeys, business processes and employee activities to ensure the maximization of value streams. It is essential that the architect team lead towards business and technical capability outcomes using roadmaps and other strategy planning and portfolio tools.
Attack the Enterprise
One cannot lead if one does not win. The architecture team has a primary responsibility to the shareholder and the customer/citizen/soldier. If the team doesn’t know how to lead then it will be forever relegated to the backwaters of IT or operations. The first rule of architecture practice is to drive the enterprise, not just respond to it. The goal of the practice is to maximize business technology strategy and to do so visibly and with value management and measurement at the forefront.
Understanding scope, coverage and context from a value model allow the architect team to develop a plan which includes growing influence throughout the organization, managing and owning decision rights in appropriate ways and building a practice which focuses on the most important things first. Scope, coverage and context are the building blocks of a mature and goal driven practice.
Disentangle IT From Technology Value
There is much argument about the role of technology in architecture practices. Around the world there are teams crying out, “It is not about technology it is about the business.” The correct translation or one that does not cause as much confusion is ‘It is not about internal IT optimizations or optimizing the technology stack for cost or technology that does not create value. It is about digital transformation and technology advantage over competitors with innovation and disruption.” Architects are technologists as a whole and they should never move away from that value proposition.
This statement is correct in many ways but has many high costs for an architecture practice if it is used to disenfranchise the team from the business practice. The situation appears to arrive through the experience of many teams who have dealt with titled architects with no business skills. However, this can often backfire quickly if the teams retreat from technology all together. It is essential that pure business-focused architects and pure-technology focused architects find common ground in the engagement model. If not, it is likely that one or both will fail.
Architecture teams must be masters of technology strategy as measured through customer, operations and business outcome metrics. Measurement of objectives and strategic outcomes with a clear line of relationships to both pure business as well as technology driven outcomes using tools like the business dependency network allow the architecture team to side-step this explosive issue. The value methods and value stream focus of the team combined with clear business case evaluation will alleviate this symptom of low maturity organizations.
Embark on a Value Plan
Evidence suggests the architecture team will succeed or fail together regardless of specialization or reporting structure. Building a value method around measurable objectives and team goals should be the top priority in establishing an engagement model.
“All value is local” and “Perception is reality” are two expressions which often define the difficulty architecture teams have in establishing a value plan. The team has any number of direct stakeholders and even more indirect ones. Recognize that perception is the primary step in creating a value model which succeeds over time.
To impact perception work through a branding exercise with the entire architect practice, if small, and representatives for each of the practices if large. Measure the value brand through direct stakeholders first by using a simple stakeholder survey or anecdotal interviews. Implement a branding policy which takes in the feedback of each architect and can be codified in a simple expression and update this on a regular basis, but a minimum of once a year. This branding exercise will allow each architect to clearly define their personal focal points and goal contributions.
Using Value Methods Properly
Value methods, such as ROI, Strategy Scorecards, Discounted Cash Flow, and all the others are tools to align outcome thinking with day in and day out delivery. The impact of value as the primary language of architects cannot be fully described here. They create buy in and change the thinking and practice of the organization in many ways. It is very difficult to argue for a particular technology investment when it can be shown to have massively lower ROI than another choice. They help create dashboards and metrics which give shape to particular strategic investments and they help influence decisions and the way they are made. Using value methods requires both patience and inventiveness as they require the application of inexact data and guess work. It is essential when developing a practice to continuously review value methods which work for both outcome accuracy as well as communication and abandon those which create confusion or are overly complicated.
Balance Quality, Quality Attributes and Cost
Quality and cost are two very powerful tools in an architecture teams value model. They are both easy to talk about and relatively easy to measure. Performance, a quality attribute, may be measured exactly in most cases, and it is easy to agree that performance is a beneficial quality attribute of a system. Cost reduction too is easy to measure and describe as valuable. However, be very careful that these value methods fit as the most appropriate measures for the architecture team to use. It is very easy for quality and cost reduction to become the teams primary brand which would be ridiculous in a startup or innovation focused engagement model. In addition, the engineering team, quality assurance team, infrastructure team and many others in the technology group already lay claim to quite a bit of ownership in this space. To be value focused is to focus on new value creation. There are extreme situations where quality, delivery and structural safety are so bad that the architecture team must focus their first, but to fulfill their primary professional mission they must retain or acquire a focus on new value and business models not just engineering excellence and optimization.
Before launching into methods of defining, measuring and articulating value, a short review of key basics of valuation is required to establish a foundation.
The Balance Sheet
A Balance Sheet is one of the 3 fundamental components used to evaluate the financial aspects of a company or business unit. The balance sheet displays the total assets against how those assets are financed and shows the financial position of the company or business unit at a point in time. This point in time is typically the end of an accounting period but could be used to reflect the financial position at any time. As such, it is critical for accounting and financial modeling purposes.
The balance sheet is divided into two sections. The basic structure is Assets = Liabilities + Equity, although it often becomes more complex. Thinking of it as a proper equation is useful as any transaction will end up changing both sides.
Assets represent money invested and generally include:
- Cash and securities
- Plant, facilities and equipment
Liabilities represent that which is owed to external parties. Equity is what was financed by the owners or shareholders directly.
Example balance sheet:
The Income Statement
The second of the core artifacts for financial assessment is the Income Statement. The statement shows a company or business unit’s profit and loss over a period of time. Included in this report are the revenues, costs, gross profit, sales, marketing and other administrative expenses, other expenses and income, taxes paid and net profit.
The basic structure of the Income Statement is Revenue – Expenses = Net Income.
Different from the Balance Sheet, the Income Statement shows income and expenses from all business activities over a period of time. Generally, this period matches the accounting period used on the Balance Sheet but may be generated at any time. This ‘rolling’ time period view is important to understand since some expenses (e.g. cost of goods sold) may not line up with revenue from sales in the same accounting period. The revenue isn’t recognized until it is actually earned. Additionally, some expenses are not just cash outflows but may represent longer-term costs such as depreciation.
Example Income Statement:
The Cash Flow Statement
The third core financial artifact of any business is the Cash Flow Statement. This document reports the cash generated and spent during a specific time period (usually a quarter or year). It acts as an important connection between the Balance Sheet and the Income Statement in that is shows how money is moving into and out of the business.
here are three sections comprising a cash flow statement. These sections detail the Operating Activities, the Investing Activities and the Financing Activities. Operating Activities deal with the revenue generating activities of the business (i.e. cash flows from assets and liabilities). Investing Activities detail cash flows from long-term assets and other investments. Financing Activities deal specifically with cash flows resulting from borrowing (loans) or equity (bonds, stocks, dividends).
Example Cash Flow Statement:
Other Common Financial Measures
In addition to these three core artifacts, there are other dimensions to financial reporting typically used by businesses when discussing financial health or planning. Many of these are generally used at a company-wide level and include things such as:
- Gross Profit Margin (or Gross Margin)
- (Sales – COGS) / Sales
- Net Profit Margin (or just Profit Margin)
- Net Income / Sales
- Financial Leverage
- (Liabilities + Owners Equity) / Owners Equity –OR–
- Total Assets / Owners Equity
- Cost of goods sold
- Labor costs
- Hardware / capital costs (depreciables)
- Other operational expenses (Can include other services and/or software)
- Cost of time
- Cost of capital
These are all interesting metrics. For the Architect, however, one set of measures comes in to play more frequently. These are measures of Capital Expenditure (CAPEX) and Operational Expenditure (OpEx).
It is important to understand the difference between CAPEX and OpEx:
|Capital expense||Operational expense|
|In through put accounting||Money spent on inventory||Money spent turning inventory into throughput|
|In technology||Costs incurred delivering the solution||Costs associated with operating and maintaining the solution|
|Definition||Capital expenditures are expenditures creating future benefits. A capital expenditure is incurred when a business spends money either to buy fixed assets or to add to the value of an existing asset with a useful life that extends beyond the tax year.||OpEx refers to expenses incurred in the course of ordinary business, such as sales, general and administrative expenses (and excluding cost of goods sold – or COGS, taxes, depreciation and interest).|
|Also known as||Capital Expenditure, Capital Expense, CAPEX||Operating Expense, Operating Expenditure, Revenue Expenditure, OpEX|
|Accounting treatment||Cannot be fully deducted in the period when they were incurred. Tangible assets are depreciated, and intangible assets are amortized over time.||Operating expenses are fully deducted in the accounting period during which they were incurred.|
The Basics and Value
Companies or business units use these basic financial analyses to measure and report their financial health. These artifacts are also often used to illustrate delivery of value: “Revenue for 2019 increased to $200K due to the SuperWidget being delivered for a cost of $96K. Our SuperWidget team delivered $104K worth of value to the company!”
But this doesn’t tell us that the Development team produced $104K in value or the Sales team did. Merely that the initiative that produced the SuperWidget ended up making more money than it cost.
When it comes down to a specific group within a business, or perhaps a specific initiative, many of these ‘macro’ measures don’t make as much sense. And they can become very subjective measures of who added what value to the company.
Architects can’t solve that problem. But Architects can absolutely define the value that they bring to an effort, help to measure that value and then articulate that value.