ASPnews Home





ASP Directory


About Us

Search ASPnews:
Internet Lists
Internet News
Internet Resources
Linux/Open Source
Personal Technology
Small Business
Windows Technology
xSP Resources
Corporate Info
Tech Jobs
E-mail Offers
Be a Commerce Partner
Cheap Plane Tickets
Digital Camera Review
Register Domain Name
Memory Flash Cards
Online Education
Remote Access
Advertising Trucks
Online Degrees
Best Digital Camera
Cheap Web Hosting
Digital Camera Review

ASPnews Focus
Top News:
» SOAs So Close, Yet So Far

» Why SaaS Is Making a Comeback

» Join the Discussion:'s industry forums

» More ASP News

TOP 50
Top 20 Providers
 & Top 30 Enablers
Free Newsletter!

ASPnews Shortcuts
Week's Top News

ASP News at

Industry Events

Discussion Forums

Industry Basics

Site Guide

Gain valuable insight on managing complex IT environments from the Meta Group. Learn how to better assess service problems and understand how your business is impacted when failures do occur.


The Case for Developing a Service-Oriented Architecture, Part 1

Continued from Page 1

The First Problem: Complexity

Some things are always the same, particularly the business problems facing IT organizations. Corporate management always pushes for better IT utilization, greater ROI, integration of historically separate systems, and faster implementation of new systems, but some things are different now. Now, you find more complex environments. Legacy systems must be reused rather than replaced, because with even more constrained budgets, replacement is cost-prohibitive. You find that cheap, ubiquitous access to the Internet has created the possibility of entirely new business models, which must at least be evaluated since the competition is already doing it. Growth by merger and acquisition has become standard fare, so entire IT organizations, applications, and infrastructures must be integrated and absorbed.

In an environment of this complexity, point solutions merely exacerbate the problem, and will never lead us out of the woods. Systems must be developed where heterogeneity is fundamental to the environment, because they must accommodate an endless variety of hardware, operating systems, middleware, languages, and data stores. The cumulative effect of decades of growth and evolution has produced severe complexity. With all these business challenges for IT, it is no wonder that application integration tops the priority list of many CIOs, as shown in Figure 1.

Figure 1. CIO priorities

Another Problem: Redundant and Non-Reusable Programming

Consider a bank that has separate “silos,” self-contained application systems that are oblivious to other systems within the bank. The first of these application systems may have been an excellent design, as well as the second, third, and so on, but each was produced by and for a different line of business within the bank and was a separately funded, isolated project. Thus, for example, the function of get account balance is repeated in the ATM system, the branch teller delivery system, and the credit card scoring system, even if they access the same account data in the same database.

Now, suppose the bank must develop an Internet service, online banking, and/or an online loan origination system for its customers if it is to remain competitive. The new system will just add to the problem of all the redundant programming already in place, unless somehow the existing code can be reused.

The Real Integration Killer: Multiplicity of Interfaces

Consider also the n(n-1) integration problem. All organizations face integration problems of some sort; perhaps because of a corporate merger, a new business alliance, or just the need to interconnect existing systems. If n application systems must be directly interconnected, it will produce n(n-1) connections, or interfaces. In Figure 2, each arrowhead represents an interface.

Figure 2. Direct integration of n applications

Consequently, if another application system A n+1 must be integrated, it will require that 2n new interfaces be generated, documented, tested, and maintained. While in the diagram above, where the set of five applications requires 20 direct interfaces, the addition of a sixth application will require ten new interfaces!

Worse yet, the code in each of the existing applications must be modified to include the new interfaces, thus generating substantial testing costs. Immediately, you look for the optimum solution that produces the minimum number of interfaces (n) for n applications, with only one new interface for each additional system added, but find that it can’t be done by direct connection.

Page 3: And What of the Future?

Go to page: Prev  1  2  3  4  Next  

Email this Article
View Printable Version
Back to Analysis


Featured Links
Learn the secrets of the popular search engines!
Free Web Hosting Buyer's Guide -- Click Here!
Enhance your Web site with the Dynamic HTML HierMenus Code

JupiterWeb networks:

Search JupiterWeb:

Jupitermedia Corporation has three divisions:
Jupiterimages, JupiterWeb and JupiterResearch

Copyright 2005 Jupitermedia Corporation All Rights Reserved.
Legal Notices, Licensing, Reprints, & Permissions, Privacy Policy.

Jupitermedia Corporate Info | Newsletters | Tech Jobs | Shopping | E-mail Offers

Give us your Feedback