It may be easier to stay with one of the software suppliers you currently favour for a framework designed to integrate and coordinate applications.
This however is not a good idea and will only lead to serious problems later on although there is no fool proof solution because the integration framework supplier you choose could fail in the future as easily as the application suppliers. Thus while there are quite a few excellent products available from OSS and other sources which are acceptable for smaller user organisations, the choice for the corporate world is more limited. Application and database vendors create too serious a lock-in; the same applies to Microsoft. This leaves IBM (in a unique position because of their size) and BEA as the independents, although there are other specialists in specific industry sectors.
With the exception of Microsoft all these suppliers are now following the standards route, with a strong emphasis on Java and XML. However the currently dominant EAI tools, WebSphere for example, are targeted at building Web front-ends to existing applications, J2EE supporting interfaces to TP systems as well as databases. It is an excellent idea and these products have dominated application development in recent years. However they are strongly biased towards traditional transaction and on-line query applications. Frankly this is not enough! In tomorrow’s world business applications will need to integrate document and office systems with data processing, in which cooperative processing world work flow, batch processing and messaging are key requirements as well as interactive applications.
This then leads to a dilemma. There is no doubt that IBM, BEA et al will expand the capabilities of their current products but they are not properly designed from the beginning. As well as exploitation of standards, a truly independent integration framework should be designed from the outset on an asynchronous, message-passing architecture. Product vendors will dismiss this as technical background which doesn’t matter. But it does! Time and again the IT users accept what ever is being advertised as the best without looking into the consequences. The thick-client architecture was badly flawed from the outset and even while SAP were showing the world the success of a thin client architecture, many organisations listened to inexperienced enthusiasts and did it wrong. Today all those thick client applications are the biggest legacy problem the IT industry has yet experienced. This time perhaps some attention will be paid to the importance of getting the architecture right from the beginning.
To be fair to SAP, while I don’t recommend using their product because of the tie-in, it is well architected. However the most interesting product by far is a Dutch one, Cordys. Unlike most start-ups Cordys is well financed and as a result has been able to do an enormous amount of development before bringing the product to market. Cordys is independent of any application vendor; it is an independent framework, the basis for a fully integrated Business Network. Most important for the future it is soundly architected and not derived from some other product. The Cordys backbone supports connectors, using XML standards, to integrate with applications. APIs to common applications are available, but there is a comprehensive toolkit for building such connectors for other applications. Workflow management is integral but so is the more immediate requirement for portals to access the variety of corporate data sources. The Cordys front-ends do not rely on a Web browser and being message based are very efficient, avoiding the common problems of network performance, particularly over wide area networks.
Cordys should become a major product so check it out.< BR>
Martin Healey, pioneer development Intel-based computers en c/s-architecture. Director of a number of IT specialist companies and an Emeritus Professor of the University of Wales.
