"Value chain analysis is gaining new credibility as a potential key approach to understanding the business better for the purpose of enabling it through IT."

Opening Statement

THE LONG MARCH TOWARD BUSINESS-IT CONSENSUS

Before we talk about value chain, which is the subject of this issue, I would like the reader to bear with me as I go back up to cruising altitude and take a broader view of the earth under us. While this will make this opening statement longer than usual, I hope the context-setting will be useful.

Since the beginning of the millennium, if not earlier, we found that we could no longer take for granted that businesspeople would authorize and fund IT projects. This was in part because they had seen too many projects that failed to provide value for the money; in part because they had seen too many large projects fail, period; and often because the proposals were not expressed in ways the business could easily understand. After years of trusting that "if it uses a lot of three-letter abbreviations and sounds complicated, it must be good," decision makers swept this assumption away and asserted their rights. Thus, we have spent part of the last decade, certainly the second half of it, talking about "aligning IT with the business."

This sounds good. In fact, it sounds a little too obvious to be of real use in practice. It is also rather disparaging to imply that (1) IT people didn't originally care to create capabilities based on their value to the business, as if they didn't know where their paychecks were coming from, and that (2) IT has all the responsibility for the alignment, while the businesspeople (CEO, CFO, line-of-business presidents, etc.) have no responsibility to educate themselves about what new technologies would allow them to do.

During the 1990s, the formative years of software engineering methods, use cases were supposed to be a key artifact that would allow a system to meet its users' needs. But requirements and justification are not the same thing: you can start drawing the little stick figures once a project has been kicked off, but use cases do not demonstrate that the system is needed in the first place. So we had to face the two dreaded abbreviations: TCO and ROI. Except that once again, the situation was very biased: businesspeople, especially CFOs, would ask IT to calculate the TCO of a system or the ROI of a project, when in fact this should have been a team effort. It's fair to ask IT to consider and estimate all the costs, but it's up to the business to "dollarize" the benefits. It became a sad joke among IT people after review meetings: "They asked us to calculate the ROI" became synonymous with "they just want to kill this project."

Over time, in response to these pressures, we developed a certain general understanding that there is a hierarchy of concerns, with different degrees of involvement from IT and from the business, which forms a continuum and should help us understand the relationship between IT capabilities and business outcomes. While there is no strict consensus on this hierarchy yet, it generally resembles this:

• Business architecture -- the articulation of concepts that are strictly related to what an organization aims to do, how it is structured, and how it operates regardless of the underlying technology

• Information architecture -- the key pieces of information used to model the business and how they relate to each other

• Technology architecture -- the platforms, networks, software applications, and IT management practices that allow business users to create and access the information in order to do their work

The term "enterprise architecture," which originally sounded like a technology-oriented term, is in many cases now seen as the proper designation for the sum of these three pieces. This is evidenced, for example, in the US National Institutes of Health's IT Enterprise Architecture Framework.¹ But it is also the view of The Open Group Architecture Framework (TOGAF), in which business architecture is the second of the eight steps in its Architecture Development Method (ADM).² And the urtext of enterprise architecture, the Zachman Framework,³ has one row called "Business Model." Like the other rows, it is divided into six columns: What, How, Where, Who, When, Why.

Some of the TOGAF wording about business architecture is useful here and will help us get back down to the specific subject of this issue:

A knowledge of the Business Architecture is a prerequisite for architecture work in any other domain (Data, Applications, Technology).... In practical terms, the Business Architecture is also often necessary as a means of demonstrating the business value of subsequent Technical Architecture work to key stakeholders, and the return on investment to those stakeholders from supporting and participating in the subsequent work....

In some cases, key elements of the Business Architecture may be done in other activities; for example, the enterprise mission, vision, strategy, and goals may be documented as part of some wider business strategy or enterprise planning activity that has its own lifecycle within the enterprise.

So far, so good. But when the ADM gets more specific in a section entitled "Business Modeling," it curiously limits itself to types of models that are rather traditional and, more importantly, that have not demonstrated a great ability to generate a dialogue between the business and IT. Specifically, it refers to:

