Harmon on BPM: Business Process Architectures

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.

Paul Harmon

Paul Harmon

Executive Editor and Founder, Business Process Trends In addition to his role as Executive Editor and Founder of Business Process Trends, Paul Harmon is Chief Consultant and Founder of Enterprise Alignment, a professional services company providing educational and consulting services to managers interested in understanding and implementing business process change. Paul is a noted consultant, author and analyst concerned with applying new technologies to real-world business problems. He is the author of Business Process Change: A Manager's Guide to Improving, Redesigning, and Automating Processes (2003). He has previously co-authored Developing E-business Systems and Architectures (2001), Understanding UML (1998), and Intelligent Software Systems Development (1993). Mr. Harmon has served as a senior consultant and head of Cutter Consortium's Distributed Architecture practice. Between 1985 and 2000 Mr. Harmon wrote Cutter newsletters, including Expert Systems Strategies, CASE Strategies, and Component Development Strategies. Paul has worked on major process redesign projects with Bank of America, Wells Fargo, Security Pacific, Prudential, and Citibank, among others. He is a member of ISPI and a Certified Performance Technologist. Paul is a widely respected keynote speaker and has developed and delivered workshops and seminars on a wide variety of topics to conferences and major corporations through out the world. Paul lives in San Francisco. Paul can be reached at pharmon@bptrends.com


  1. From our experiences we believe that successful and dynamic business (process) modeling requires a layered approach – of views of the business, and skills to create the content. The Business Architect is the critical role – a person with extensive knowledge of multiple business environments …end-to-end. Someone with the experience to know that what they are being told is probably incorrect. Someone with the experience to drill into a manager’s description of what happens in a process to expose the pieces that have been omitted.

    The Business Architect is responsible for creating the executive management view of the organization – The way our business works – the end-to-end flow of activity from desk to desk, machine to machine etc. that shows how value creation and enabling processes link demand and supply. They are not interested in the specifics of what happens at a desk or machine, just the flow of work through the business. We have seen CEOs from large organization’s and SMEs print out enlarged flows and display them on the boardroom wall to provide senior management with a shared picture of how their business works.

    The second tier, the detail of what happens at each desk/machine/etc., is collected by Business Analysts. This tier defines the tasks workers perform within a process and the flow of these activities at their desk, machine or another workplace. It effectively connects them to the real world – linking than to software, documents and any digital artifacts needed to undertake the task.

    The third tier, that the Analysts organize, is the collection of procedural detail from the people who do the actual work – the push-button set of step-by-step instructions that define a procedure.

  2. Claude Patou says:

    If you look about Balanced Scorecard Management Approach, BSC, you have an built EA system, from firm vision, followed by firm strategy, followed by BSC general map in BSC leverages, followed by deployment layer, sub- deployment layers, and with deployment project program. It’s more dynamical.

Speak Your Mind