The costs of integrating and not integrating
Yesterday in this series we looked at why we need to integrate - in this
second article we'll look in some more detail at the costs of integrating, and of not integrating if we should choose to do so.
For many years now the subject of integration has been considered on a project-by-project basis, as new applications are developed their integration needs are identified, designed, developed, built and tested. Depending on the nature of the new application, it may have relatively simple integration needs that can be satisfied by a few programs in the overnight processing schedule. If it were that simple the handcrafted project by project approach would be acceptable.
The problem is that these days few organisations run in batch mode, for most it's real time or as close as possible to real time business operations. This is, of course assuming that the integration needs are identified in the design and analysis phase. More often than not, such requirements are missed and often not recognised until the testing phase where someone notices that some data is missing - investigation shows that it is not just missing, it was never there in the first place.
This is where the compromises start. Given the choice between significant investment in development time and infrastructure costs many organisations will forego the need for real time operation and instead settle for periodic refreshes or event based transfers. So the potential functionality, and more importantly business advantage, offered by real time applications is immediately dispensed with for the sake of not being able to integrate in the manner needed.
In this scenario, the organisation will follow the DIY route. This approach has its routes as long as twenty years ago when the need for systems to be integrated first arose. Business operated in batch mode, because the technology did not exist to support anything else. And yet today the technology does exist, in terms of networks and infrastructure, integration tools and development environments. Added to that, and most importantly, the business need exists.
So if you choose to go down the DIY path you will have to invest development time, the same is just as true for bespoke as ISV sourced applications, and then decide just how much of a loading you can afford to put on the infrastructure. You'll design the application interfaces, test them and make them live together with the rest of the system. Anyone that has been remotely involved in application development knows that the real work has only just started when an application goes into production.
Once you've sobered up from the go live party there are the stack of change requests that have appeared. Either things slipped out of scope of the original application or business users are already demanding additional functionality.
Whatever happens you've now in the maintenance cycle and the applications, and their crucial interfaces, slowly but surely move from the original design into what the business actually wanted. This normally happens in a relatively unplanned manner - a change management process may or may not exist, if it does it may or may not be adhered to, and if it is adhered to changes may or may not be documented.
Don't forget we're taking about integration between applications here. Its not just one goal post that moves - its all of them, all in different directions and at different times. So, aside from the normal maintenance overhead there is the additional maintenance overhead introduced by everything changing at the same time. And this still does not take into account the fact that mistakes are made. No matter what anyone tries to convince you otherwise there is no such thing as error free code.
You might think that buying ISV sourced solutions reduces the cost. It may reduce the initial development cost but there is still the on going maintenance overhead to be considered.
Then there are those organisations that did put some thought into their integration strategy and they went out and bought an integration solution, and then another, and then another. Whilst integration solutions offer enormous benefits to the organisation, they are not a collectable item - there is no need to try and go for the whole set - one is normally sufficient. But some organisations don't listen, or maybe they have been through a series mergers and acquisitions and have yet to put together a consolidated IT strategy. Either way, they're making things far more complex than they need be.
Copyright 2003 IT-Director.com provides IT decision makers with free daily e-mails containing news analysis, member-only discussion forums, free research, technology spotlights and free on-line consultancy. To register for a free email subscription, click here.
For More Information:
- Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
- Are you tired of technospeak? The Web Services Advisor column uses plain talk and avoids the hype.
- For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
- Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.
- Visit our huge Best Web Links for Web Services collection for the freshest editor-selected resources.
- Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
- Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary for the latest industry lingo.
- Couldn't attend one of our Webcasts? Don't miss out. Visit our archive to watch at your own convenience.
- Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.