The Evolution of Business Process Integration
The convergent demands of enterprise application integration (EAI) and B2B commerce are driving IT departments to look for new, advanced solutions that must be easy to deploy, responsive to rapid change, and hugely scalable and interoperable in a heterogeneous environment. Process-oriented middleware, the evolutionary successor to message-oriented middleware, grew in response to such demands and now offers a powerful tool to simplify IT systems management.
Early holistic approaches to IT simplification, from business process reengineering to enterprise resource planning, proceeded on the premise that standardization - of applications, processes, and data formats - would solve the integration problem. After all, in a homogeneous environment, there are no disparate elements to integrate. In reality, these projects tied up a daunting number of resources for an inordinate length of time and only produced yet another integration point in an IT system that continued to increase in complexity. In an economy where only agile organizations survive, monolithic programs will fail to yield the expected benefits in a timely manner.
Later integration solutions focused on message-oriented middleware, a hub-and-spoke framework that reduced the business process to its atomic elements of message requests and responses, envelopes and payloads, and formatted segments and fields. Business transactions were represented by the unsynchronized delivery of messages to mailboxes. A centralized message broker transformed and routed messages. Customized code was written to interact with enterprise information systems. The actual act of the business doing business, or the business process, might be reconstructed as a disjoint collection of custom log entries and message notifications.
The implementation of the message-oriented middleware framework and its add-on integration applications was a labor-intensive activity and entirely the IT department’s responsibility. It was impossible to engage other parts of the organization or domain experts in the organization’s economic objectives, strategic alliances, commercial tactics, and business procedures. The detailed programming knowledge required to manage these frameworks was an effective barrier to the involvement of people other than information systems technicians. Thus, requirements were difficult to gather, and the complexity of the system made the required changes difficult to implement.
Meanwhile, integration pressures continued to mount. Mergers and acquisitions left in their wake a sea of incompatible and redundant application systems that were suddenly required to interconnect. Threats from global competition as well as the opportunity for global expansion extended the enterprise application integration challenge beyond the organization’s four walls, through the firewall, across the Internet, and around the world. The Internet economy demanded an almost frenzied responsiveness that could not be achieved without tighter integration with partners, often with those who were partners in one area and competitors in other areas. Standards emerged to accelerate intense collaboration and participation in extended business processes across the Internet.
As is often the case in the software industry, such challenges gave rise to a paradigm shift. Instead of focusing on atomic message elements, visionaries began to suggest a focus on the entire business process. Business process integration combined with enterprise application integration to create the process-oriented middleware framework. The focus of process-oriented middleware is on the business process, or the sequence of actions that achieve a business goal, either entirely inside the enterprise or in collaboration with its trading partners. The process can be represented graphically or in a flow chart in a manner meaningful to the business stakeholders. Most importantly, this flow chart can be executed and monitored.
This process focus engages the cooperation of personnel outside of IT. Not only are requirements easier to gather, but other parts of the business can help in constructing the process models. At a time when IT resources are in short supply, such help is a welcome addition to the project.
Outside the enterprise, emerging industry standards are establishing the business process as the atomic unit of work. RosettaNet, ebXML, business process modelling language (BPML), web services flow language (WSFL), XLANG, and others support the advertising and discovery of business process abstracts between trading partners. An agreement is established based on the process abstract, private implementations of the process are supported through the standard, and collaborative e-business is conducted.
Inside Process-Oriented Middleware
The chief benefit of process-oriented middleware is its ability both to model and to execute the business process. Earlier workflow systems that modeled role-based interactions such as escalation procedures without sufficient detail to make these models executable are of limited benefit to IT. Emerging process execution languages such as BPML represent the next evolutionary step in workflow management. They provide a standard XML-based syntax for process models. They also provide a rich set of execution features such as security and transaction integrity.
Let’s examine the process model as BPML or another modeling language is likely to depict it. In a process model, a process is a sequence of activities launched by a business event and concluded when a business goal has been achieved. Each activity receives a document (business data or a request), manipulates the document, adds other information to some document context, evaluates what to do next, and passes the document and its context along to the next appropriate activity. A simple sequence is too restrictive to handle the dynamic decision-making most business processes require, so let us imagine the flow of activities following a variety of patterns:
- A choice, where an evaluation of some expression is made and the next activity is chosen based on the result.
- A split, where multiple activities are spawned from the current activity and the child activities run in parallel.
- A join, where the results of a number of activities are united to be further processed by a common activity.
- A fault handler, a sub-process launched to compensate for errors detected by the process.
- A loop, where a sequence of activities repeats for a specified number of iterations or until some condition is met.
These patterns make the business process quite flexible. If one adds the ability to interpret business rules for dynamic decision-making, then the result is a system designed to be responsive online to changing business needs.
The process model supports an incremental project approach where larger processes can be built from other processes. This incremental approach is particularly inviting to business personnel outside of IT. From a pallet of predefined processes, the business analyst can construct a higher-level flow of activities without being concerned about the finer details already configured in processes s/he is using as building blocks and yet, without having to manipulate these details, construct a fully executable process, whose details can be monitored and audited.
To learn more about how these business processes are executed, let’s go deeper into the composition of a process. The activities that make up a business process can be subdivided into two logical components, an internal and an external component. The external component is tied to an element in the environment with which it communicates; this could be an application, a communications channel, an API, or an interface for human interaction. The internal component ties the external component to the engine that executes activities. Freed from a human, application, or technology interface, the internal component is easier to scale. In a clustered environment, the internal component can be replicated and moved freely from machine to machine. Scaling for the external component is also possible but trickier as the component continues to need access to the port, disk, socket, or other interface with which it communicates.
To meet scaling requirements, each activity should operate on a separate thread with a queuing mechanism to exchange its document context information with other activities. For the reliability demanded by the enterprise, sufficient state-related information should be maintained in the document context and persisted to disk so that the activity could be restarted or resumed at any time.
A Role-based Project Approach
As the previous section shows, there are some implementation details of interest to the IT professional that are not of particular interest to the business domain expert. A successful project should support the collaboration of personnel with different business and technology expertise by leveraging their knowledge and segregating from each the details needed exclusively by others. Specifically, a business process integration project should be staffed to fill three roles:
Business Specialist
The business specialist understands the organization’s business processes and business rules. Using a graphical modelling tool, he should be able to diagram information flow from activity
to activity. He cares about the content of business documents and understands their meaning to the business.
Collaboration Specialist
The collaboration specialist understands the agreements made with trading partners. He is familiar with industry collaboration standards and protocols. He can read a business process abstract. He knows the auditing requirements for end-to-end transactions. He has a detailed understanding of his business document requirements and can map his document requirements to those of his partners.
Technology Specialist
The technology specialist understands his enterprise’s applications, databases, and operating systems. He can execute processes and monitor them and fine tune performance. He performs system maintenance activities such as backup and restore.
The collaboration and technology specialists may have to do all the work to implement an integration program on a message-oriented framework. There is no convenient point to engage the business specialist. Depending on the maturity of the framework, the technologist may get all the work. If the connection to applications is custom code and if no standards are employed, the work consists mostly of programming, which is the domain of the technology specialist and provides little opportunity to seek help from the collaboration specialist.
An integration program that is based on a process-oriented framework should engage all three specialists. In a mature application, the work of the technology specialist should be minimized. The program should have a stock of preconfigured activities and processes to assist the business specialist in modelling processes. The program should leverage industry standards to assist the collaboration specialist in preparing maps and establishing trading partner agreements. No coding should be required. Sophisticated monitoring and auditing interfaces should allow the technology specialist to view operations from a machine perspective while also letting the business specialist view operations from a process perspective. Both kinds of tracking are essential in an enterprise production environment.
Meeting the Needs of the Enterprise
Process-oriented middleware can meet enterprise reliability, scalability, and interoperability needs while at the same time establishing credible links between the execution of activities to the business objectives they serve.
Real-time visibility in business processes across organizational boundaries is the key to an effective multi-enterprise collaboration. If you can see business as it happens — particularly if it involves many processes and participants — you can manage it faster, smarter, and with greater agility.
 Pat Cheong is the Regional Director of Sterling Commerce Asia, a company that provides collaboration solutions for retail, consumer packaged goods, manufacturing, and telecommunication industries and financial and healthcare services.
|