• Activity models (also called "business process models")

• Use case models

• Class models

The question is the right one: "What are the ways in which one can represent essential facts about the business so that everyone, including IT, knows what to do to make the enterprise run well?" But the answer is probably not use cases and class models. Instead, it appears that there are three approaches that claim to provide (by themselves or in conjunction with other methods) this actionable description of the business:

1. Business process management (BPM), or perhaps more specifically business process modeling and business process improvement. By listing this discipline here, I am in agreement with TOGAF. Business process modeling -- or rather its predecessor, workflow modeling -- was already practiced 20 years ago, although at that time it only served to produce graphic documentation for human use.

2. Business capabilities, which are really the "what" of the business, while business processes are the "how." In recent years, we have seen the emergence of a cottage industry devoted to business capability analysis -- and we've also seen the usual marketing hype. However, some companies have developed a business architecture discipline based on the analysis of capabilities; for an example, see SenseAgility's "Capability Based Business Architecture" offering.⁴

3. Value chain analysis is closer to the "why" of the business -- it goes back to the fundamental idea that a business exists to create value, and that you should be able to trace how this value accumulates over the course of certain processes. If something does not contribute to value, it can be eliminated or streamlined, a premise that is the root of various "lean" approaches. The seminal work on value chain is Michael Porter's 1985 book Competitive Advantage,⁵ which our authors reference throughout the issue. The Internet Center for Management and Business Administration provides a quite readable synopsis of Porter's work.⁶

THE ROLE OF VALUE CHAIN IN THE BUSINESS-IT DIALOGUE

Over the past several years, when industry observers searched for the causes of IT's frequent failure to deliver what the business required -- which may have been a capability that enabled new business, or one that allowed the business to adapt to changing markets -- they arrived at several sobering realizations:

• It is not just that IT was delivering systems badly (overschedule, overbudget, with poor quality), but also and even more seriously, IT had been delivering the wrong systems.

• The methods used to elicit requirements from the business were often not working well enough. Even though we claimed that UML use cases were designed to be written by the end users and would prevent the errors made in interpreting textual requirements, the reality is that they often were just IT people's interpretation of what the businesspeople had told them using ambiguous language.

• In many cases, the business didn't really know what it wanted to do, or there were multiple contradictory opinions, yet the pressure was on to deliver some system that would fulfill this imprecise need.

Thus, the quest has continued for ways to describe a business that can drive effective initiatives, both purely at the business level and in terms of fostering effective IT initiatives. "Effective" means several things:

• The initiatives and resulting systems are understood by business stakeholders.

• They likely impact the bottom line by generating more revenue, reducing costs (especially by simplifying processes), or both.

• The projects are cost-effective versus their bottom-line impact -- something that is usually measured in terms of a "hurdle rate."

It is still rare for a business to produce explicit models that can drive this alignment. The most frequently used discipline in recent years has been business process management (or at least its front end, business process modeling). There is ample literature on this, including the two 2010 issues of Cutter IT Journal we devoted to multifaceted coverage of BPM (Vol. 23, Nos. 2 and 5). Another approach, still novel but gaining traction, is capability-based business architecture, often practiced by small and medium-sized consulting companies.

Value chain analysis, which has been recognized since Porter's Competitive Advantage appeared, is gaining new credibility as a potential key approach to understanding the business better for the purpose of enabling it through IT. Cutter's BPM Glossary defines value chain as "the series of activities through which value is added to the product or service ultimately delivered by an enterprise to its customer. Customer value is the key concept, with value chain analysis being used to determine what activities do not add customer value in order to eliminate or streamline them."⁷ This has multiple implications: value chain analysis can help prioritize where IT needs to focus resources; it can help calculate the ROI of projects; and it can streamline the IT portfolio by eliminating some activities rather than letting them continue to consume resources.

