Understand the Value Equation

 Posted by on Feb 22, 2011  Add comments
Feb 222011

Architects face many challenges in their jobs. Among them are creating architecture and applying architecture. I’ve said many times that creating architecture alone does not create value. Rather, the value from architecture comes when it is applied. In other words, value is delivered when architecture is used to influence the outcome of decision making, analysis, design, or implementation. Yet another challenge is that architects are often not the people who are responsible for doing the applying. So we face a conundrum: we don’t create value until someone else uses the architecture. That begs the obvious question of how to get other people to use the architecture.

The equation itself is really quite simple: if you make it easier for someone to do their job using architecture, they’ll use it. Although in concept this seems almost obvious, achieving it is really quite difficult. First, we need to understand what outcomes we are trying to achieve with architecture. Next, we need to understand what processes are involved (such as portfolio management, strategic planning, analysis and design, implementation) and what roles (people) are responsible for performing them. Then, we need to understand what perspective and skills the people with these roles have, and what the individual steps in the process are. Last but not least, we need to determine the steps in the process where architecture has the most leverage and opportunity to influence the outcome. Finally, we design an architectural deliverable (view) that supports those process steps, maximizes the leverage, and is meaningful to the person performing the process (their perspective).

This explains one of the most common reasons that architectures — even beautifully designed ones — often squander on a shelf, packaged as what one of my clients called “nice binders.” Although the architectures may be brilliant, they are not relevant or meaningful to the people who need to be influenced by them, or they are not in a format that makes them approachable, actionable, or useable. In short, they don’t provide value to the user. One common approach to this problem is to try and legislate the use of architecture through policy, regulated processes, and governance oversight. We all know how effective this approach is.

The opposite of the equation is also true. If architecture adds a burden to someone’s job, then they will figure out a way to get around it, something I’m sure you have all experienced. There are of course some subtleties to this set of ideas. Often, enterprise goals, compliance, operations, and so on, require changes that add additional steps to a process. Perhaps, well-defined architecture can relieve some of the pressure by reducing some of the additional burden. A slightly modified value equation, then, is that the value that architecture adds to a process (and the person performing it) has to be greater than any additional burden (work) that it adds.

This is also true with anything new or improved. The value of the new process or tool has to be great enough to make it worth switching from the old familiar one. A recent experience with an EA repository illustrates this point. The architecture team had collected information about servers, applications, operating systems, support (people and organizations), and so on, and populated a fancy IT repository tool with them. No matter how hard they tried, however, EA couldn’t get the operations and support people to switch from using their spreadsheets to start using the repository. The standard reports the repository tool produced weren’t very much different than what the spreadsheets provided, and the fact that the repository was more up to date just wasn’t enough.

In discussions with the different teams, we discovered information that the spreadsheets didn’t provide and that would be useful in making their jobs easier. Then, we created different custom reports specifically for the operations staff and for the support teams. Before long, both teams had switched to using the repository and were actively working with EA to enhance the information and reporting. The added value of the new system was greater than the learning curve, etc., of switching, and the new information it provided made their jobs easier. The moral of the story? Giving someone something new that’s essentially the same isn’t enough. If you want people to change, give them something that’s new, better, and makes their job easier. Apply the value equation.


Mike Rosen

Michael Rosen has more than 20 years technical leadership experience architecting, designing, and developing software products and applications.


  One Response to “Understand the Value Equation”

  1. I agree – understanding how architecture is valuable is a pre-requisite to doing it well.

    I think one of the values of an architecture is the way it establishes communication channels – the architecture ultimately matches the communication channels for a project. One thing that can therefore keep an architecture from adoption is if it proscribes sub-optimal communication channels among members of the team.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>