Business Process Management Suites (BPMS).
Historically the two tiered client server and siloed enterprise architectures spawned an industry based around enterprise application integration (EAI). This was facilitated by middleware enabling integration of disparate systems across the enterprise.
The advantage of this approach was that existing applications and data structures could be leveraged to create, extend or automate new business processes without disturbing the existing infrastructure. The problem however is that middleware itself is complex, difficult to maintain and the various disparate systems linked together were usually on different operating systems, used different databases, programming languages and generally were incompatible in every way.
Middleware was a means to an end but very inefficient because organisations were still supporting multiple disparate systems as well as the middleware itself. The next phase in the evolution information systems was the growth of ERP style systems such as SAP, a single integrated environment with common data structures, languages and reporting tools shared across the enterprise.
Hence vendors such as SAP and others moved beyond simply controlling the data itself but into managing and controlling the processes and work flows of an organisations entire value chain; this facilitated the evolution of workflow management systems where software can define create and manage workflow across the enterprise.
There was no need for middleware because ERP vendors transformed the previous generation of discrete monolithic ‘off the shelf’ applications for work areas such as accounting, inventory or human resources into a cohesive set of linked applications (modules) so data could be maintained across the enterprise in a seamless fashion (since they were all using the same database objects).
These systems not only manage work and process flows across an enterprise but in many cases facilitate best, albeit common practice for functional areas. This leads us to where we are now with enterprises typically supporting information systems that are accessible with industry standard communication protocols and data formats and providing the means of BPMS managing enterprise business processes.
Key Issues:
ERP systems are by no means a panacea as they are complex, expensive and require significant human and technical resources to maintain.
Many organisations customised their ERP applications and this not only adds further expense but is time consuming and fraught with the danger of introducing workflows that don’t integrate across the enterprise (the very thing you are trying to achieve). It also introduces considerable maintenance overheads coordinating these changes across new versions. That is, as vendors release new ERP modules customisations need to be redone and often divisions become locked into old or multiple versions of ERP systems out of step with the rest of the enterprise.
BPMS are an alternative to this scenario. These suites are potentially more agile and productive, easier to develop and maintain and can focus on bridging the gap between process managers and software developers. There is a lower implementation and development risk as they can be layered over the top of ERP and other corporate data systems. They can be developed, tested and even replaced with alternative systems without disturbing the existing architecture.
The difference between middleware and BPMS is that these suites are usually integrated to a homogeneous environment rather than needing to connect disparate IT systems as was the case when middleware oriented solutions first appeared. This need not be the case of course but usually enterprises like to lower their cost of ownership by adopting standard operating environments (SOE).
The current generation of communications and data standards; based around Service Orientated Architectures (SOA) such as Web Services and XML (Extensible Mark-up Language) have created the opportunity for vendors in the BPMS market to add considerable value to the enterprise without requiring them to replace their existing investments.
As an example I have compared two such suites chosen from the BPTrends Report on five of the criteria cited in the report. I have chosen to compare the Oracle BPEL Process Manager (version 10.1.2) and Adobe Live Cycle Workflow (Version 7).
I chose these two because Oracle is a major vendor of ERP systems and well placed to integrate their BPMS offerings and Adobe, although not a developer of ERP systems is one of the world’s largest and diversified software companies whose specialisation has been on the desktop.
I was interested to see if the different backgrounds of these vendors would be reflected in their products. The first point of comparison is the BPM Engine.
The BPM engine is essentially a server providing the technical nervous system for the BPMS. It must manage communication and database connections, data and process flows, allocate and de-allocate resources and provide the executable environment for the various applications that use it.
The functions within a BPM engine generally require IT infrastructure; such as Microsoft .NET or J2EE the java platform supported by SUN Microsystems and others. Some vendors write their own languages (such as BPEL) and application servers rather than use the native support from major IT vendors. In for example standard web page servers such as Microsoft IIS or open source Apache are replaces by propriety applications servers providing similar functionality.
Not surprisingly both Adobe and Oracle support a Service Orientated Architecture that facilitates component based architecture. Therefore they both support Web Services and the full suite of standard communication protocols (eg HTTP, SMTP) and data formats (XML).
They also run on both J2EE (Java) and Microsoft .Net application servers/platforms. This is important because organisations will have an existing commitment to a development platform and will not necessarily want to maintain two different environments and indeed this is often creates tension and unnecessary conflict within development teams.
However both of these products require J2EE application servers so in a Microsoft Internet InformationService (IIS) environment it may require maintaining two technical skills sets (both .NET and Java) in the enterprise.
Of course the whole point of Web Services is to be a language agnostic, message based environment however typically organisation cannot avoid doing work in the native languages of a particular platform.
Integration of both products to existing IT infrastructure however is good since they both support the full set of Internet and SOA protocols and services (for example WSDL, email, XML, JDBC, HTTP GET and POST) and many other protocols enabling connectivity to back end systems and services.
Oracle uses their BPEL product as a development platform. Therefore if the organisation doesn’t already have a commitment to an Oracle based ERP solution (like PeopleSoft for example) there will be significant start up costs in training and support to develop using this language.
Both Oracle and Adobe support Application Programming Interfaces (API) to their systems but only for Java and Web Services are required from other languages.
Both have graphical user interfaces for modelling and design and in the case of Adobe this has the distinct advantage of having the look and feel of familiar Adobe desktop products. It also offers a library of templates and components for assembling and creating workflows without programming. On the other hand the Oracle, with its years of investment in languages and programming tools has taken the path of using the usual drag and drop graphical capability to produce fully operational BPEL code. Their BPEL Designer then is a far more capable product in terms of capability but again to get the most out of this an enterprise may need a significant investment in an Oracle ERP based system. The Oracle product also includes wizards to model common process and work flows.
The scalability of both Oracle and Adobe are similar since they both provide for load balancing, clustering of servers and Light Weight Directory Access Protocol (LDAP) for user management. This is essentially achieved on both systems by using standard technology from major IT service providers rather than creating their own propriety architecture.
Similarly both use the XML based query language XPATH and SOA services for the creation, control and maintenance of business rules. Both have graphical tools to achieve this.
A cost comparison is not possible because of the many variations vendors use to determine their pricing so for this class of software it requires creating a request for proposal or similar and soliciting quotes. The article mentioned the cost of the Oracle BPEL Process manager at $40k per processor (at the time) and the Adobe price is only available after requesting a consultation.
Personal Reflection
This class of software is difficult to select and as mentioned organisations would typically outline their requirements in a document and call for a request for a proposal (RFP). In my experience alarm bells should start ringing when the only means to establish the cost is to go through this sort of process. Typically vendors will seek to charge on the basis of ‘what you can afford’ particularly for larger organisations.
There are complex variations of charging models with named users, seats, client access licenses and so on making the comparison of costs between various systems difficult to ascertain. The selection of a product on technical and operational issues is difficult enough but the sales process is often more challenging especially if there is the opportunity to split offerings into many modules and dependencies further complicating the purchase decision.
The sales division of vendors in this class of software are often focused on maximising the return for the vendor rather than simply selling a product as is the case with vendors that sell mainstream ‘off the shelf’ products.
[This is an extract from an essay I wrote as part of a Master of Commerce assignment – Doug Robb, Clarity Software]
Additional Reading
Harmon, Paul. Business Process Change (Chapter 15,16).
Khan, Rashid N (2006). BPM A Global View, BPTRENDS web site.
