This guest post comes courtesy of Jason Bloomberg, managing partner at ZapThink.Take the BriefingsDirect middleware/ESB survey now.By Jason BloombergZapThink has long championed the
close relationship between business process management (BPM) projects and service-oriented a
rchitecture (SOA) initiatives. As anyone who has been through our
Licensed ZapThink Architect Bootcamp can attest, we have a process-centric view of SOA, where the point to building loosely coupled business services is to support metadata-driven compositions that implement business processes, what we call service-oriented business applications, or SOBAs, for want of a better term.
Nevertheless, there is still
confusion on this point, among enterprise practitioners who see BPM as a business effort and SOA as technology-centric, among vendors who see them as
separate products in separate markets, and even among
pundits who see Services as supporting business functions but not business processes.
On the other hand, there are plenty of enterprise architects who do see the connection between these two initiatives, and who have pulled them together into "BPM enabled by SOA" efforts. This synergy, however, is not automatic, and requires some hard work both among the people focusing on optimizing business processes to better meet changing business needs as well as the team looking to build composable business services that support the business agility and business empowerment drivers for their SOA initiatives.
ZapThink has worked with many such organizations, and over time a distinct best practice pattern has emerged, one that is both fundamental as well as subtle, and as a result, has fallen through the cracks of
compendia of SOA patterns: the Process Isomorphism pattern. Understanding this pattern and how to apply it can help organizations pull their BPM and SOA efforts together, and even more importantly, improve the alignment of their SOA initiatives with core business drivers.
What is Process Isomorphism?An isomorphism is a mathematical concept that expresses a relationship between two concepts that are structurally identical but may differ in their respective implementations. A very simple example would be two tic-tac-toe games, one with the traditional X's and O's, and the other with, say, red dots and blue dots. The game board and the rules are the same, in spite of the difference in symbols the players use to play the games. If two particular games follow the same sequence of moves, they would be isomorphic.
The term process isomorphism usually refers to two processes that are structurally identical, typically between two companies in the same industry. For example, if the order-to-cash process is structurally identical between companies A and B, that is, the same steps in the same order with the same process logic, those processes would be isomorphic, even if the two companies had differences in their underlying technical implementations of the respective processes.
We're using the term differently here, however. Process isomorphism in the SOA context is an isomorphism between a process on the one hand, and the SOBA that implements it on the other. In other words, if you were to model a business process, and as a separate exercise, model the composition of services that implements that process, where those two models have the same structure, then they would be isomorphic.
One conversation that helped crystallize this notion was with
John Zachman, who was explaining some of the changes he has recently made to his seminal
Zachman Framework. He has renamed Row 3, which had been the System Model row, to the System Logic row. People were confusing the System Model with the physical representation of the system, which resides one row down. Our discussion of process isomorphism is essentially a design practice that relates these two rows of Column 2, the How column. In essence, the process logic model is one level above the service composition model that implements the process logic. The process isomorphism pattern states that these two models should be isomorphic.
Process Isomorphism in PracticeWe've been using a wonderful example of Process Isomorphism on our LZA Course for a few years now, courtesy of British Petroleum (BP), who presented at our Practical SOA event in February, 2008 (
more about our upcoming Practical SOA event). The presentation focused on how process decomposition is the common language between business and IT efforts, and one of the examples focused on the Well Work Performance process, one of thousands of processes in their oil drilling line of business:
BP's Well Work Performance Process
The Description column in the chart above reflects the four main subprocesses that make up this process. The Sub-Task columns represent individual sub-tasks, or steps in the process. Finally, the Supporting Service Name column indicates the Business Service that implements the corresponding sub-task. The fact that there is a one-to-one correspondence between sub-tasks and supporting Services, combined with the implied correspondence between the process logic and the composition logic, illustrates Process Isomorphism. In this simple example, the process logic is a simple linear sequence, but if the logic were more complex, say with branching and error conditions, then the process would exhibit isomorphism if the composition logic continued to reflect the process logic.
It is important to point out that the one-to-one correspondence between process sub-tasks and supporting Services is by no means a sure thing, and in practice, many organizations fail to design their compositions with such a correspondence. Frequently, the issue is that the SOA effort is excessively bottom-up, where architects specify services based upon existing capabilities. Such bottom-up approaches typically yield services that don't match up with process requirements. Equally common are BPM efforts that are excessively top-down, in that they seek to optimize processes without considering the right level of detail for those processes to enable services to implement steps in the processes. Only by taking an iterative approach where each iteration combines top-down and bottom-up design is an organization likely to achieve Process Isomorphism.
The Process Isomorphism Value Proposition
The essential benefit of Process Isomorphism is being able to use the process representation to represent the composition and vice-versa. While these concepts are fundamentally different, in that they live on different rows of the Zachman Framework, the isomorphism relationship allows us the luxury of considering them to be the same thing. In other words, we can discuss the composition as though it were the process, and the process as though it were the composition.
This informal equivalence gives us a variety of benefits. For example, if process steps correspond directly to services, then service reuse is more straightforward to achieve than when the correspondence between steps and services is less clear. Service reuse discussions can be cast in the context of process overlaps. If two processes share a sub-task, then the SOBAs that implement those processes will share the supporting service. In addition, the metadata representation of the composition logic, for example, a BPEL file, will represent the process logic itself. Without process isomorphism, the process logic the BPM team comes up with won't correspond directly to the BPEL logic for the supporting composition. This disconnect can lead directly to misalignment between IT capabilities and business requirements, and also limits business agility, because a lack of clarity into the relationship between process and supporting composition can lead to unintentional tight coupling between the two.
The ZapThink TakePerhaps the greatest benefit of Process Isomorphism, however, is that it helps to establish a
common language between business and IT. The business folks can be talking about processes, and the IT folks can be talking about SOBAs, and at a certain level, they're talking about the same thing. The architect knows they're different concepts, of course, but conversations across the business/IT aisle no longer have to dwell on the differences.
The end result should be a better understanding of the synergies between BPM and SOA. If process specialists want to think of business services as process sub-tasks, then they can go right ahead. Similarly, if technical implementers prefer to think of business processes as being compositions of services, that's fine too. And best of all, when the BPM team draws the process specification on one white board and the SOA team draws the composition specification on another, the two diagrams will look exactly alike. If that's not business/IT alignment, then what is?
This guest post comes courtesy of Jason Bloomberg, managing partner at ZapThink.Take the BriefingsDirect middleware/ESB survey now.
SOA and EA Training, Certification,
and Networking EventsIn need of vendor-neutral, architect-level SOA and EA training? ZapThink's Licensed ZapThink Architect (LZA) SOA Boot Camps provide four days of intense, hands-on architect-level SOA training and certification.
Advanced SOA architects might want to enroll in ZapThink's SOA Governance and Security training and certification courses. Or, are you just looking to network with your peers, interact with experts and pundits, and schmooze on SOA after hours? Join us at an upcoming ZapForum event. Find out more and register for these events at http://www.zapthink.com/eventreg.html.
the successful use of web data services and enterprise mashup technologies and the adoption of an open language that promotes enterprise mashup interoperability and portability. This is a high priority for more and more enterprises, which is why the OMA could gain momentum.
