Computerworld reported in July about a new industry group, the Integration Consortium, that aims to make systems integration projects less expensive and more successful for its members. It is a very ambitious aim, and some of their goals are of a "boil the ocean" magnitude. While we're waiting for the ocean to heat up, a better understanding of integration from a business standpoint should actually help improve an organization's integration project outcomes in the near term.
It is a good bet that systems integration, in one form or another, will continue to drive a good chunk of IT value in many enterprises. Integration is what allows more parts of the enterprise (and the extended enterprise of suppliers and customers) work together with less and less human intervention.
At the very basic end of integration is simply getting system A to send data to system B (e.g. sending filled orders to the AR system for invoicing). More advanced integration has systems A & B sending data back and forth (an inventory and order management system communicating, for example). Progressively more advanced integration projects tie together multiple disparate systems and may start to incorporate aspects of Business Process Management (BPM) such that workflows and business rules are applied to the data moving from system to system (for example, managing the return process from the customer service rep issuing an RMA to the warehouse receiving the return and all the way to accounting for credit).
According to the Computerworld piece, The Standish Group estimates 95% of all integration projects fail, that is, overrun their schedules or budgets and/or underdeliver on their goals. Now, this is one of those stats that begs a number of questions, however, even the base number indicates something is wrong with these projects. The Computerworld piece also says industry studies peg integraton costs at 35% of total IT project costs for the average company. No matter how you slice it, this is a big impact issue.
Since I think the Integration Consortium's dreams are a long way from being realized but recognize that integration should continue to be a business technology objective, here are some things the business should think about when it comes to integration in the enterprise:
Older systems are harder to integrate - Think about the overall benefit of replacing that old mainframe-based warehouse system. Sure, it might work adequately in the warehouse, but is the odd-duck architecture inflating integration costs and externalizing those costs into other projects, making the perceived cost of newer systems higher than it actually is, while artificially lowering the perceived cost of the legacy platform?
-
Application Suites (such as those from Oracle, SAP and Peoplesoft) can eliminate a lot of integration hurdles for companies, if they are willing to make the trade-off of taking a suite approach versus selecting best-of-breed applications.
-
Integrating package software from multiple vendors is harder than you'd think, even when the products run on common platforms (i.e. operating systems and databases). There are three main reasons. One is that every software package has its own underlying view of the world, data-wise; the second is that each package has a specific "standard" way for data to flow into or out of the application (assuming it was even designed to be integration-friendly, which many are not). The third issue is that there is a chasm between the two systems; data will not always flow perfectly and something needs to sit in the middle to deal with the inevitable hiccups that will occur. Accomodating these exceptional cases and error conditions can consume a significant amount of time.
-
Integrating custom applications, either to vendor packages or other custom applications, is usually relatively easier than working with multiple vendor packages, assuming you have or retain good developers. The freedom to modify and adapt the custom application makes it easier to accomdate the package application.
-
Two-way (round-trip) integration can often be more than twice as difficult as one-way integration. Integrating transactional system with a data warehouse is usually pretty straightforward, it's basically a data feed. Integrating a warehouse system and an order management system involves dealing with special cases like partial fulfillment, backordering, and other complexities.
-
Typical project scope management techniques rarely apply in integration projects. Unlike building a new application where some sacrifices can be made for the sake of the schedule or budget, integration projects typically are all-or-nothing. You really can't just do 60% of the integration between your inventory and order management systems, having the order system place a hold on inventory when taking an order but not releasing the hold if the order is cancelled, for example.
-
Use realistic estimates when determining the business case for integration. If 95% of integration projects are over-spending and under-delivering, it cannot all be put onto the development team's back. The good news is that integration projects have a very defined scope, and it can be estimated if the people doing the estimation are experienced in doing integration work.
-
Integration projects are usually a good place to look for outside expertise, especially if integrating to a packaged application. You should be able to find a good consulting firm that has done integration work with the package, giving them an advantage in estimating the work. But don't make the mistake of getting an estimate of time and labor from a consultancy and expecting the internal staff to do it in the same amount of time (at the lower internal rate). The consultancy will have the same advantage in performing the work more quickly as they do in estimating the work accurately: experience.
Comments