Working Draft

This site is currently a working draft of the ITABoK 3.0. Release date is planned for beginning of 2018. In the meantime please utilize the current ITABoK version 2.0 

Value Model

Description

Value model is the practice and delivery of value according to a clear and consistent set of rules and decisions. Value model includes the economic framework, operating measures as well as soft measures such as management preferences which are used to guide and deliver change in a company.

Traditional value management 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.

Practices

The purpose behind value model is to ensure the operating model of the transformation practice matches with the value model approach of the organization in question. A highly financial method of value management, 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.

Impact Areas

The value model approach will impact decision making in critical areas across the organization from strategic investment to capability based planning and product trade off analysis.

There are a number of decision types which must be considered as a part of the value management approach. The table below summarizes value impact areas in the operating model.

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

1. 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.
2. 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.
3. 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.

Goal Setting 101

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 goal types to work on for architect team maturity. Goals primarily fall into organizational goals, those that have value to the business or stakeholders and architecture team goals 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 and technical capabilities 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, do not 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 practice. Around the world there are teams crying out, “It is not about technology it is about the business.” 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 goals 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.

Recognize Perception

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

References

IT Value Network: From Investement to Stakeholder Value