By Frank Teti
While it appears that the fundamental architecture for cloud computing is the service-oriented architecture (SOA), there continues to be a significant hype regarding the relationship between business process management (BPM) and SOA. Although these things are not necessarily orthogonal, they are not inextricably, interrelated technologies as some analysts would have you believe.
Nevertheless, in the world of the high-technology, writers, analysts, and marketers create demand for new products and services by embellishing the synergies and underlying dependencies—either real or imaginary—in an effort to educate, sell, and promote the general welfare, so to speak.
In my own small way, I am guilty of contributing to this pattern. Along with other commentators in the field, I’ve been part of the hype with such comments as:
Many organizations that have been pursuing SOA now realize that adopting it without including BPM is in many ways an empty strategy. It’s not even really possible to calculate or talk seriously about calculating the return on investment of a SOA without considering a solution for BPM in the mix. (1)
Further hype abounds in the business and academic fields. Neil-Ward Dutton, cofounder and research director, MWD Advisors, states, “by demanding a focus on business improvement opportunities where flexibility is an imperative, BPM adds a value context and focus to SOA work,” in Making the Right Connections. (2)
Also, Faouzi Kamoun, College of Information Technology, University of Dubai, comments, “When combined together, BPM and SOA have the potential to empower enterprises to automate and optimize value chains through adaptable business processes, while easing the capability of IT in developing and managing flexible systems and applications, which integrate complex and heterogeneous technologies,” in The Convergence of Business Process Management and Service Oriented Architecture. (3)
While these statements are not necessarily erroneous, they are purely speculative and remain unsubstantiated. Then again, they say a lot, based on prior experience, anecdotal experience, and so forth. But such bringers of wisdom are sometimes nothing more than a sewing circle that gets together at industry meetings in order to define value proposition, programmer productivity, and such. The purpose of this article is to try to shed some light on the claims of BPM and its usage in general.
Rethinking BPM
In my more recent engagements, I’ve had the opportunity to move away from consulting within the infrastructure world of SOA and into the realm of pure BPM. Prior to that, I had more of a conceptual appreciation as to how BPM technology could integrate within an SOA. In retrospect, I realize that I used to make unsubstantiated statements regarding the coexistence and dependency of BPM on SOA. Indeed, perhaps I was merely laying down some cool discourse to a customer who didn’t fully understand SOA, let alone BPM. Recently, however, I have grappled with some business and system use cases as well as application requirements that have forced me to rethink these enabling technologies and the value they bring to the organization.
As many enterprise architects will prescribe, it is always important to understand the role of a component, such as BPM, within your architecture.
The Role of BPM within SOA
Wikipedia explains that some vendors could use BPM to describe new and/or updated products that provide automated workflow technology. (4) In many cases, “updated” here means updated or modernized for SOA. BPM—updated—existed before SOA and can exist without SOA. Prior to SOA, persistent storage was through relational databases and queuing mechanisms. The architectural shift with SOA is that Web services-enabled BPM can take the role of the service endpoint or the client that connects to a service.
When BPM is a service endpoint in the architecture, the data emitted may be the result of some real-time process —or unique behavior—that changes the state of this data. Where BPM and SOA truly intersect is when new BPM applications are unleashed into the organization and are essentially cordoned off from the rest of the organization. For example, there may be a need for a BPM service to integrate with the system of record for the organization; this may require integration with another process, a CICS application or a transaction gateway to the mainframe, in order to access an organization’s enterprise data. A BPM service should not be limited in its ability to integrate with the enterprise-wide environment; having all protocols readily available—including HTTP, JMS, and IIOP—is a tactical advantage.
When Web services are used, the advantage is that the security model (i.e., WS-Security) is part of the service and is consistent with the overall enterprise-wide application security model, which may be relying on SAML, digital certificates, or Kerberos. The point here is that database integration as an alternative is not necessarily the best option from an enterprise-wide security standpoint, nor is it from a data manipulation standpoint. This is because Web services can be specified to use collections and objects, which are better forms of abstraction than SQL result sets. Essentially, Web services provide a more seamless integration mechanism.
One of the main issues with SOA is in clearly defining the role of applications products within the architecture. When the service bus became the “next big thing” an IBM employee told me that IBM had four of them—and assured me that all were for specialized purposes. In reality, this problem of redundancy is endemic with SOA.
Consider the following questions:
- Do you perform transformations and routing in the service bus or within BPM?
- Should BPM always integrate with a service bus to expose proxy Web services, or should clients integrate with BPM directly?
- Should the service bus authenticate incoming requests, or just be a “pass thru” and let BPM authenticate the client?
- Should protocol conversion happen in the service bus or within BPM?
- Essentially, these types of questions don’t have a definitive answer. In many ways, optimum constructs might be:
- Decided upon arbitrarily by development groups
- Sometimes included in best practices documents published by enterprise architects in an effort to establish corporate standards
The subject of debate even within the vendor that created these technologies and grappled over the same issues such as “flexibility”—that analysts refer to as benign—can, unfortunately, become an opposing force to the standards put in place by the organization in an effort to improve essentials such as programmer productivity, application robustness, and scalability
Beware of BPMN 2.0
Overall, BPM is a business science applied by organizations to evaluate the various ways in which they complete work. Today, the term implies incorporating both technology- and non-technology-based methods for completing that work. This is an arbitrary point, however, since what’s currently done by hand today could possibly be automated by BPM tomorrow. BPMN 2.0—Business Process Model and Notation—is the notation for modeling this effort.
In my opinion, BPMN 2.0—the expansion of the original BPMN—is doing more to hurt BPM adoption than help it. In practice, I have found that you can design and build fairly complex business systems with a couple of handfuls of icon constructs. A parsimonious model, if effective, is always and everywhere a better model, not only for the design phase, but during the maintenance cycle, too.
BPM Is for the Technologist, Not the Business Analyst
When BPMN 2.0 first came about, its vision was to create one single specification for a new Business Process Model and Notation that would define the notation, metamodel, and interchange format, but with a modified name that would still preserve the BPMN brand. I find this vision to be self-serving and one that perpetuates those professionals who may be somewhat adept at emitting designs and never have a chance to participate in the feedback loop of implementation groups where you can truly validate the accuracy and usefulness of the design artifact. If anything, this notation scares away business analysts, who perceive it as so technical that only developers should be creating the workflow models. In projects were this happens, the business analysts are relegated to working with documents that contain requirements and use cases. In this manner, they will never make the professional jump to being a process designer, where they can truly impact the outcome of the project.
Still, concepts such as “spinoff” and “split/join” are conceptually daunting—and a programming feat—but modeling parallelism and asynchronous behavior into business application is where real productivity and straight-through processing design can be fully realized. In the heyday of COBOL/VSAM application, analysts would use data flow diagrams (DFDs) to express design.
A DFD is a graphical representation of the “flow” of data through an information system, modeling its process aspects. Often, DFDs were a preliminary step in creating an overview of the system that could later be elaborated. A properly leveled DFD using less than a handful of visual notation representations could effectively design a business system. I’m not sure if today’s BPM enthusiasts want to distance themselves from DFD, or perhaps they think it’s too rudimentary, but they should take a lesson from history. DFD was a simple but powerful tool. Thus, I feel it’s important to point out to the BPM analysts that they are not implementing the system; rather, they are just designing it.
Historically speaking, though, I never thought I would see the day that a process model, such as the one depicted below, could be forward engineered into a basic implementation. Coming out of the 3GL application development world, I have a certain amount of respect for design artifacts, but have always viewed them as discrete tools that facilitate the development lifecycle; not a construct for actually deploying a business system.
How SOA Got Into BPM
You can trace the association of BPM to SOA with the introduction of Business Process Execution Language (BPEL); essentially, a language for wiring together multistep logic flows spanning multiple external Web services executions. Indeed, this overloaded use of business process terminology caused some confusion within the overall application space. Perhaps a less misleading term may have been something like “Web Services Invocation Language” or “Service Orchestration Language.” But there was an advantage to this misrepresentation. By defining the new technology capability of BPEL as being similar to BPM, it was perceived as an avenue to sell the concept to the business client. It is important to note that BPM was already accepted as a business investment at that time for many large organizations.
Organizations have deployed BPM products since the 1990s. Thus, some BPM—and now business process management system (BPMS)—vendors saw the potential of creating business processes that could be monitored and optimized in a closed loop within SOA. Consequently, within this new open architecture, which was clearly gaining traction among the standards groups, vendors could embed their product with this functionality and create a synergy between their product and SOA. The capabilities of SOA provided a way to make their products integrate with automated processes as well as with existing back-end applications and data sources.
The overloaded use of the word “business” has obfuscated the role of BPM technologies in the architecture, to a degree, and contrary to some analysts’ thoughts, it will still take some time before SOA and BPM find their place since they are generic and complementary technologies. So, beware the technology mythmaker who tries to represent his technology as mission-critical and required. In reality, a certain amount of SOA and BPM technology should be part of a robust and modern architecture, and the key is to understand where it is a good fit.
Implications
Any discussion of business technology without at least perfunctorily mentioning its impact on an organization’s cloud computing strategy would be remiss. Software vendor-driven BPMS—whether on premise or in the cloud—usually relies on a modern architecture, which today incorporates many of the features of SOA. In many ways, the cloud obfuscates these features and the SOA-style adopted by the vendor may not even conform to the organization’s standards.
Still, for the typical cloud customer, it is a tactical and cost reduction purchase, as compared to licenses. It is about relinquishing control of data, architectural standards, security, etc. in order to boot strap them into a more modern processing world. For the vendor, the cloud really represents a cannibalization of their own product line, since the cloud option is at the cost of firm’s license product. Nevertheless, only in the BPM curve long run will it be certain as to whether this marketing strategy was pragmatic on their part. SW
Frank Teti is a senior consultant with Knowledgent. He was formerly with Pegasystems and also in the SOA practice at Oracle and BEA Systems. He can be reached at frank.teti@knowledgent.com.
Sources:
- Teti, Frank. “The New World of BPM: A Framework for Evaluating BPM Technologies.” Software Magazine, March 2009 (www.softwaremag.com/content/ContentCT.asp?P=2952).
- Ward-Dutton Neil et al. “Making the Right Connections Between BPM & SOA.” Webinar, Active Endpoints, 2010.
- Kamoun, Faouzi. “The Convergence of Business Process Management and Service Oriented Architecture.” Ubiquity, June 2007 (http://ubiquity.acm.org/article.cfm?id=1276167).
- “Business process management.” Wikipedia (http://en.wikipedia.org/wiki/Business_process_management.
Apr2014, Software Magazine