There is a significant camp among business architects that uses Porter's value stream, value network, and value chain concepts. Six Sigma methodologists use the Suppliers, Inputs, Process, Outputs, Customers (SIPOC) diagrams, which are a form of value chain representation. For the late Geary Rummler, a BPM pioneer and early proponent of many of the performance improvement methods we know today, the processing system hierarchy consists of:⁸

• Enterprise or business model

• Value chain

• Primary processing systems

• Process

• Subprocess, task, subtask

More generally, different practitioners use different views of the business. Some of these views represent alternate approaches: as a user, you have to choose one. But some views may also be complementary: they might correspond to the viewpoint of the manufacturing VP versus that of the CFO, for example, and you need both. The dust is still far from settled in terms of understanding and agreeing on what models should be included in a value chain-driven architecture.

Porter did not invent the value chain concepts in order to facilitate business/IT alignment or integration; he did so in order to enable business executives to understand how to make their companies more competitive. In 1985, one could honestly say that a company that made products was dependent on the excellence of the five primary value chain activities shown in Porter's basic model (Inbound Logistics, Operations, Outbound Logistics, Marketing and Sales, Service). But since then, the Internet happened, we had an information explosion, and we needed to automate more and more processes. Surely, then, the IT capabilities of the enterprise are much closer to the core value chain of the organization nowadays than they were when Porter wrote. It should follow, therefore, that the value chain approach could be key to justifying and assigning value to IT initiatives -- or, as I should probably say, to business initiatives, of which IT is an essential component.

The EA2010 Working Group, a subset of the OMG's SOA Consortium, wrote in its 2010 paper Business Architecture: The Missing Link Between Business Strategy and Enterprise Architecture ⁹ that:

To reap the benefits of business architecture -- business visibility and agility -- the business architecture must reflect the entire business design, from the point of view of business designers and owners, rather than IT solution delivery. This point of view begins with business motivations, includes key business execution elements -- such as operating model, capabilities, value chains, processes, and organizational models -- and transcends information technology representations, such as business services, rules, events, and information models.

Subsequently, the same paper talks about formal representations of a business architecture in those terms:

Business architecture is formally represented via a variety of artifacts, including business motivation models, capability maps, value chain maps, process models, policy documents, organization charts, and product catalogs. The techniques used to produce and manage these artifacts vary by situation. Organizations focused on eliminating waste may employ Lean practices, while organizations focused on competitive advantage may employ value chain analysis.

This may still sound academic, but a good case study is that of Pfizer, the pharmaceutical giant. Its business architecture is represented as a hierarchy of levels. At the top are value-added chain diagrams, of which there are between 20 and 30. The next level consists of function trees, collectively containing a couple thousand individual functions. Finally, the lower level consists of event process chains, which are an early notation for business process models that predates the emergence of Business Process Modeling Notation (BPMN). And finally, IT capabilities are the enablers of specific process models.

More ideas about and experiences with the use of value chain concepts were presented during the "Value and Innovation Day" held during the OMG's Technical Meeting in Santa Clara, California, USA, in December 2010. In fact, it was during this meeting that the idea of devoting an issue of Cutter IT Journal to the use of value chain analysis was born. Three of the presentations made that day are relevant to our discussion and complement the articles in this issue:

1. Arne Berre of SINTEF, the largest Scandinavian research organization, proposed to apply some of the techniques used in defining a service architecture, in particular the SOA modeling language (SOAML), to value chain concepts. He also showed how the UML collaboration diagram can depict the interaction between participant roles. He pointed out that UML version 2 has a concept of "ports," depicting how UML components connect. These connections can represent entities such as "order placer" and "order taker," and when you connect an output of one component to an input of another, you are representing the fact that value is exchanged. Berre also highlighted an interesting example of a tool largely dedicated to modeling and manipulating value chains, e³-value,¹⁰ developed by Jaap Gordin at the University of Amsterdam. According to Alexander Osterwalder, the self-described "business model alchemist,"¹¹ the e³-value tool allows you to:

   • Draw, model, and represent business value networks graphically

   • Easily share these drawings among decision makers to foster discussion

   • Rapidly redraw specific elements of the value network based on the discussions

   • Make several different business prototypes (i.e., model different possible value networks)

   • Automatically generate the revenue and profitability for each business prototype and test different assumptions.

