Early emphasis on process architecture was driven by Geary Rummler, in the 80’s. Geary always advocated beginning any major process initiative with a company architecture that shows how all the major processes in a company worke together to produce valued outcomes. Michael Hammer, in Reengineering the Corporation, followed Rummler’s lead and suggested that projects should begin with an overview or architecture of the company’s processes.
That theme was reinforced by Harvard business strategy professor, Michael Porter, who described a high level Value Chain Model that showed how one combined all the activities that an organization needed to generate a line of products or to achieve a strategic goal. The difference between Rummler and Hammer and Porter, was in the use made of the architecture. Rummler and Hammer used an architecture to begin a process redesign project. Porter used an architecture to refine how the processes in the organization worked together to achieve a strategy. In essence, Porter made architecture into an independent modeling effort.
Watts Humphreys and the folks involved in developing the Capability Maturity Model (CMM) at Carnegie-Mellon defined a development (maturity) path that saw companies evolve from a focus on single process improvement projects to teams of managers who used process architectures and systematic measurements to guide corporate development. Humphreys was clearly interested in architectures, independent of the specific improvement project. Complementing this, in the 00’s, was a US government initiative that required companies to prove their financial integrity – their ability to follow the money — by developing a business architecture that showed how the company moved information about. The US architecture initiative put its focus primarily on the development of a computer architecture that defined software applications used by an organization. Since software applications did not match precisely with business processes, computer-focused architectural efforts often seemed to clash with process-focused efforts. To add to the confusion, the OMG, a software standards consortium, launched a business architecture effort that focused on “capabilities” (outcomes rather than activities) which added considerable confusion to the whole architecture scene.
Today, there are, in fact, several approaches to business architecture, and modifiers like “process” and “IT” need to be checked carefully to determine what type of advice a given book or article will provide.
Business Process practitioners need an approach to architecture that puts processes at the center of their work. Obviously processes must be tied to a company model, to strategies and measurements, to organization charts and to capabilities and software architectures. The essence of a process focus, however, is that businesses achieve value by executing business processes. Processes define what the business can do and they form the backbone on which on attaches everything else– resources, employees, software systems, facilities and access to customers. For processes people, at least, architecture is about processes and how they work together to produce value.
Roger Burlton has been engaged in business process analysis and improvement for decades. I have worked with Roger at BPTrends, at conferences, and on the development of a process methodology and a curriculum, so I am hardly objective, but I think he is one of the most reasonable and practical process gurus available today. Roger has always focused on providing models and procedures to help guide practitioners to success, and his latest book, Business Architecture: Collecting, Connecting, and Correcting the Dots, is an excellent example of Roger’s approach.
The whole book is organized around Roger’s Business Architecture Framework, a model comprised of four phases, each composed of four concerns. The first phase focuses on Defining the Business. Two focuses on Designing the Business, Three focuses on Building the Business, and the fourth phase focuses on Operating the Business.
The second phase focuses on four concerns: Business Processes, Business Capabilities, Business Information and Business Performance. In effect one lays out the business process architecture as one focuses on the first concern, and then integrates processes, with capabilities, information systems and business performance measures as one proceeds to work through the phase. You can think of the business design as having four perspectives and the methodology allows one to integrate the perspectives. This approach provides the developer with a grounding in each of the popular perspectives prevalent today and shows how they can be integrated into a broader approach.
Let’s be clear, Burlton has not written a book that focuses on how to undertake a single process redesign project – books like Rummler and Hammer wrote. He definitely focuses on identifying the various business processes that make up the organization and develops a comprehensive approach to identifying where problems lie and where there are opportunities to improve an organization. He is focused on how one uses an architectural perspective to determine where a process term should focus its efforts.
In essence, Burlton is offering a comprehensive methodology for prioritizing how one goes about improving business processes within an organization. This is a modern update on the approaches that Rummler and Hammer both promoted with a much more sophisticated approach to establishing priorities. The essence, however, is that to improve a business one starts with process and works down to the process problems, identifies which to focus on, fixes them, and then continues to maintain and improve them.
The alternative to this approach might be a book that just focused on what Burlton calls “Designing the Business” and described how to develop a business process architecture in considerably more detail. It might show the relationship between value chains and high level processes in complex organizations, for example. Such an approach would place more emphasis on how process hierarchies fit together, and how one dealt with the flow on core products and with support services like HR and IT, that must be provide, not for customers, but for numerous internal activities.
Consider that fewer companies, today, emphasize architecture than did in the early years of this millennium. Today’s companies face an increasing rate of change and problems, like the pandemic, that seem to come from nowhere and then totally dominate our thinking for a year or two. Organizations that, two decades ago, might have set-up a long term planning group, see no need for such a group today. Instead, organizations are much more likely to buy off-the-shelf processes to handle routine activities, and focus on just those processes that involve critical new technologies or that address customer issues that are most pressing. No one has time for the kind of effort involved in the kind of business process architecture work advocated by CMM.
It’s as if process architecture started as part of planning for a specific process redesign, got elevated into a more specialized concern with CMM and an emphasis on company-wide integration, and now, has retreated to its more modest origins as a way to plan a specific process improvement effort. Burlton offers the perfect approach for this new era. It doesn’t go into great depth on how one might achieve a detailed, company-wide architecture. Instead, it provides a light-weight approach to defining all the various major processes in an organization, and prioritizing them. Then it proceeds to drill down and plan for specific improvements.
Burlton’s book integrates lots of valuable information and several very useful models and procedures into a general approach to figuring out an organization’s problems and opportunities, and then helps readers plan to address the processes that will yield the most valuable improvements. This information is presented in a systematic way, and any business process practitioner will benefit from studying and experimenting with the approaches described in this book. It belongs on every business process practitioner’s bookshelf.
The practical approach described in this book can help you as a business architect, analyst, or manager, create reusable, adaptable, and manageable knowledge of your organization. Apply the full lifecycle from business strategy through implementation, and identify the required knowledge domains. Convert business strategy into usable and effective business designs which optimize investment decisions. Articulate what domain knowledge (the dots) needs to be collected, how these are connected, and which combinations provide the greatest opportunity if corrected. The book covers the main business architecture stages of ‘Define the Business’, ‘Design the Business’, ‘Build the Business’, and ‘Operate the Business’. Build models of the external ecosystem, business stakeholders, business information, business processes, business capabilities, change prioritization, and performance management systems to support your change journey.
This book is an essential companion guide for new business architects and analysts, and a valuable reference for experienced architects to enhance their practice.
