Defining Value in Architecture

(Editor’s Note: This is part two in a series of four articles that will appear each Monday. Lockhart is a Director at Point Management Group.)

Today’s world of business technology is driven by the overriding quest for delivering Value. Value comes in various forms but is often denoted in dollars saved or earned. For example, the Product Development function generates value by creating useful goods for customers to buy while the Sales and Marketing function is seen as creating value by ensuring these products and services are sold to the right customers at the right time. Product ABC generated X dollars in revenue against cost of goods sold and earned a profit of Y dollars. Easy. Straight forward.

But what about business functions that are perceived to have no direct relationship to value creation?

From a business perspective, Architecture is rarely seen as contributing to the creation of value. In fact, it is frequently viewed as a drag on value creation. A value sinkhole, or cost center, potentially even one that slows time to value.

This has several causes. Among them are some architects’ penchant for philosophical ‘ivory tower’ thinking, various overzealous attempts at governance and control that slows product development, the perceived lack of actionable Architecture work products, overreliance on complex frameworks and models and what often appears to be no quantifiable ROI. In short, the business often believes Architecture costs too much, takes too long, delivers nothing tangibly useful and interferes with activities that do (e.g., Product Development).

The reality is that Architecture is not a business function and doesn’t show up as a plus or minus in the value equation. It is a discipline th at impacts how well each of the business functions that create value are performed. Bad application architecture results in bad Development outcomes which impacts the value of the product or service delivered. No one wants to buy bad products. Revenue isn’t what it could have been. Better Architecture would have increased the quality of the product. Better products leads to increased revenue. With this as the lens, Architecture is revealed to be directly tied to delivery of value.

Architecture as a business discipline creates value. And this holds true whether it is Enterprise Architecture, Business Architecture, Software Architecture, Information Architecture, Integration Architecture, Infrastructure Architecture, Security Architecture, or any other form of Architecture. Wherever the Architect is practicing his or her craft, the chances that value will be realized go up. Way up.

Why does this matter? Why do we need to recognize and better define and articulate the value that the Architecture profession brings to business?

Because everyone wants better business and technology outcomes.

The reality is that stronger Architecture results in better outcomes. It is therefore incumbent upon Architects to understand how to identify, measure and articulate the value they provide that ultimately drive better outcomes.

One cannot measure what has not been defined. Therefore, begin with defining the value an Architect brings to the table.

As mentioned earlier, an Architect’s value is related to the rigor or discipline that their activities impart to the effort in question. It isn’t as simple as saying “A logical architecture is worth $5K of value,” however, it is possible to look at the activities performed by the Architect to help get to an answer.

What are the architects’ activities?

Depending on the context, the business function, and the company in question, an Architect may be performing many different tasks. They may not all be related to the Value Story, but at the highest level we can say that an Architect’s activities and work products seek to improve the overall performance of a function. These activities are performed in some fashion and in varying degrees by all types of Architects and can be bundled into several key meta-activities:

1. Describe the Context of the Change

• Why is change needed in this context?
• What is happening in the market/business/program/application that is driving this change?
• What does this change affect?

2. Define the Improvement

• What is being changed?
• What does the current state look like?
• What will the target state look like? (i.e. How will it be changed?)

3. Collect the Data

• What will it take to make the change?
• What are the costs (financial, performance, quality, resources, time, functionality)?
• What are the benefits (same possible aspects as above)?

4. Perform the Analyses

• How well do the proposed changes meet the need? (i.e. What will success look like?)
• Are there alternative options for making the change?
• What are the costs vs. benefits over time?
• What are the associated risks of making or not making the change?

5. Report the Results

• How will this change be explained to stakeholders?
• What does this change tell us about other changes? (i.e. What is being learned?)
• Is this change actually achieving the desired outcome?

In the development of an engagement model these activities are called ‘The Red Thread’ and are included in the Design Traceability as well as Business Technology Strategy competencies.

If these activities are not performed, or not performed well, the overall effort in question will suffer and expected benefit may not be realized. The Architect delivers value by executing these activities themselves (e.g. developing solution architecture) or ensuring that someone else executes them according to a standard (e.g. governance, analysis and extended team).

If the Architect performing these activities results in better outcomes, but there isn’t a measure for how much each activity is worth to the effort in dollars, how is value defined?

What is it Worth?

The word ‘value’ itself has some problems in this context. The main issue is that value can be extremely subjective. What is of value to one Director of Application Development may not be of value to a Senior Manager of Risk and Compliance both stakeholders then have differing perspective on value for initiatives.

For this reason, architects need to be looking at outcomes when we are defining value. Outcomes in the BTABoK are defined using objectives.  Acceptable or expected outcomes of an effort will be core to the effort, defined up front, and will provide the standard against which to measure for value.

To apply a formula to the Architect and their activities, the outcomes reflect the result of the effort in question as a measure against the cost of that effort against the time to achieve that effort. In effect, value is defined as follows:

Value Aspect	Attributes
Did we do what we said we’d do?	What were the expectations (OKRs, KPIs) for the effort? Were they achieved, not achieved, exceeded? Are they quantitative or qualitative in nature? KPI’s may reflect a level of quality, performance, growth, reduction, be denominated in dollars, time, people… in effect KPIs and OKRs are complicated
What did it cost?	Costs incurred delivering the change Costs required to operate and maintain the change New costs resulting from the change Hidden costs (brand, morale, reputation, etc.) Costs include hardware and software, people, office space,  other overhead costs (electricity), OpEx, CapEx… this is where understanding the fundamentals of valuation are so necessary for Architects
How long did it take?	Time to deliver versus the expectation laid out as part of the KPIs The impact of being behind or ahead of schedule (for the entire effort, for just a phase of the effort) Must include all lifecycle phases (e.g. Plan – Build – Deploy)

Each of these components of value will have differing units of measurement associated with them depending on the context.

But this definition of “Value” is for the value of entire effort and doesn’t reflect any individual role’s part in delivering that value. How do we represent what part the Architect is playing for each Value Aspect? How does the Architect is contribute to the overall delivery of Value?

Value Aspect	What is the Architect Contributing?
Did we do what we said we’d do?	Create and/or Review Business Case Manage and Prioritize Initiative Portfolio (Investment Prioritization) Risk/Compliance Analyses and Assessments Capture and Analyze Architecturally Significant Requirements Reference Architectures: Master, Context, Product-Specific Specialists in the Architecture Practice: Solution, Security, Data, Integration, etc. Capability Models (Business Capabilities, Technical Services) Standards and Frameworks (Principles) Define and Articulate Solution Options (Decisions) Objectives (Key Performance Indicators / Success Metrics) Stakeholder Alignment
What did it cost?	Cost/Benefit Definition and Data Collection Cost-Benefit Analyses Standards and Frameworks (For Financial Analyses) Workforce Management Analyses Budgeting Financial Management and Reporting
How long did it take?	Roadmaps Sequencing and Prioritization Governance (Reviews, Toll-Gates) Stakeholder Communication Engagement Models

The Architect doesn’t deliver value simply by drawing a Technical Services Model for the SuperWidget product. After all, if it were a bad or confusing or incomplete diagram it wouldn’t be viewed as adding value but probably the opposite. The value is not in the drawing itself but in the information that it captures, the manner in which it codifies that information and the clarity with which it conveys it to stakeholders.

It is the quality of the work product  delivered (or activity performed) by the Architect that determines the degree of Value they contribute to the overall effort. It is these work products, or activities, that capture, codify and convey that help determine the overall outcomes. The better these are, the more positive the outcome, the more Value delivered.

Which begs the question, how do we measure that?

 

Next Article: “Measuring Value”