2. Cutter Senior Consultant Verna Allee developed a method to visualize value networks back in 1993. She said that people mostly think about processes and value in a linear way, similar to an industrial assembly line. Therefore, neither Porter's value stream maps nor business process diagrams are fully adapted to the new networked models of value creation. Instead, she proposes a "value network analysis" that "makes the intangible visible, negotiable, and manageable." It discovers how the work actually gets done and how efficiently an organization converts resources (inputs) into deliverables (outputs). The methodology has been used at AT&T, Telenor, the Mayo Clinic, Boeing, Rolls Royce, Cisco, and a number of health, local/regional government, strategy, and nongovernmental networks. A value network model looks a bit like a social graph, except that the nodes represent roles, not specific people.

3. Fred Cummins presented an overview of the Value Delivery Metamodel (VDM) effort being undertaken by OMG. There is no need to describe it further here, as Cummins and Henk de Man have contributed a more complete description in one of the articles in this issue.

FOUR POINTS OF VIEW

In this issue of Cutter IT Journal, we aim to shed some light on how value chain relates to both business architecture and enterprise architecture, and as a result, how it can contribute to aligning or integrating business priorities and IT programs. In the following articles, six experts from varied backgrounds will help you understand and explore the contribution of value chain. Their analyses provide guidance to those who are seeking a different way to revive or reinforce the dialogue between the CIO and the rest of the C-suite, or to ensure that the portfolio of business systems, as well as infrastructure projects, uses business imperatives rather than the appeal of new technology as its justification.

We start with Cutter Senior Consultant William Ulrich and Neal McWhorter, who incidentally are the cochairs of the OMG's Business Architecture Special Interest Group.¹² In their article, they first point out that service industries have struggled with the original Porter value chain, which seems to imply that there is a physical product being pushed through a sequential manufacturing process, and that this has resulted in James Martin's concept of a "value stream." They explain how the customer or stakeholder focus of value stream analysis enables and guides strategic transformation. They also provide a hierarchical mapping between value streams, business capabilities, and business processes.

We continue with Ralph Whittle, who describes the enterprise business architecture (EBA) he wrote about in his 2005 book¹³ and how EBA is leading practitioners to rediscover value chains and value streams. He talks about "integrated value streams," which he equates to "core cross-functional business processes" and which some of us also call "key end-to-end processes." By doing that, he provides a unified view of BPM, value streams, and business architecture. Whittle's detailed diagrams of value stream components provide a concrete example of how organizations might go about analyzing their value streams to build a composite business model.

Kraig Parkinson, like Ulrich and McWhorter, explains why neither value chain analysis nor business process modeling is enough, and he invites us to consider "value stream thinking" instead. Parkinson then describes in detail the properties and uses of value stream maps and the roles involved in creating them. He relates this to the business operating models described in Enterprise Architecture as Strategy by Jeanne Ross, Peter Weill, and David Robertson,¹⁴ noting that "through VSM, [business leaders] can establish a common, visual model of the current flow of information and materials through the process, learning about problems along the way that may inhibit achieving their target operating model." Parkinson explains how value stream improvement leads to improved IT agility and eventually to a "well-oiled IT" machine. However, he cautions that the dream of "IT alignment with the business" may not be all it's cracked up to be.

Finally, we conclude with Cummins and de Man, cochairs of another OMG body, the Business Modeling and Integration Domain Task Force. For them, the need to improve business operations leads people to conduct "capability analysis," which requires that they consider and model multiple factors, including how value is created. Therefore, capability analysts need modeling tools, but they also need a metamodel -- a model of how value delivery models look -- so that tools created by a free market will follow some common approaches, represent comparable entities, and produce models that can be interchanged. This is the justification for the OMG's work on the VDM standard, which the authors hope to arrive at by 2012. The article describes the concepts to be included in the VDM and the analysis activities this will enable. (It should be noted that the graphical representations in the article are illustrative only; the companies that submit a proposed metamodel specification to the OMG, and the vendors who will implement tools compliant with the final adopted specification, are free to propose different notations.)

