Understanding Enterprise SOA | WebReference

Understanding Enterprise SOA

Understanding Enterprise SOA: SOA for enterprise application integration

Written by Eric Pulier and Hugh Taylor with forward by Paul Gaffney and reproduced from "Understanding Enterprise SOA" by permission of Manning Publications Co. ISBN 1932394591, copyright 2005. All rights reserved. See https://www.manning.com

The following excerpt continues to look at the IT and management issues at Titan Insurance, a fictitious business that the book uses as a case study in Service-Oriented Architecture. The excerpt refers to "Jay," who is an employee of Titan's IT department. There is also a reference to the "Atticus Finch Technique," which refers to a process of asking a question only when one knows the answer in advance. (An allusion to the novel, "To Kill a Mockingbird".)

    5.1 Is Titan happy with its EAI?

    5.2 How web services can simplify EAI

    5.3 Web services in portals

    5.4 Web services in software development

    5.5 The savvy manager cautions: limitations of web services in EAI

    5.6 Summary

I explain to Jay that web services and the service-oriented architecture (SOA) have the potential to facilitate real change in enterprise application integration (EAI). In addition, the new technology can have a major impact on two related areas: portals and software development. All three of these endeavors currently suffer from difficulties caused by proprietary standards. In this chapter, we look in detail at the way the open nature of web services may offer some welcome relief.

5.1 IS TITAN HAPPY WITH ITS EAI?

Using the Atticus Finch technique, I ask Jay a question to which I already know the answer. "Is Titan happy with its EAI?" Groan. "Yes and no," he admits. "Obviously, we like what it can do for us. We just don't like the cost, inflexibility, personnel demands, and—"

"The tight coupling," I say, cutting him off.

"Right," he agrees with a laugh. "The tight coupling." Titan uses a proprietary EAI technology on the legacy architecture from Apollo Insurance. As shown in figure 5.1,

the EAI solution provides a connection between the policy, claims, and financial systems. As is, it works fine. The problem is expansion and change management. Titan will need to buy more modules of the solution if it wants to connect the Apollo systems with the old Hermes architecture. That has indeed been considered, but temporarily rejected because the company wants to avoid buying more proprietary software that will further lock them into that one vendor and create permanent positions for software engineers who will be needed to maintain the system.

"What's more," I say, "you're lucky it works as well as it does."

5.1.1 First, the truth: EAI is broken

The unfortunate truth about EAI is that it often doesn't work. A recent Forrester report indicated that almost 65 percent of EAI projects are late or over budget. Yet, they cost on average over $6.4 million to complete—those that get completed, that is. EAI is generally a far longer and more expensive proposition than the final outcome would justify.

5.1.2 Islands of integration

Why do EAI projects go so badly wrong? Among the primary reasons that we will explore, perhaps the most problematic issue is simply the unstructured way EAI often just takes shape in an enterprise. Figure 5.2 depicts a typical EAI architecture early in its life cycle. Your company has three systems, but for any number of reasons—cost, management preference, politics, and so on—different parts of your company have elected to use two different EAI packages. Package A integrates accounting with the customer service department's customer resource management (CRM) while Package B integrates accounting with the mainframe. At this point, your company has to maintain (and pay maintenance fees) for one module each from two EAI packages. A third vendor may provide yet another proprietary EAI package.

As time goes on, your company adds such new systems as enterprise resource planning (ERP) and a website. What happens if you need to connect CRM with ERP? In the majority of cases, you will have to buy additional modules of the EAI package to accomplish this task. You will require the "ERP to mainframe" and "ERP to CRM" modules, a situation shown in figures 5.3 and 5.4. Of course, each module brings with it annual maintenance fees. Adding EAI modules not only increases your IT management complexity, it also raises your budget permanently.

Whether the integration is done by a proprietary EAI package or through a custom development program, the result is usually a set of "islands of integration" in the enterprise. When integration is then extended beyond the firewall, the issues become even more complex. Figure 5.5 illustrates this dilemma. What if you need to connect

your website to accounting? Again, what you get is a turf battle between the various EAI platforms. Package A's maker tells you that it makes sense to drop B and C so that everything will "work together." In addition to costing a fortune, you are still hampered by Package A's proprietary technology. What if you need to connect your ERP with the vendor's ERP? To do that using traditional EAI methodology, either you or the vendor would have to switch packages, and that just ain't going to happen. You can always create your own custom interface, but that is a whole other set of problems, among others that we will now explore.

Created: March 27, 2003
Revised: December 2, 2005

URL: https://webreference.com/programming/enterprise/1