Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

Enterprise IT rarely gets thrown away—it just gets integrated in a never-ending game of system-wide cut-and-paste for developers. From something as common as adding new applications to existing environments, to complex overhauls of legacy applications to be service-oriented, enterprises are constantly juggling integration challenges. Despite vendors' friendly talk about their approaches to SOA, ESBs, and integration in general, their practices are often predatory. These tactics range from locking customers into proprietary standards and unnecessary or unsuitable features, to astronomical licensing and services charges. Vendors have been sticking it to enterprise customers for a long time.

Consider behavior such as:

1. Up-Front Coding, Proprietary Toolkits

With many proprietary vendor solutions, you have to learn their methodologies and toolkits. There are countless stories of customers working with proprietary suites where the learning curve of integration in traditional J2EE and EJB environments is large and discouraging. Use their technology, for example, and you have to use their messaging system, which has an associated skill set requiring significant ramp-up. It reaches a point where the business value is severely diminished by the technical resources and finances required. Furthermore, many of these solutions require sizable development efforts at the onset, just to evaluate them against enterprise infrastructure.

2. Astronomical Licensing Costs

Enterprises pay exorbitant licensing fees for existing applications, and introducing new applications incurs further licensing fees. The biggest perpetrators tend to be vendors in the EAI and application-server space who charge for every dev stage, test license, and server-additional component.

3. Ongoing Services/Support Costs

Proprietary EAI, ESB, SOA, and integration products tend to have enormous professional services costs. Tibco, for example, generates more than 50 percent of its revenue from services performed on the company's own products, making you wonder just what the software requires to run at all. Moreover, when problems arise, customers have to submit issues to the vendor describing the problems. Because you can't see the code, there isn't a lot of information at your disposal to actually understand the source of the problem. So the best you can do is open a ticket and wait. But when experiencing enterprise software issues, waiting is not an option.

4. Getting Locked Into a Prescribed Approach

Many integration vendors—even those that try to be standards based—only use the standard for the protocol, but they don't use open standards for the methodologies by which you access the protocol (or anything else). Try weaning yourself from their approach and you risk breaking interfaces that you can't fully see or understand.

5. Feature Overshot

The downside of the SOA/ESB/WS-Star evolution is that to get an integrated stack where these things become meaningful and useful, you have to pay big money to single vendors. Oftentimes you are simply seeking to get "hooks" into information for basic integration stuff and don't need things such as BPEL or orchestration. However, when you buy, say, a vendor's SOA option whole-hog, you typically wind up paying for a ton of things you'll never use. (How many JMS vendors does one company need?) Vendors want you to adapt your environment to their tool and architecture, rather than the other way around.

Luckily, open source is giving enterprise customers alternative approaches to integration. For instance, one of the recurring architectural themes for customers is that, when it comes to integration, there are no recurring architectural themes. With open-source tools such as Mule (mule.codehaus.org), however, some architects use a typical ESB topology. Others use an ESB without the bus, and literally wire together enterprise services using web services or HTTP or messaging. Smart design is more about understanding your integration requirements and then applying the right technologies, rather than adopting a single vendor's technology stack, precluding you from having any options moving forward.

Open-source offers transparency. Not only can you see the code and identify the problem, but you can also fix it directly. Often bugs are a one-line fix, so it's aggravating not to be able to see the source code and change your own system to work around a basic problem.

In short, open-source integration platforms leave your options open, reuse your existing technology investment, and put you in the best position to be able to pick and choose complementary approaches.

RELATED ARTICLES ComponentOne Releases Studio Enterprise 2008 v3 Debugging API Spec for Power Architecture Released Amazon SimpleDB: Unlimited Public Beta Announced CodeGear RAD Studio 2009 Released Mathematica 7: A Review		TOP 5 ARTICLES No Top Articles.