Commerce One Conductor takes on integration

What business really wants from IT is automation of the processes that make the business go. Ironically, the very enterprise-level support systems that CIOs installed in the ’90s to support HR, customer service, accounts receivable, and so on are the primary hurdle.

Business processes typically cut across system boundaries and require the interoperability and choreography of multiple systems. Yet, most enterprise-level support systems focus instead on one task without thinking about working with other systems. Web services promise to solve the problems of integrating these enterprise systems and most vendors already support basic Web services protocols — but the real problem is that tricky integration process.

There are basically three choices to integrate systems with Web services: (1) write a custom application in Java or some other programming language that interfaces with enterprise systems and creates the integrated functionality; (2) buy message buses, integration brokers, business process modeling tools, and other middleware and configure them to provide the functionality; or (3) buy an all-in-one integration suite such as Conductor from Commerce One.

The advantage of an integrated solution, like Conductor, is that someone else does the difficult task of making everything work together. What’s more, as an application, the integration comes with useful features and tools that you can’t afford to build if you’re doing the integration yourself. This is certainly true of Conductor, an impressive package of tools that is greater than the sum of its parts.

More Than Just Interoperability

Conductor is fundamentally a Web services intermediary: Its interoperability engine forms a layer between various enterprise systems and services to ensure that everything can talk to everything else. It does the hard work of translating protocols, ensuring message delivery, and managing services such as security. But Conductor exceeds the standard interoperability engine, providing a sophisticated suite of tools for building and operating applications that automate business processes.

The heart of Conductor is the registry, an all-purpose directory of services, users, documents, and transformations that the rest of the system uses to compose custom business processes. The rest of Conductor is designed to make maximum use of the registry; consequently, business process applications built in Conductor automatically respond to any process change a user makes, reconfiguring connections as necessary and without maintenance.

Building a business process application requires some sort of programming language, too. BPEL (Business Process Execution Language) is emerging as the standard way to specify business processes, but Conductor makes use of its own internal language to create business processes instead. You never see Conductor’s internal language as such, because you create business processes and link them to services in the registry using graphical programming tools called the Graphical Process Builder (GPB).

GPB allows easy visualization of the process flow, decision points, and actions taken. Some might perceive the lack of support of BPEL as a weakness, but I think it simply reflects the instability of the BPEL standard as Conductor was being developed.

Where the interoperability layer connects services together, Conductor’s presentation manager provides portal services and acts as something of a central dashboard. During design time, portal services allow administrators to manage the registry and define application components; at run time, the portal services enable human interaction with the business process. Screens for the portal service are created in GPB and a Conductor-supplied Eclipse plug-in called Design Center, so you can easily present custom, interactive pages to business process users.

Suppose you’ve built an application in Conductor to manage a parts-ordering process. The process might take orders from an existing enterprise system through the interoperability layer and send them to the correct supplier, performing message translation, logging, and security functions on the fly. After the application has been deployed, management decides that orders over a certain amount need to have supervisor approval.

Adding this new step is simple: Use GPB to add a decision point and conditional step to the overall process flow, and a new approval screen is created automatically in Design Center. Now when the system determines that an order needs supervisor approval, an alert is sent to the appropriate supervisor, who logs into the system, reviews the order, and decides whether to approve it. User roles, also maintained in the registry, protect various authorization steps so that only authorized personnel can perform the required action.

Quick and Flexible

Conductor benefits from Commerce One’s roots as a B2B e-commerce tools vendor, as it comes with xCML, Commerce One’s set of XML-defined business documents (purchase orders, invoices, etc.) for common business processes. In addition, Conductor supports other XML-based business documents, such as those from Ariba, and even supports user-defined documents.

Unlike many EAI tools, business process automation with Conductor can proceed one process at a time. An IT shop can bite off the business process automation task in small pieces, reducing the overall complexity. Once the process is in place, Conductor’s flexibility (and excellent GPB interface) eases the maintenance burden by making changes to business processes quick and easy.

One weakness that I hope will be remedied in future versions is Conductor’s inability to federate with the enterprise’s existing identity infrastructure. Not being able to tie into existing directories for user and role information forces you to repeat the data for each system and creates real administrative headaches.

Also, an important caveat to keep in mind: Tools like Conductor are not simple to use. This is not a slam on Conductor — it’s simply a recognition that automating business processes by integrating multiple legacy systems is a complex process. The user guide tutorial supplied by Commerce One is almost 100 pages long, and that’s probably not long enough to really explain what’s going on.

Complex tasks require complex tools with large learning curves; learning to fly a plane isn’t easy, but it facilitates actions that you can’t do the old way. Despite its inherent complexity, Conductor is an impressive suite of tools that gives organizations a reasonably priced platform for integrating legacy applications or automating Web services-based business processes with trading partners.