X
Business

Beyond BPM: Runtime SOA

In an insightful essay, ZapThink's Ronald Schmelzer suggests that the factor that separates SOA from other past programming movements is business process. SOA, he contends, has the potential to take us beyond the current prison of Business Process Management (BPM).
Written by Britton Manasco, Contributor

In an insightful essay, ZapThink's Ronald Schmelzer suggests that the factor that separates SOA from other past programming movements is business process. SOA, he contends, has the potential to take us beyond the current prison of Business Process Management (BPM).

As he explains it, "BPM or workflow tools, often present a flowchart-type visual interface or natural language business rules engine that enable business analysts or their proxies in the IT organization to build a representation of the business process in a step-by-step fashion and then attach individual activities in a process to the company’s operations."

The problem? "[T]his approach to business process development and creation often suffers from the problem that the person who is responsible for creating the representation of the process either doesn’t know all the details of the business process at hand in sufficient depth, is not up-to-date with the current state of how a business process is actually working in the company, and/or doesn’t have knowledge of the whole process from end-to-end. As a result, most business process definition exercises often produce little more than 'shelfware' – that is, they end up creating nothing more than writing on paper that represents either the business process as it used to be, or the business process as it’s supposed to be, but never the business process as it actually is or will be."

Schmelzer makes the case for a "runtime business process model -- one in which a change to the model will in turn change the way that the business and its systems operate, and vice-versa, where a change to the business will automatically appear in the business process model. This bidirectional, runtime vision of business process should therefore be a key goal of any SOA implementation."

I encourage you to read the entire essay in which he explains how we might go about making this happen by separating "the notion of business logic and process from the underlying code that implements an individual task or step in a process."

While the conversation remains far too technicallly arcane and inaccessible to decision-makers at this point, Schmelzer takes a helpful step in the right direction by at least addressing today's SOA "cynics" -- and you know who you are -- in their own language.    

Editorial standards