By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Charles Lowe, Independent Consultant
New software is rapidly making the technical aspects of integration easier to solve. Getting different systems to interwork and to use distributed databases was once an insuperable obstacle; it is now increasingly manageable as just one aspect of a technical implementation programme. Major integration problems do persist, however, because solving the mechanical integration issues often exposes the much more intractable people issues. At the heart of virtually every systems project is a change management project. This is especially true of an integration project, which typically eliminates manual interworking activities, as well as introducing an element of control over those responsible for each of the elements being integrated.
Within a single organisation, such change can usually be achieved by applying change management principles, such as involving all those likely to be affected by the decision in the decision-making process. You must also listen to your staff and make sure that people know their future employment options. The key aspect is that management must have a clear, agreed vision of what they are trying to achieve, and must be totally honest with those involved. Without full training, a dissembling change manager will be found out quickly and will lose all credibility when that happens.
Within a single organisation, ultimately everyone should be responsive to the board. So, while it is rarely used, the existence of the possibility of escalation is a powerful tool for project managers when seeking to encourage co-operation. Where an integration project crosses organisations - for example in the public sector - the problem is far harder because often there is no point at which responsibility for all participants in the project converges.
Middleware is a term that is used almost too loosely but is is perhaps best viewed as a scale. At one end you have tightly coupled systems, operating in more homogeneous environments, offering high performance and synchronous transaction capability - component-oriented architectures such as DCOM or Corba. At the other end lies the loosely coupled, business-to-business style environments that can tolerate long running transactions, which are totally technology agnostic and would not be used in high-performance applications - RossettaNet, BizTalk and ebXML, for example. Somewhere in the middle lies a whole host of traditional enterprise application integration (EAI) solutions such as MQSeries.
.Net has come from the tightly coupled DCOM world and made a leap into the more loosely coupled environment through the introduction of Web services and protocols such as Soap, which allow technology-independent service calls to be made using XML over Internet standards such as HTTP. In theory, you should be able to use it to integrate different systems. But in reality it does not provide all the value-add that you would expect from traditional EAI solutions. For instance, you will quickly find yourself building a network of spot integrations where an immediate response is always required.
Modern EAI provides a host of facilities such as store and forward messaging capability for slower systems, publish and subscribe models, workflow to orchestrate updates across multiple systems and data format translations. If a pure Microsoft solution is desired, this can be delivered by augmenting .Net with products such as BizTalk. However, this is not an out-of-the-box offering and is positioned at the lower performance end of the scale.
Clearly, technology is only one aspect of integration; business and departmental buy-in remains a key challenge. One approach might be to gain business buy in by putting in place a clear matrix for data ownership by system, developing an overall architecture roadmap outlining the business benefits and then holding a series of architecture open days for the stakeholders.
Mike Pomerance, IBM
The .Net set of technologies is a set of enablers for integration policies. Essentially, they are designed to help solve the problem of re-use. Integration is, of course, another manifestation of the same problem. It would be a mistake, however, to expect them to solve the core issues associated with integration.
Some of the issues you describe, like data protection, can be addressed or even solved by the application of technologies but others, like departmental rivalry, are far more recalcitrant. Standards are being set, usually by industry groups but occasionally by organisations trying to win market mindshare. If you are looking for standards being set in your industry, surf your industry and software developer centric sites which should provide you with information around emerging standards.
There are frameworks, policies, architectures and standards that are being used to address integration. Some of these have been implemented quite successfully in the financial services and high technology areas.
The message for strategists is still the same: technology can help you implement good decisions, but it can't make them for you.
Our panel of experts
- Imam Hoque of e-business consultancy Rubus
- Roger Till, e-business user group, eCentre UK
- Nick Maxwell, e-business consultancy Quidnunc
- David Grimshaw, Cranfield School of Management
- Neil Barrett, IT security consultancy IRM
- Peter Boggis, Concours Group
- Kevin Malone, IBM
- Charles Lowe, independent consultant
- Mike Pomerance, IBM global services, northern region
How it works
Each month E-Business Review prints a problem submitted by readers. Our panel of experts draws on their specialist knowledge to explain how best to solve it. Email your questions or your own personal solutions to this month's problem to: