Words decay with use. It says something about the times we live in that a new term is coined, it becomes popular, and then it becomes meaningless, and we move on to yet another new term. In the 50's there were conferences on Work Simplification – a movement to improve business processes. Somehow, that term fell into disuse. For a while people spoke of quality control, and then of Six Sigma, and later still, of Lean and then Lean Six Sigma. Meanwhile others spoke of Business Process Improvement, then Business Process Reengineering, and, more recently, Business Process Management (BPM). Today, BPM seems to be fading and people are now talking about Business Transformation. I often blame companies like Gartner, that, it seems, can't keep hyping the same topic for too long, so they keep inventing new terms to maintain their client's interest in the “next hot thing.” I realize, however that it isn't just the fault of companies like Gartner; everyone seems to be involved.
A term is coined and given a meaning by the person who coined it. Thus, Michael Porter, the well-known strategy professor at Harvard Business School, coined the term “value chain” in his 1985 book, Competitive Advantage. Porter, like the good academic he is, was careful to define the term precisely, and provided clear examples of value chains. He went on to use the term in several articles, each defining the term and providing additional examples.
In the early 1990's, when Michael Hammer kicked off the Business Process Reengineering (BPR) revolution, he also used the term “value chain,” attributing it to Porter. Unfortunately there was a problem with Porter's definition of the term. Porter used “value chain” to describe all of the processes that a firm used to create a line of products and services. His model shows that management, finance, IT, and HR as well as other support processes are all part of a single value chain. This works fine if the company only produces a single line of products and services, but it creates problems if a large corporation produces more than one line of products. Consider Michelin, the French firm that produces tires and guidebooks. It's conceivable that Michelin has separate finance, IT and HR operations supporting tires and guidebooks, but it's unlikely. More likely one IT group supports both divisions. In any case, at some level, senior management controls both divisions. Reflecting this reality, Hammer and most others began to use the term “value chain” to only refer to the core processes that generate a given line of product and services. That, in turn, means that Finance, IT and HR process must somehow be accounted for in some other way.
Without going into more detail, suffice to say that “value chain” is still used today, but is used in a variety of ways, and only a few of the uses still correspond to Michael Porter's original usage.
In other words, sometimes we change usages simply because we get tired of using the same term over and over again. Sometimes a term, like “Business Process Reengineering” picks up too much baggage – there are too many stories about failed BPR projects and suddenly no one wants to admit that they are working on a BPR project. And, often, the times change and one definition proves too limiting and people begin adding adjectives or using a new term to describe the term.
The term I am interested in this Column is “Business Process Architecture.” The term was surely used by many different people, but the first person I heard use it was Geary Rummler, in the early Eighties. Geary had developed a systematic approach to improving organizational performance and he argued that one needed to approach performance change in a systematic, top-down manner, starting with an overall understanding of what the organization was trying to achieve. He had lots of war stories that emphasized the trouble you could get in if you accepted a client's word and started working on a specific problem without first understanding the larger context. In essence, clients often failed to understand their own problems. If you accepted their definitions, without doing an investigation of your own, you often found yourself trying to solve a problem that couldn't be solved, given the constraints you found yourself operating within. Thus, Geary insisted on working out a business model, he usually termed it a “business map,” and then later termed it a business process architecture, that laid out the major processes that the organization relied on to produce its product or services. Later, Michael Porter would formalize this a different way and call it a “value chain.” The key idea was that you needed to know the major activities an organization went through to produce results. Those major activities defined the environment within which any specific process worked. Assuming the specific process was a couple of layers down inside the organization, then some of the larger processes define the inputs and accepts the outputs that the specific process needs and generates as it functions.
Geary's approach became embedded in Hammer's work and eventually everyone who worked on BPR projects in the early 90s learned that one needed to start a process redesign project with a value chain or business process architecture that defined the overall context for a process improvement effort.
Now let's step back and forget business process change for a moment. In the Nineties there was a separate movement among IT people to define the software elements used by a given organization. This was termed an Enterprise Architecture (EA). The idea was formalized by many different people. Most formulations of the EA suggested that management had goals and that IT assets were accumulated to support those goals. To link goals to IT applications, one spoke of “business processes” designed to implement business goals. The enterprise architects hypothesized “business architecture” as a description, presumably developed by business managers, that described what the business sought to accomplish. The various technical architectures, of hardware, applications, of data and of infrastructure elements, existed to support the business goals and hence to support the business architecture. The only problem with this is that business people didn't think in “architectural” terms and didn't really have such an architecture. That didn't bother early enterprise architects very much because they were happy just cataloging their IT assets.
To make a long story a bit shorter, ultimately the enterprise architects decided they would have to create their own business architecture. The process people just assumed that what the IT people were really talking about was a value chain or a business process architecture. In the past few years, however, as one group after another has become involved in trying to specify a version of a business architecture, the whole field has become incredibly messy. At this point, if you believe one of the groups, The Architecture Guild, a business architecture has little to do with business processes. They are focused, instead, on capabilities, or, sometimes, “value steams” (which derives from Lean and has another long, twisted history).
Suffice to say that business process people still need to start with an overview that can provide a context for business process improvement (or BPM, or Business Transformation, or whatever people are calling process improvement today). You need some kind of overview that establishes the context in which your process improvement work will take place. Capabilities, and most of the other artifacts that today's Business Architects are developing aren't much use. Indeed, some of them have contributed to no end of confusion.
No blame need be assigned. Sometimes different groups don't need to work together. Business process improvement people need to develop business process architectures – or process maps, to use Geary Rummler's original term. Business Architects are struggling to develop artifacts for Enterprise Architects and are presumably satisfying their own needs. A policy of benign neglect seems to be the order of the day. Business process change practitioners need to understand that their use of “business process architecture” is different from the uses of similar terms by Business Architects. In a better organized world they would be the same, but in this world they aren't and we simply have to adapt.