Editorial

In a March 2002 survey by Morgan Stanley, 225 CIOs listed extending their current IT investments through application integration as their number one priority. This is not surprising. Given the slow economy, many Fortune 500 companies are putting off large new packaged-application initiatives, and are looking to make do with what they've got. Why start a multimillion-dollar ERP project when half the company's users can't make use of the applications that are already installed (or sitting on the shelf)?

But when I talk to CIOs about their "application integration" needs in more detail, I don't get a consistent story. One of the reasons for this "impedance mismatch" is that there are really several different forms of application integration. This creates a huge risk because vendors and IT buyers are nodding in agreement about the need for application integration, but each has a different vision of what that means.

In a former life, I encountered the same problem as I managed the integration of software products acquired by a major software vendor. Let me offer you this more concise way to describe application integration, along with examples and the pros and cons of each approach. Using this nomenclature may help you avoid a misunderstanding that results in disappointment or project failure.

Forms, Degrees, and Mechanisms

There are four basic forms of application integration:

• Presentation
• Workflow
• Data
• Component

These integration forms are largely independent of each other and they address the layers in a traditional architecture stack. Each integration form can be taken to many degrees (based on ROI), which correspond to the complexity or depth of application integration. Integration mechanisms refer to the implementation technology used to accomplish the integration.

Presentation Integration
The presentation form of application integration has to do with having a consistent look and feel (also known as a skin) and common commands within an application and between applications. It also involves the personalization and customization of different application views, depending on which user is logged on.

Example Mechanism: Portlets
Portlets are user-interface components that end users see within a portal. Like a window on a PC or Mac, each portlet owns a portion of the browser or wireless device's screen where it displays views of an application (or content) and provides results. Portlets can be as simple as a message board or as complex as an order entry into an ERP application. Portlets can be designed, assembled, deployed, and managed using a variety of enterprise portal solutions. Some portal products have the ability to rapidly create portlets out of existing content or Web applications, and leverage a variety of technologies (e.g, JSP, servlets, .NET, DHTML).

Pros:

• Portlets are low risk, and give quick, high bang for-the-buck results.
• Portlets allow you to selectively expose different pieces of application functionality to employees, customers, partners, and suppliers without having to install software on each client (or future upgrades).
• Portlets Web-enable existing applications and provides a way to surround them with other enhancing tools and technologies (like collaborative Web services).

Cons:

• Doesn't add new functionality to (or replace) existing applications
• Encapsulating an existing application that is already disliked and putting it within a portal may be like putting lipstick on a pig. It may be pretty, and pretty disappointing.

Workflow Integration Workflow integration enables organizations to create and manage Web-based business processes between employees, customers, and business partners.

Example Mechanism: Event/Condition/Action (ECA) Rules Engines
ECA rules engines automate business processes in response to events involving systems or collaborative processes within a group of users. The rules engine receives events that are sent to it as events occur inside a portal or enterprise application. The rules engine applies conditions to the events and if they fall within the condition parameters, the rules engine invokes an action. The rules represent business logic for deciding whether e-mails are sent, alarms are triggered, counters are advanced, or other software services are invoked. Examples of products that include business process automation tools are BEA WebLogic Integration, Savvion Business Manager, and Mongoose PortalStudio.

Pros:

• Enable you to automate and streamline business processes that include interaction among people and systems in order to reduce costs and time delays.
• Provide consistency, respond to exceptions, and take corrective action.
• Routes tasks, documents, and information between people and systems.

Cons:

• If not properly designed, workflow integration can be inflexible because it's a tightly coupled way to talk to existing systems.

Data Integration

Data integration is the most common form of application integration. Every business needs to aggregate, transform, and integrate data in order to reduce costs and inventories, increase revenue, and improve competitive positioning. There are a wide range of formats (e.g., XML), metadata, infrastructure, databases, and applications with which business objects and transactions interoperate.

Example Mechanism: J2EE CA Connectors
J2EE Connector Architecture (J2EE CA) is a nonproprietary standard for integrating applications with existing enterprise information systems. BEA, Insevo, Resource Adapters, TIBCO, and webMethods currently offer a variety of prepackaged J2EE CA-based connectors for leading ERP, CRM, and other corporate applications.

Pros:

• Allows you to share data across and beyond your enterprise.
• Eliminates the time, effort, and expense of a traditional EAI or B2B integration project.
• Provides a real-time view of your business, allowing you to get up-to-the-minute information from all of your systems and applications.

Cons:

• J2EE CA-based connectors aren't available for every corporate application.
• Some connectors do not support bidirectional data transfer.
• For highly complex data integration requirements (longer and more complex value chains), J2EE CA alone may not be sufficient.

Component Integration
Effective sharing and reuse of code is one of the holy grails of software engineering. Component integration has to do with developing fundamental building blocks (components and frameworks), making them readily available, and then leveraging them across enterprise systems in order to build robust and flexible systems with reduced development time and cost.

Example Mechanism: Web Services

Web services are self-contained, self-describing, component-based applications that can be published, located, and invoked across the Web. Web services perform discrete functions that can be simple requests or complex business processes. Standard technologies like XML, UDDI, SOAP, and WSDL are key parts of the Web services architecture. A Web service can be invoked from a portlet and can work with J2EE CA-based connectors (it's not a "one or the other" scenario). Products for developing Web services include AltoWeb, BEA WebLogic Workshop, and Microsoft Visual Studio .NET. Examples of XML-based Web services are Microsoft Passport and Sun Microsystems' Liberty.

Pros:

• Reduces the cost of building new applications and shortens the time it takes to get them into production.
• Increases interoperability between the various development environments so developers don't have to worry about which programming language or operating system they are using. Costs vary widely with each individual Web service. Commoditization will drive these costs down.

Cons:

• Web services are currently at the top of the hype cycle. Some clients talk to me about adopting Web services and at the same time they ask me just what a Web service is. It's important to set the expectations here.

No single integration form is a silver bullet; different companies have different integration needs. In many companies, there are several formal IT initiatives going on in parallel involving multiple integration forms. The specific integration strategies adopted by a CIO depend on many factors. This includes how well existing applications already work together and figuring out what type of integration would provide most bang for the buck (ROI analysis).

One survey said the average Fortune 500 company has 62 major corporate applications. These are normally a combination of commercially available ERP, CRM, or SCM applications, legacy (old, outdated) applications, database systems, and custom-built (proprietary) applications developed in-house using the latest and greatest technologies.

In some cases, the best integration strategy for the short term is to reach for low-hanging fruit. That is, to implement a point-to-point data integration between two applications that requires little time and/or resources. But it is important to keep in mind that point-to-point integration between applications, if not done carefully, can actually exacerbate the overall application integration problem in the long term.

Conclusion
With the current economic slowdown, there is a great demand to do more with current IT investments by integrating existing applications. While there is a tremendous opportunity for those who can deliver application-integration solutions, there is significant risk of failure due to the misunderstanding of the functional requirements, implementation, and business value of a proposed application-integration solution. By defining application integration in terms of forms, degrees, and mechanisms, you can manage expectations, drive requirements, and deliver the most business value.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...