What BPM Experts Know About Business Process that SOA Folks Don’t
The oft-touted objective of Service-Oriented Architecture (SOA) is to enable business agility in the face of continued change and heterogeneity. Since we’re not talking simply about making technology work better with technology, it makes sense that SOA must be aligned with the needs of the business. The needs of the business are reflected primarily in the organization’s business processes, and thus one would think that SOA must have a business process-centric perspective. But all too often, the conversation ZapThink has with end-users, consulting firms, and technology vendors focuses not on those business processes, but rather on the underlying technology platforms, standards-based interfaces, and system-to-system communication. Indeed, the story of business process has been at times so buried within the discussion of SOA that to the business, SOA itself has no business relevance. And yet, if there is any hope to a long-lasting impact and benefit of SOA, it must indeed be business relevant, and thus business process-driven.
The fact that many in IT are unable to justify a business case for a SOA investment signals that there must be a disconnect between the problems the business wants to solve and the promise of SOA as a solution. Yet, this is not the case with all IT initiatives. Indeed, the area of Business Process Management (some would add Modeling and Monitoring to the collective BPM term), has little role within the organization unless it is maps to specific business processes. However, those with BPM skills are not typically part of the SOA discussion, and as such their knowledge and connection to the business has not transferred to the organization’s separate efforts. What sort of business process knowledge can SOA folks learn from their BPM counterparts, and why are we needlessly separating our BPM and SOA efforts?
What do BPM Experts Know about Business Process?
Historically, IT treated the worlds of integration and business process separately. The IT environment has been so complex over the past thirty to forty years of computing that simply getting things to communicate and interact with each other is a significant challenge for IT. Technology offerings and approaches such as Enterprise Application Integration (EAI), Extract, Transform, and Load (ETL), and Enterprise Information Integration (EII) are squarely focused on solving the integration problem without needing much of a business context in which to justify their value. If you need data to go from system A to system B to accomplish some goal, then why bother the integration specialist with that goal? And yet, by focusing just on the technology problems of integration, the business placed little emphasis on requiring integration technologists and specialists to understand the business context or process in which those integrations form a part.
At the same time that integration efforts were underway, the business sought a means to address their continually changing business requirements in the context of IT. BPM evolved to drastically reduce the amount of time it took to distill the needs of the business into practically implementable parts. The business process is represented in a model that helps organizations identify not only how to realize current processes, but make improvements to them as they change in the future. Increasing productivity in the process improvement cycle is one of the greatest of BPM’s value propositions, and is usually achieved by reducing design-to-deployment timeframes through an integrated approach to both team management and technology. Successful BPM adherents point to methodologies and technologies that let them quickly develop and test process models, create and deploy user interfaces to those processes, and then connect those interfaces to existing systems.
The BPM Group has long espoused a view that Business Process Management is “…a natural and holistic management approach to operating business that produces a highly efficient, agile, innovative, and adaptive organization that far exceeds that achievable through traditional management approaches.” Two things come to mind. First, this definition of BPM sounds very close to the vision of SOA, and perhaps melding this perspective of BPM with the enterprise architecture perspective of SOA would leave to a much more business-relevant perspective on SOA and a more architecturally-grounded perspective on BPM. In fact, the idea of starting with a business process representation and rapidly iterating on that model to create the required logic necessary sounds much like a top-down, model-driven best practice just now being espoused in the SOA community. Yet, enterprises are still stuck building Services from the bottom-up, starting not with business processes, but rather underlying systems.
Second, many in the SOA community have never even heard of the BPM Group or seen them heavily involved in SOA efforts. Furthermore, there have been a number of BPM and SOA conferences in which the topics seem very similar, but the audiences were different — a fact we pointed out earlier in our Thinking Outside the SOA Box ZapFlash. This is an ominous sign that the BPM and SOA communities are more separated than they should be. But even more worrisome is the fact that many in IT who now champion SOA are not conversant in the language of business process. They often lack skills to do proper business process modeling and have not been involved enough in the organization’s BPM efforts to learn the benefits and pitfalls of various BPM approaches. The problem is that traditional integration experts are not the same as the business process experts.
Blending BPM and SOA
At first blush, some might see the efforts of BPM and SOA opposed to each other: business process experts on the one hand trying to build the perfect model and the technologists on the other trying to expose the perfect Services. And yet, there really is no such diametric opposition. In any environment of change, the business processes will continue to result in the need for new and different Services, and the technologies will likewise change with such regularity so as to complicate the efforts of anyone trying to realize a particular process. In the business reality of continued and simultaneous evolution, companies need to take a Service-oriented perspective on BPM and a business process perspective on SOA.
Taken as a starting point, Business Process models detail at an abstract level the various activities and relationships between activities to result in some sort of outcome. For many, these models serve as a requirements document that guides development. However, from a Service-oriented perspective, taking a purely developmental approach that considers business process models to be nothing more than static requirements documents is inadequate to realizing the agile and model-driven goals of SOA. One the one hand, SOA demands that compositions of Services be defined in metadata that are both executable as well as a human-understandable. In this vein, business process models are runtime artifacts, and not just design-time requirements documents. On the other hand, such models, if seen solely as design-time artifacts, serve to only to complicate things by trying to define every bit of process detail beforehand, resulting in extreme complexity and analysis paralysis that prevents any forward movement on process enablement.
Proper process-driven SOA considers BPM to be the top-down portion of any iterative SOA methodology with the result of well-defined Service contracts and a methodology that enables continuous, iterative definition of both the processes and their representative Services.
Furthermore, well-established BPM techniques don’t consider the lifecycle to be complete once a process has been modeled. On the contrary, effective BPM requires simulation and walkthrough of existing business processes to identify optimization and improvement as well as continued feedback from attempts to implement activities and Services at defined levels of granularity. Good BPM creates effective teams that can see how a business process will perform before they actualize it into Services at runtime.
However, before we can wrap up this topic, it’s important to note that BPM + EAI + Standards does not equal SOA. Too many software vendors consider their SOA efforts to merely be the collection of their process, integration, and standards-based middleware toolsets without realizing that the core motivation is the reduction of complexity by helping transform existing business processes through the use of agile Services. SOA is an approach to organizing IT assets as well as considering business processes and changing requirements. In this light, rather than piling formerly unrelated products together under the new banner of SOA, companies should carefully re-engineer their process and infrastructural tools to be inherently Service-oriented and process-driven.
The ZapThink Take
Some people have proposed creating a new term such as Process-Oriented Architecture (POA) needs to be created to separate those SOA efforts that are process-driven from those that aren’t, but one can just as forcefully argue that SOA efforts that are not process oriented are of little value. Successful SOA must necessarily be process-driven, otherwise an organization’s SOA efforts are nothing more than either standards-based integration or a new form of object-oriented computing.
SOA efforts will get a significant boost in both effectiveness as well as business stakeholder buy-in if it can leverage the best of what’s been learned from BPM as well as include BPM experts within their SOA teams. Indeed, for SOA to be successful, it must merge or more comprehensively combine with the efforts of BPM in order for it truly to be a business-focused architectural approach that successfully gives business the freedom to change.