System iNetwork

October 2, 2007

Business Process Integration: Sorting Your Spaghetti

LANSA made headlines this week by announcing the October 15 release of LANSA Composer, a business-process integration (BPI) application for the System i. To summarize it very briefly, it's a solution that lets even nontechnical users map out the data connections, software integration steps, and document outputs for applications. Then Composer automatically generates the code to make these connections happen. It takes a "top-down, process-centric approach," to quote the press materials, to helping organize how information moves to support business activities, among other functions.

This type of application brings home to us once again the value in general of computer automation to business. Particularly in larger corporations, the interconnections between business processes, the applications that help drive them, and the data sources that feed them are often complex enough to make the most diehard spaghetti coder proud. Any application that lets someone other than a developer be able to use graphical symbols to map, and by extension reorganize, these processes, can be helpful to the bottom line. This is particularly true in some of the intangible ways, such as the time saved for people and computers when processes are realigned in a more efficient way. So it's good to have applications like LANSA Composer for the System i because it helps System i shops enjoy this kind of mainstream benefit even though the platform remains something of a minority enthusiasm in the business world in general.

However, Composer has a drawback, and that's that it's Java-based. So if you're not running JVM on your System i and don't have immediate plans to, Composer is a solution that will remain beyond your grasp for a while.

Unfortunately, that's also true of virtually every other integration application for the System i! That's because for the System i, Java seems to be an indispensible feature for nearly every application of this type. When I say "this type," I really mean several types. Most of Composer's competitors term themselves "transaction integrators" or "enterprise application integrators (EAI)" and are the kinds of products that developers rather than end users use. LANSA Composer's ability to let ordinary end users (e.g., manager types) use graphical representations to plot application relationships makes it stand out, but it's not the only solution that enables System i application integration.

Composer is based on LANSA Integrator, a product that's been available for years. Integrator enables application-to-application and B2B transactions via XML and Java services. Primarily aimed at facilitating e-business, Integrator also provides such services as secure PDF documents for contract documents, information exchanges between ATMs and backing systems, and SMS updates on transactions or deliveries. Two other Integrator functions, though, are enabling the integration of Java services with RPG, Cobol, and C applications and the ability to publish or use third-party web services via the Simple Object Access Protocol (SOAP). We'll return to those in a moment.

IBM's WebSphere includes several EAI or process integrators. These include WebSphere Business Modeler, WebSphere Integration Developer, and WebSphere Process Server. These let you model business processes and integrate existing business applications with each other. However, to get these solutions, well, you have to buy WebSphere.

Magic Software's iBOLT Business Integration Suite helps developers integrate legacy applications with other databases and other applications. It includes a modeling environment that lets users create and map business processes and flows, a deployment module, and a monitoring component. However, it requires the Apache server (or by extension, WebSphere).

EXTOL Business Integrator is a family of products that provides an application server and runtime repository that indirectly integrates applications by automating data inputs and outputs. It also offers user-defined process models. Like LANSA Integrator, though, its primary focus is e-commerce: It's mainly used to facilitate integration between "front-end EDI systems and back-end applications and data."

Red Oak Software recently upgraded its Legacy Integrator, a transaction- and application-integrator solution for System i, System z, and Unix servers. Java-based and running under NT and Unix, Legacy Integrator nonetheless can pass data to and from System i applications and applications on other platforms via 5250 Java emulation. (Red Oak also offers the coincidentally named Legacy Composer, which transforms legacy application functions into Java-based objects for integration with other applications and works with Eclipse).

TIBCO Software's TIBCO BusinessWorks is "standards-based integration backbone" that accomplishes EAI without Java and runs on the System i. It has two problems, though. First, it only runs under AIX, not i5/OS. Second, it requires a Service-Oriented Architecture (SOA).

Jacada's HostFuse is a solution that integrates legacy applications by "service-enabling" them, and it runs under i5/OS. However, it's for developers and also requires an SOA structure.

This is by no means an exhaustive list of solutions for System i application integration. In addition, there are a number of other product types that one could argue foster it.

For example, you could make the case that most enterprise resource planning applications embody significant elements of both BPI and EAI because they unify multiple business functions, if not multiple applications, into a single system. Solutions that can schedule application jobs can also provide a functional way of determining a sequence of application actions and data flows. SOA, pretty much by definition, is a means of integrating business processes by turning the applications that support them into web services. This is where the LANSA Integrator SOA functions come in and where many solutions that facilitate building an SOA overlap strongly into the BPI concept, so much so that it's hard to know where to draw the line between them. (Not for nothing, then, is the SOAP acronym being changed lately to mean "Service-Oriented Architecture Protocol," an amusing example of one time when an acronym is driving the jargon instead of the usual other way around.)

So to return to LANSA Composer, which started off this whole train of thought, we can say that this is a product that is also somewhat distinguished by what it isn't. It isn't a product that's just for programmers. It doesn't require WebSphere or Apache server. It doesn't require an SOA. And it isn't primarily just for e-commerce applications.

It's too bad, though, that we don't have an application like LANSA Composer that runs natively under i5/OS and is aimed at nontechnical users. It makes sense that Java provides a unified way of providing the integration services that LANSA Composer does, and that facility of Java's is no doubt one of the reasons LANSA based Composer, and all the other vendors based their integration products, on that language.

However, not everyone wants to use Java, even though many enterprises could use a BPI app...

Posted by at October 2, 2007 1:08 PM