Business-Process Engineering (BPE) and Business-Process Management (BPM)
Miriam Grace and Sandi Jeffcoat
Summary: Learn about Business-Process Management (BPM), and get ready for the future. What is right about IT is that we recognize the value of full collaboration with our business customers and, finally, we are developing tools that enable us to realize that partnership fully. (5 printed pages)
There is something wrong with IT—something dreadfully wrong.
–Smith & Fingar 
Bob is a new software architect about to embark on a software-development project where the customer is re-engineering their business processes. He has a generous budget and the full support of his IT leadership, and his customer is bringing in experienced business subject-matter experts (SMEs) to define the new business-process architecture. He has talked at length with the business-process owners, who are focused on developing lean and efficient business operations, so that they are "starting from scratch" and documenting new, common approaches to getting their work done across multiple business divisions. The business leaders are committed to engaging collaboratively with Bob and his IT team to get the requirements right. So far, so good.
Bob is an expert programmer. He has been a Senior Developer for over a decade and took the opportunity to advance to the position of software architect when this project was advertised. But he has never engaged in the "front end" of the software-development life cycle where the business processes are documented. This is new territory for him; and, although his IT skills are significant, neither is he used to thinking in business terms nor does he know how to prepare himself and his IT team for the adventure ahead of them.
If Bob were more aware of the emerging field of Business-Process Management (BPM), he would know what to do with the intellectual assets that his customers are about to create. He would be aware of the "coming attractions" in the technology of BPM systems, and he would understand how to capture the process information and turn those process descriptions into digital data—the key deliverable of the next phase in the software-development life cycle. He would know that a business process is a sequence of activities that carries out a complete business goal [Debevoise, 2005, 3]. Bob would be aware that BPM is the identification, understanding, and management of business processes that link with people and systems in and across organizations.
BPM knowledge would have provided Bob the power to visualize his customer's business processes as a critical "information chain" that connects the step-by-step series of activities with the data entities and relationships that Bob requires for system development. But Bob missed the previews of the coming attractions in the world of BPM. So, he and his IT team are in for a bumpy ride, as well as an expensive but worthwhile learning adventure.
Over the next several months, Bob and his team of functional analysts participate in workshops that start early, go all day long, and often extend into the evenings. He watches his customers argue among themselves about how to perform key functions in a way that satisfies all of their conflicting requirements. There are focal points from the various divisions—each one trying to work toward a common way of doing things, while fighting the habits of years of doing it their own way. Conflicts arise and resolutions are negotiated. This is hard work, and agreements are a win.
Antipattern 1, Divide and Conquer: Separate Users from Process
Bob and his IT team are learning about the customers' business; but, they are not sure how to help, other than to try to facilitate the discussions. When the customers finally do reach agreement, the results are documented by a business-process modeler who captures the business processes in Microsoft Visio diagrams and pastes the diagrams into static Microsoft Office Word documents, where the vibrant business descriptions are sealed away.
Thus begins the separation of the business people from their processes, and thus begins what will become a widening gulf between Bob and his customers. This is an all-too-familiar scenario in IT projects and what made Smith and Fingar  say, "Something is dreadfully wrong with IT."
Antipattern 2, Divide and Conquer: Separate Users from Data
But Bob does not seem to be aware of the communication gap that is growing between his customers and his team. He has begun to get nervous about all the time this process work is taking. He has brought in a data architect and data modeler, armed with a data modeling tool. He begins to move the subject of data from the background to the foreground. In his mind, data is what is important to the system design; this is familiar territory, this is what he knows. Words like "cardinality" and "facet" creep into his vocabulary. He holds sessions with the customers to educate them on the importance of the data model. The data architect shows the customers examples of how to think about their data, how to identify it. The customers have printed out paper representations of their business processes. Bob doesn't notice how they clutch them as if someone were going to steal them away. They look at their process flows and then at the data model; their brows furrow and they become confused.
Bob asks them to stop thinking about process now and turn their attention to the data. He tells them that the data is what is important now—that process definitions revealed the requirements—but he must understand the data to design the system. They try to bend, to follow his request. Both he and the data architect search to find a way to make the customers understand, but they do not seem to get it. Bob feels increasingly frustrated. They are not making any forward progress. He asks himself, "What more can I do to help them understand? It's their data. Don't they know what data they need to do their jobs?"
Now, reflect a moment. Think about what Bob is asking of his customers. They have just spent months working to describe their business operations. They have gone deep, describing what they do and trying to find lean, common approaches to old resource-intensive ways of operating. They have redesigned their processes to reduce cycle time and some have even sub-optimized their individual ways of doing business for the good of the whole. Finally, they reached a place of satisfaction with their creation. Now, he is asking them to climb another mountain, absorb a new language, understand new symbols, and create new representations of their reality.
They cannot bend that far without breaking. So, they fight it. Concepts like one-to-many and many-to-one relationships escape them. The breech widens. They experience a sense of loss. The pride that they had in their process definitions is diminished. Ownership has subtly transferred to Bob and the other IT professionals. The customer's knowledge about their business does not easily translate into information-systems design work. Although Bob is designing a system for them, they feel it move from their hands to his, and they worry about their needs being met. The breech is now a chasm.
The Business-IT Divide Is Alive and Well!
If Bob were more aware of the coming attractions in the world of BPM, right from the beginning he would have had a data architect and data modeler collaborating with the process modeler—constructing a data model and data dictionary from the maturing process definitions. Even more effectively, they would have required that the process models be captured in a digital design tool that enabled the transformation from business-process design to data model—where the inputs and outputs of the business become data entities, and where complete traceability from requirements to end-product delivery is birthed.
But, can we propose a scenario in which the problem never got started?
What if Bob and his business partners could concurrently perform the process-definition work right along with the system configuration? What if their focus was on "process processing" and not on "data processing?" What if Bob was looking toward the creation not of a "database," but of a "process base?" What if he could deal directly with the business process as an application, instead of data and application? What if his customers retained direct, physical ownership and could directly engage with him in the design and configuration of their system? What if their business processes were the design of the system?
Business-Process Management Systems
I understand that ideas as radical as eliminating the need for application development as we know it might make you raise your eyebrows and twist your lips into a look that speaks a "Yeah, not in this lifetime!" expression. And you would be right—almost. We are not there yet. But it is inevitable. Business-process management systems (BPMS) are here already, but they are still just a glint in the eye of the future that they foreshadow. If Bob had educated himself on the promise of BPM, separating what is possible now and what the five-year road map looks like, he would have been more sensitive to the value of the business processes for the long-term viability of his system design, and he would have understood what building blocks he should be putting in place now to support this profound change in IT development methods.
BPM has the potential to eliminate the business-IT divide, because it allows business and IT to do what they do best. When the business process is the application, the two become one, and modeling of the business process is the modeling of the application. After all, we have always said that software development is a process for building, maintaining, and perfecting business process. It's true now—more than ever.
BPM promises a focus on the "now"—the strategic goal that generated just-in-time inventory management and that stretches toward the ideal of the adaptable organization, in which time lags between innovation and execution are virtually eliminated. As Smith and Fingar  have suggested, "Change is the primary design goal of business-process management systems, because in the world of BPM, the ability to change is far more prized than the ability to design in the first place."
BPM is a technology-enabled way of running a business—harnessing the universal connectivity of the Internet to stay one step ahead of the competition [Fingar, 2006]. BPM represents a change in the language, symbols, and tools that we use to describe and design information systems. These methods and tools have become more business-centered and less tied to technical details. BPM allows the business to model its operations in words and process diagrams. To update the process or associated rules, the words and diagrams are updated by the business—allowing true flexibility and instant adaptability to changing business circumstances. This is the promise of BPM.
The next "big thing" in business is operational innovation and business transformation. BPM is the technology that is keeping pace with that global change. If there is any chance to achieve the promise of business and technology evolving in tandem, software architects must begin putting in place now the building blocks that will facilitate the transformation.
So, preview the "coming attractions" of BPM. Learn about BPM, and get ready for the future. What is right about IT is that we recognize the value of full collaboration with our business customers and, finally, we are developing tools that enable us to realize that partnership fully.
- [Davenport, 1993] Davenport, Thomas H. Process Innovation: Reengineering Work Through Information Technology. Boston, MA: Harvard Business School Press, 1993.
- [Davenport et al., 2000] Davenport, Thomas H., and Laurence Prusak. Working Knowledge: How Organizations Manage What They Know. Boston, MA: Harvard Business School Press, 2000.
- [Debevoise, 2005] Debevoise, Tom. Business Process Management with a Business Rules Approach. Roanoke, VA: Business Knowledge Architects, 2005.
- [Fingar, 2006] Fingar, Peter. Extreme Competition: Innovation and the Great 21st Century Business Reformation. Tampa, FL: Meghan-Kiffer Press, 2006.
- [Harrington et al., 1997] Harrington, H. James, Erik K. Esseling, and Harm van Nimwegen. Business Process Improvement Workbook: Documentation, Analysis, Design, and Management of Business Process Involvement. New York, NY: McGraw-Hill, 1997.
- [Smith & Fingar, 2003] Smith, Howard, and Peter Fingar. Business Process Management: The Third Wave. Tampa, FL: Meghan-Kiffer Press, 2003.
About the authors
Miriam Grace is an Enterprise Systems Architect and a member of the Boeing Technical Excellence Fellowship. She has over 20 years of experience as a computing systems architect, with a specialty in business-process management systems. Miriam is a published author, holds a Master's degree in Systems Design, and is a Ph.D. Candidate in Leadership. Miriam designed a learning system that provided a curriculum of foundational skills for software architects at Boeing.
Sandra Jeffcoat is a member of Boeing's Technical Excellence Program, a 2005 National Women of Color in Technology and 2007 National Society of Black Engineers (NSBE) Golden Torch awards winner, and a Ph.D. candidate for the Antioch University Leadership and Change Program. She has more than 28 years of technical experience for such companies as the Boeing Company, Eastman Kodak, NCR, Mead Paper Corporation, AT&T, and various governmental agencies.
This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.