VALUE CHAINS AND THE FUTURE OF BUSINESS ARCHITECTURE

As the contributed articles (and the foregoing discussion) indicate, we're still in an immature stage with respect to our understanding of the relationships among business strategy, value chains or value streams, business capabilities, business processes, and IT capabilities. In the words of one of the advocates of a capability-centric architecture, Aleks Buterman of SenseAgility, this is a Goldilocks problem:

For strategic planning, value chain analysis produces powerful business function-driven results that are often not in sync with operational reality; for business process, it produces a mountain of operational descriptions that are rarely in sync with the strategic plan due to their volatility. Capability-driven methods, which connect strategic planning with operational reality, are "just right" for the proper application of value chain analysis.¹⁵

We may be naive to expect the field of business architecture to find its footing so quickly. It took the software engineering discipline about 15 years to go from a basic consensus on the range of models that were required to describe a system (the object-oriented methods that proliferated in the 1988-1993 time frame differed in the order of tasks and the exact meaning of their varied notations, but they still represented a certain commonality of concepts) to having a rich set of tools supported by major players like IBM as well as by many smaller companies. The same thing happened with computer-aided design tools 10 years earlier. Because change management depends on human nature, we should not expect this cycle to get notably shorter over time. We are starting to see a proliferation of business architecture tools, which will probably prove too many for the size of the market. In the ensuing shootout and consolidation, the usual suspects (IBM, Microsoft, Oracle) will pick some of the survivors, while a few others will be able to maintain their independence. We can only hope that the fittest of the concepts and notations will survive this process.

Once we have a consensus about business architecture components, methods, and notations -- similar to the consensus that emerged in 1995 about UML -- then we will understand where value chain modeling fits into this puzzle. And while the OMG's metamodel effort may sound very esoteric or intellectual to today's practitioners, having a rigorous metamodel of value chain concepts will help secure this new edifice.

ENDNOTES

¹ "NIH IT Enterprise Architecture Framework." US National Institutes of Health (http://enterprisearchitecture.nih.gov/About/Approach/Framework.htm).

² "TOGAF: Introduction." The Open Group Architecture Framework (www.opengroup.org/architecture/togaf8-doc/arch).

³ Zachman, John. "A Framework for Information Systems Architecture." IBM Systems Journal, Vol. 26, No. 3, 1987.

⁴See www.senseagility.com/index.html.

⁵ Porter, Michael E. Competitive Advantage: Creating and Sustaining Superior Performance. Free Press, 1985.

⁶ "The Value Chain." NetMBA Business Knowledge Center (www.netmba.com/strategy/value-chain).

⁷ Baudoin, Claude R. "Business Process Management: Cutter Glossary." Cutter Consortium Enterprise Architecture Executive Report, Vol. 13, No. 4, 2010.

⁸ Rummler, Geary A., Alan Ramias, and Rick Rummler. White Space Revisited: Creating Value Through Process. John Wiley & Sons, 2010.

⁹ "Business Architecture: The Missing Link Between Business Strategy and Enterprise Architecture" (PDF). SOA Consortium, January 2010 (www.soa-consortium.org/EA2010_Business_Architecture.pdf).

¹⁰See www.e3value.com.

¹¹ Osterwalder, Alexander. "E3-Value: A New Breed of Management Software to Model Business Networks." Business Model Alchemist (www.businessmodelalchemist.com/2006/05/e3-value-new-breed-of-management.html).

¹² See http://bawg.omg.org.

¹³ Whittle, Ralph, and Conrad B. Myrick. Enterprise Business Architecture: The Formal Link Between Strategy and Results. CRC Press, 2005.

¹⁴ Ross, Jeanne W., Peter Weill, and David C. Robertson. Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. Harvard Business School Press, 2006.

¹⁵ Buterman, Aleks. Personal communication to author, March 2011.

ABOUT THE AUTHOR