| home / programming / enterprise / 1 |    [previous][next] |
|
|
|
A long development and implementation time frame is another factor that impacts the effectiveness of EAI. The average project life cycle is 10 to 20 months. The time required to sort out political issues in the organization (itself a factor that can potentially kill EAI before it even starts), select a vendor, gather requirements, and then implement the solution may be so long that the early goals of the project are obsolete by the time it is completed.
The unintended result of EAI is often the creation of a high overhead “job for life” for a developer with specialized EAI package skills. When combined with the obligation to pay recurring maintenance fees on proprietary packages and buy add-on EAI components as systems grow and change, an EAI project can create a long-term maintenance overhead that is untenable.
Change management is perhaps the greatest cause of problems in EAI initiatives. With conflicts in data message definitions or mismatches in proprietary components, a change to either side of a set of integrated system necessitates a cumbersome and often costly change implementation process.
If you were to expose the functionality of each system as a web service, in theory you could start to solve some of these challenges. Figure 5.6 shows what the SOA would look like. The systems in the SOA all interoperate using SOAP. There are a number of striking benefits from adopting this kind of SOA for EAI purposes:
• You can now create interoperation between any number of systems that were previously locked into their respective “islands of integration.” • Change management becomes far simpler. You can modify or swap systems with great ease. • You are no longer beholden to the proprietary EAI package. If you want to connect new systems, you don’t have to buy any special modules or pay additional maintenance fees. • The EAI expert with the “job for life” is not needed. |
Comparing EAI and SOA side by side shows several differences between the two approaches to creative interoperation of systems. Table 5.1 presents a high-level comparison of EAI and an SOA based on web services. In each category, the SOA is more open and provides greater enabling of interoperation without reliance on proprietary vendor platforms. However, as we see in the next section, achieving integration of systems and applications using a web services–based SOA is not without challenges and limitations.
Portals, which can provide unified access to multiple applications, are in many ways comparable to EAI. As portals gain in importance with corporate users, the IT departments that develop and support those portals have come under increasing pressure to be more flexible in content delivery while continuing to trim the budget. Web services can deliver both of these desired objectives to portal management.
A portal is a browser-based application that presents content and functionality from a range of sources on one screen. For example, an employee portal at a business might contain human resources information, calendars of special events, sales forecasting interfaces, and so on. Each of these separate areas on the portal may originate from a different system within the business. Some content areas in a portal may come from outside the business, as would be the case with a weather report, for example.
Figure 5.7 shows a typical portal architecture. The portal draws content from a number of different systems. To get the information or functionality from the originating system to the portal, the portal developer must write a custom interface or buy a portal package that connects underlying systems to portals. Either way, it is a timeconsuming, inflexible, and often expensive system. The workload and budget required to maintain a portal built in this manner can be quite substantial.
As shown in figure 5.8, web services provide an effective way of reducing the complexity and overhead that comes with custom-coded portal interfaces. With each supporting system exposed as a service, the portal can draw its content and functionality from each system without the need for any custom-coded connectors. The result is a simpler, lower-cost portal.
Change management in the portal environment is also greatly improved by web services. With a web service architecture, a portal can flexibly change its content sources. Figure 5.9 shows how a portal developer can “swap out” content sources by plugging in new web services.
| home / programming / enterprise / 1 | [previous][next] |
Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Shopping | E-mail Offers | Freelance Jobs 
Created: March 27, 2003
Revised: December 2, 2005
URL: http://webreference.com/programming/enterprise/1
