Enterprise Integrity: Think BPMS
- Published: October 31, 2016
- Written by David McGoveran
Lessons can be learned from the DBMS story and a new opportunity seized in doing so. RDBMSs brought a true IT revolution, changing computing forever. When commercial RDBMSs were introduced, there were no standard ways of 1) organizing data, 2) accessing data interactively, 3) accessing data programmatically (despite CODASYL, proprietary approaches ruled!), or 4) remotely accessing data (files yes, data no). RDBMS availability made data sharing (across modules, applications, and even systems) possible and ultimately the norm.
Of course, it took a while to get a standard language and even longer to get a non-proprietary API. The relational model made both possible: Physical data independence hides the dirty details of physical storage, logical data independence hides logical changes where desired, and location independence hides physical location. Without this encapsulation, distributed applications were impractical: It’s no accident that client/server and network computing’s predecessor (LAN-based computing) took off with RDBMSs. And without these, EAI (and ERP) could not be.
The great new opportunity I mentioned? Well, today applications hold processes captive much as they once did data. So in the late 1990s I suggested a new concept to several EAI vendors — the BPMS (Business Process Management System). A BPMS manages business processes independent of applications: Process information is easily shared, accessed, and managed. As data modeling tools are used to design database schemas, so process modeling tools could be used to design process schemas (improperly called “processes”). Like an RDBMS, a BPMS stores process schemas, process constraints, and interprocess relationships in its system catalog. A repository for
process “runs” the BPMS analogue of RDBMS data.
Early commercial RDBMSs provided tremendous and immediate investment return by enhancing query, decision support, and report capabilities, as will the BPMS. And the decision support/analytic potential of a BPMS can take us far beyond querying the “status” of some business process, allowing physical performance parameters of a process schema to be related to business performance metrics.
Even so, such passive BPMS uses ignore the real potential as active IT components. BPMSs will be more than process schema repositories, becoming the process “database of record,” and externalizing business function logic. The BPMS then both monitors and controls process flow much like an intelligent message router: After all, a business process is just a set of inter-connected business rules, a network of business events, activities, or functions. At the highest level of process abstraction, the BPMS controls the business logic between applications, business functions, or activities, permitting process modification without shutting down applications.
Today’s workflow products can be considered a primitive BPMS technology, but lack key features. General process schemas, real-time performance, and transactional recovery features must be supported to obtain the real potential of BPMSs. That potential lies in process independence analogues of physical, logical, and location independence, which are necessary for business integration and transformation success. Like data schemas, process schemas (found today as application control or procedural logic) must support multiple descriptive levels or process abstraction hierarchies. Unfortunately, the procedural logic that implements multiple process levels is rarely separated in application code. Solve these problems, and BPMSs will enable changes to the physical implementation of business logic without impacting management’s business process understanding. More important, managers can then implement business process changes with minimal impact on or involvement from IT.
Early BPMS technology existed in products such as HP ChangEngine, IBM MQWorkflow (now IBM WebSphere MQ Workflow), Vitria, and others. Still, analogues of SQL, database transactions, and relational API are needed to progress. And we need dynamic optimization of the location of process execution—whether externalized in a BPMS process engine or internally in the application. Although BPMS technology lacks the functional maturity or definition associated with RDBMSs, today’s products tangibly hint at the flexibility and economic benefits of the BPMS vision. IT and business drivers foretell increasingly rapid business process change. Without a BPMS as a key component of the business integration architecture, that demand won’t be met.
And I hope you’ll agree that consistent, managed business process change is the very essence of enterprise integrity...and therefore of business transformation.