IT value models must be designed to allow for three types of activities which do not traditionally play well together:
Valuation is the practice and delivery of value according to a clear and consistent set of rules and decisions. Value models include 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.
The purpose behind a 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.
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.
|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|
|Goal Setting||Goals||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|
The value model must be designed to allow for three types of activities which do not traditionally play well together:
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 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.
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.
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.
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.” 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 and innovation and disruption.” Architects are technologists as a whole and we 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 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.
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.
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.
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.
The diagram shown is based on work done by D. Rico’ in 2006 and provides an approach for thinking about how to describe the business value of IT. The areas most architects think about for describing value are around enabling new capability which helps a business make more money, or in rationalization projects that help with reducing the cost of existing IT. However, if we use the pillars listed above as a framework to consider different ways we can provide value, we can provide justification for projects that add value in other ways to the organization.
As we improve our skills at describing value in order to get projects funded, we can provide measurement tooling so the operations team can capture evidence based on metrics we describe and can capture additional evidence over time. Once we do that, we will provide the CIO the information they need to provide evidence of business impact delivered through IT. Through effort, over time we can shift attitudes about architecture and become involved in projects earlier in the lifecycle where we can have greater impact.
Determining the value may be on increased revenue or decreased cost, but may also be on less tangible value, like customer satisfaction and loyalty. As an architect, you need to calculate business value, and present and collect information on the value of IT and the value of architecture. For some, this feels like bragging, but it is not. It is simply showing the value you and your teams bring to the organization.
Here are some of the tools used to calculate value. As you can see, the calculations are not too challenging. The challenge comes in identifying the correct data to complete the calculations. Both staff architects and consulting architects may or may not have access to the financial data need to complete these projections, and more often are not required to provide these details.
However, we encourage you to grow you skill in this areas as it will be needed to advance your career, and trending suggests it will be required over the next several years.
If you provide a solution that will increase online penetration, you have to determine if the sales are new sales or will pull from existing sales and calculate the value to the company based on that data, not just the revenue stream generated through online sales.
Your intent should be to provide as realistic information as you can. Many times we are provided numbers or nebulous percentages to use in determining value. As you approach validating this information through discussion with the people that initially provided the data, consider researching similar or competitive groups to facilitate discussions.
Technology-focused people tend to feel technology has an innate value in and of itself. As you determine business value, you must think about the entire package, including people, process, usage, and technology. Reflect on the examples here.
How would you have sold a project to create Google Maps/Netflix/WhatsApp?
Leveraging historical information and providing tools to track results over time is valuable. For instance, if you created a portal solution for an existing sales staff, would you suggest the solution be monitored by tracking past and futures sales and comparing the change for people that started using the new portal versus those that did not?
Would you try to determine the impact of end user training based on traffic using new capabilities?
Financial value is most commonly calculated on project and larger components such as product perchases or tradeoff analysis between directions. It is normally calculated using simple cost and benefits numbers such as the following.
Kata: Figure out the MeasuresFind a recent email or presentation or webcast from one of your executives or one of your customers executives. Something where they describe the future of the company or their goals and what makes the company successful. Listen for their priorities, “We will be the top airline for customer service in the country.” “We will have a mobile workforce.” “We are going to grow our loans department in small and medium business” “We will have the most efficient manufacturing lines in the industry”Write a list of these expressions and figure out ways to measure them. Write down the measures and their outcomes.
The challenge with trying to describe value is in determining how value will be measured and where the value will come from. In the example, customers can complete a sales in person, on the phone, and online. The cost of sale online is least expensive and cost in store is most expensive.
This value category includes operational measures and stakeholder measures. These are business measures which are used by stakeholders to make decisions but which may not be directly related to financial outcomes. For example a customer survey done on the website or the time to clean an airplane are useful measures whether they are related back to financial returns or not.
To understand how to measure success in this category think about the way you would measure a successful manufacturing line. How quickly items come off the line? How many defects are there per 100 items?
Simplicity and reuse are one of the most commonly mentioned value categories but surprisingly little is known about how to measure them. Making something simpler is difficult to describe in relation to making it more flexible.
|Reduced Technical Debt||The amount of technical debt is the number of poor decisions which lock the orgaization into a single technology choice.||Measure technical debt as the cost to reverse a decision.|
|Increased Reuse||Reuse refers to the number of systems which utilize a single business or technical function.||Measure API level calls and which systems are dependent.|
|Insert Debt Request|
|Insert Debt Canvas|
Critical market changes are driven by technology innovation whether it is disruptive or incremental. The architect team should measure impacts and use innovation methods to look at possible market impacts. Competitive analysis tools and market trend techniques are invaluable.
Most government agencies and non-profits use separate tools from their for profit counterparts as they are not in the business to make money but to provide value to their citizen, stakeholder or mission. The do good category is used to describe value in these scenarios.
To be effective in growing and innovating in this space it is necessary to extend beyond the cost savings and reuse space and extend into the benefits space. To do this for a business case rate the business case on its target achievements and give them a score in relation to your overall mission. For example, at Iasa, holding an event for architects may get a value to membership rating of 2 (on a scale from one to ten) but the development of a accreditation for masters degrees in architecture gets a 8. These may be arbitrary scales but they will keep you focused on innovation as opposed to simple cost reduction.
We are just beginning to see agile value management techniques arise. One major issue to be addressed is the availability of architects at the agile team level. Value agile would require a signficantly larger number of architects. Optonally if the team is using an Extended Team model, the product owners and development leaders may be trained to do value management.
|Agile Value Story or Epic CardThese should use a system to identify the ASR in relation to a story and track it through the lifecycle.|
|Value KanbanThere is a way to show value in the pipeline.|
ITABoK 3.0 by ITABoK 3.0 is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.
Based on a work at https://itabok.iasaglobal.org/itabok3_0/.