Integrating Islands with Landmasses

EAI notes and thoughts

Saturday, December 31, 2005

Now an Integration Appliance!

I was reading literature on 's appliance for SMBs (Small and Medium Scale Businesses) and also attended a that touched upon the product. It offers out of the box integration through:
  • Integration software hosted at the Bridgewerx site
  • Appliance acting as the hardware
The first step is to design the integration at the Bridgewerx site. The integration software is a based web application and is available for a test run at the . The output of the design task is a file that has to be configured and deployed on the appliance.

After designing the integration at the Bridgewerx site, the (source and target) have to be configured and the integration can then be deployed on the appliance. For each environment e.g. Test, Production, a separate appliance would be required.

The Bridgewerx appliance is a Dell Wintel server running Windows 2003 Server, and SQL Server 2000. The complete specs are available at the site. The choice of a Microsoft based solution instead of an Open Source approach has been a little intriguing to me. But then, this could be due to the fact that most of my experience is with IBM and Java based .

In the webinar, a solution using the Bridgewerx appliance was explained. The scenario was integration of with an internal billing application of Bridgewerx's client.

is another appliances vendor which has a similar product - XI50. I could not get much details on its specifications, so will not be able to compare it with Bridgewerx's product.

Bridgewerx is clearly aiming at the cost-conscious SMB market with an extremely competitive pricing strategy. With IBM acquiring DataPower, it would be interesting to see how the competition in this market unfolds.

del.icio.us  digg  technorati 

Sunday, December 18, 2005

Are ICCs really successful?

Amidst widespread hype about the success of Integration Competency Centers (ICC), I have been hearing rumours of the proving to be costly in at least two of the clients with whom I was/am associated with. Aside from cost (inspite of offshoring), the other reason that is spoken against the ICC is inflexibility in terms of accepting and executing requirements. This reason in most cases is true and could be explained as follows:

Choice of Integration Tool
These days the EAI tools predominantly focus on realtime transactions and process integration. Many organizations think that they are ready for realtime process integration while a deeper insight into their functioning show that they are not. This is because most of their business processes are designed to be batch oriented and changing them would have a huge impact with adverse effects. Most of the EAI requirements center around data integration levels and only require the tool to move data across systems. Thus the EAI tool in most cases, is not fully effective.

ERP Solution Centers and Process Integration
The next problem is that when an EAI tool, whose general definition is to do data integration tries to get into ERP space for process integration, it is definitely frowned upon. The ERP solution centers that manage business processes as a core functionality see this as an invasion into their space and friction is bound to develop.

Scarcity of Skilled EAI Resources
The problem with getting EAI skilled analysts and developers is bigger than ever before with more and more companies waking up to EAI. A fallout of this is that resources act high-handedly, dictating terms to prospective employers and demanding exorbitant salaries. And surprisingly, most of them are folks with just an year or so on a single EAI tool. More often than not, they fair poorly on the job as they are more of "button pushers" or "machine operators" with hardly any knowledge of EAI concepts and paradigms.

So, where does that leave us?
It may so happen that there are no concentrated competency centers doing integration anymore. Folks on a project could just double up as EAI developers as per the project requirement. This would serve to alleviate the resourcing problem and a more informed decision on the integration tool could be made as the project resources would be the ones closest to the functional requirements.

del.icio.us  digg  technorati 

Thursday, December 08, 2005

IASA President visits this blog!

I was delighted to find IASA president Paul Preiss's comments on this post. It is encouraging when people read a blog and leave comments, the joy is doubled when they happen to be dignitaries.

del.icio.us  digg  technorati 

Monday, December 05, 2005

Efficient XML Interchange - EXI

In almost all of the EAI projects that I've worked with, I have noticed one problem related to performance - the growth of message size when wrapped in XML. This is of concern especially when the data being transferred has no semantic meaning, binary data, database records being synchronized and similar examples come to mind. People have resorted to actions such as removing the XML wrapping, using EDI internally(!), switching to FTP for data transfer and even upgrading hardware servers (due to stubborn EAI evangelists with substantial clout) to overcome this. The affected parties can now take heart from the fact that the W3C has setup a working group called EXI to develop a format that improves the performance while transferring data in XML. (news through David Linthicum's Real World SOA blog). Of specific interest to me is the following point in the charter,

"Fulfill the design goals of XML with the following exceptions:
  1. The interchange format must be compatible with the XML Information Set instead of being “compatible with SGML” (XML goal 3);
  2. For performance reasons, the format is not required to be “human–legible and reasonably clear” (XML goal 6); ..."
Point 1 related to XML goal 3 will hopefully shed off some baggage that the present XML Info set is being burdened with. Point 2 should be the differentiator for this format and deal the killer blow. Not sure how this point will be taken care though, with entities probably?

del.icio.us  digg  technorati