Harmon on BPM: Where is Business Architecture Today?

One of the things I noticed at this year's BBC Conference is that many vendors offered help with both Business Process improvement and with Business Architecture development. I suppose BPTrends can take a certain amount of credit for the increased emphasis on Business Process Architecture as we have promoted the idea for years. At the same time the OMG and the associated Business Architecture Guild also deserve credit as they have also done a lot to raise awareness of various Business Architecture as a kind of adjunct to Enterprise Architecture.

Just to be clear about architectures, here's an overview. Architectures began, in the Nineties, focused on organizing the Information Technology resources of an organization. In many organizations, even today, the term “Enterprise Architecture” is a synonym with the organization's IT Architecture. Most textbooks, however, have always defined “Enterprise Architecture” more broadly, as concerned with everything in the organization. If you use this broad definition, then logically there ought to be a “Business Architecture” — something that describes business goals and the processes used to achieve those goals. For years, enterprise architects didn't take business architecture very seriously. They would just wave their hands at a vague drawing and claim that the IT architecture supported the goals and processes of the business. (See Figure 1.)

Figure 1. An overview of some kinds of architectures


Figure 1. An overview of some kinds of architectures

In the past decade a variety of enterprise architects have become interested in defining the term “Business Architecture” more precisely. Several efforts have been launched to describe the elements of a “Business Architecture.” The most notable efforts are those offered by the Open Group (TOGAF) and the OMG (and the Business Architecture Guild). Although some within either group would disagree with me, I would argue that both of these efforts are driven by IT people who seek to define the Business Architecture section of a comprehensive Enterprise Architecture. Neither, as far as I can tell, have interested actual business managers, but that may change as Enterprise Architects continue to promote this approach.

My concern here is on what I would call a Business Process Architecture. This architecture comes out of the business process tradition, and not out of the EA/IT tradition. In the early Seventies, when Geary Rummler first began to try to systematize business process redesign, he argued that process developers should begin by defining the value chain that they were focused on. The value chain defines the outcomes that are delivered to customers and other stakeholders. Once the value chain is defined, one can decompose it and determine which large subprocesses are required to deliver the value one is focused on. Later, Michael Hammer incorporated this approach into his writings on Business Process Reengineering, and urged organizations to begin their process reengineering efforts with a clear overview of the value chain and the major processes that made it up.

In the past decade the various kinds of architecture have become intertwined. For many, today, a “Business Architecture” and a “Business Process Architecture” are the same thing. They aren't. A Business Architecture can include lots of elements that aren't necessary or even useful to process practitioners. Keep the uses of the two approaches in mind. Business Architecture, as used by TOGAF or the OMG, is designed to provide IT people with business goals that IT can support. More to the point, unfortunately, enterprise architects are often pursuing multiple goals and tend to develop models that are overwhelming and of little use to those actually trying to manage a business.

Business process practitioners and managers who are trying to improve organizational performance usually have narrower goals. They seek to determine how processes generate value, and to define the specific processes that need to be improved to generate value more rapidly, more effectively, or cheaper.

Some process practitioners have gotten caught up in the excitement generated by the business architecture folks and have begun to think of a business architecture as a legitimate goal for process practitioners. They have begun to think that an organization ought to maintain a process architecture, for its own sake. At times in the past decade I have got caught up in that enthusiasm myself. Realistically, however, most companies don't have the time or the need for a comprehensive business architecture – or even for a comprehensive business process architecture. It takes too much time and effort to create a comprehensive business process architecture, and then it costs even more to maintain it. In today's business environment, with changes coming rapidly, trying to develop a comprehensive business process architecture is an endless task and not a very rewarding one.

BPTrends teaches an architecture course. Our focus is on providing business process practitioners with the information they need to identify where problems occur. We identify associated processes within a value chain and examine them because they often contribute to the problems process redesigners are trying to eliminate. Some companies have asked for help in preparing more comprehensive business process architectures and we have helped them develop such architectures. For some organizations, focused on major business transformations, a comprehensive business process architecture can be very useful.

For most organizations, however, a major architecture effort is a waste of time. It focuses analysts and managers on a huge effort that doesn't provide much in the way of payback. It's far better for most organizations to focus on a specific problem, define the value chain that contains that problem, and then analyze just those business process architecture elements required to understand the problem.

This isn't just my opinion, of course. BPTrends has run a variety of surveys over the years. Broadly speaking, few organizations have comprehensive business process architectures – at least in the way I'd use the term – and they aren't interested in maintaining those they have. Many pay lip service to the idea of a business architecture, but data suggests that very few organizations are willing to spend the money or invest the people required to actually create and maintain such an architecture.

All this isn't to say that organizations don't need any form of business architecture. IT folks need something to structure their software and database efforts – though that's not really a process issue. Even process people need business process architectures to help align their process improvement effort. What most organizations don't need, however, is an extensive effort aimed at defining all of the business processes in an organization, let alone more superficial elements. Such an effort is simply busywork that will keep analysts busy for years and lead to little of value. In today's business environment, the key is to produce results with a minimal effort. Things are changing too fast to justify the tedious, non-productive architectural efforts that are still being promoted by too many practitioners today.

There will still be some uses for comprehensive business architecture efforts – if one is designing a new organization, or undertaking a major transition – but otherwise, the emphasis today must be on streamlined redesign efforts that don't waste time defining and analyzing routine processes that don't need to be captured. The alternative is to spin one's wheels and produce the kind of shelfware that way too many business architecture efforts have done in the last few years.

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
Share

Comments

  1. Claude J. Patou says:

    Paul, you become business-realist, with your analysis. Short-termism is stuff king. Company envision for SME is hard in these constraints.

  2. I love Geary Rummler and Co’s materials. Glad to see you quote him. Do you have any thoughts on additional experts that would dovetail with Geary’s thoughts and methodologies?

  3. Keely Maitland says:

    It has been my experience also that businesses don’t want to invest in a business process architecture and I agree that documenting processes down to the nth degree is a never ending source of busy work. What level of business process architecture do you think is necessary? How would an organisation know how well they are achieving outcomes for customers if they don’t have a business process architecture to base their measurements on?

  4. Mary Biggs says:

    Quote: “…the emphasis today must be on streamlined redesign efforts that don’t waste time defining and analyzing routine processes that don’t need to be captured.”

    Paul: How do you know which processes “that don’t need to be captured”? Don’t you need SOME sort of overall view so that you can make this sort of determination? Perhaps there are low value “routine processes” out there which are consuming disproportionate resources?

  5. If you are analyzing a specific process, then you always need to know what super process that specific process belongs to — that provides you with ways of measuring results. If you are analyzing a high level process, then the superprocess will probably be a value chain — and you will need to analyze that. I would always prefer that one knew all of the value chains an organization supports and that one had a good analysis of all of the level 1 processes contained by each of the value chains. That prepares you to establish very good measures of those processes and to locate almost any other lower level process rather easily. So, an archiecture of value chains and their major subprocesses would always be nice. Beyond that, without a specific need, I wouldn’t go. And I’d only decompose when I had a specific problem — I wouldn’t drill down into sub-subprocesses just to create “an architecture.”

Speak Your Mind

*

Share
Share