In Operational Support Systems and IT management field, implementation of integration adapters, - solutions to integrate management systems, data sources, etc.- is a common requirement as most organizations use variety of products from different vendors for different purposes. Integration tasks continue to carry high risk (and perceived as such) in the implementation of management (network/systems/application, etc.) tool/solution implementation projects. Project failures and overruns are still all too common. What is the problem? There are many hurdles. Here are the top 8 reasons for systems integration project failures (that I've encountered):
-
Non standard APIs and lack of support of open standards
Most of the management tools are behind the curve in supporting industry standards and providing open/available APIs regardless of the vendor claims. Current technologies such as web services are either not available or support a small subset of the functionalities, etc. hence still not a viable option in most cases.
-
Inherent unwillingness of vendors to cooperate with each other (despite what they may say).
Although almost all customers use solutions from multiple vendors, due to the competition among vendors, there are inherent difficulties for vendors to maintain a good integration. Lack of open APIs (as stated above) do make the cooperation necessary; yet unless it's a prerequisite for a major sale, vendors have little interest to cooperate with each other. So if you want to make sure the integration works, and will continue to work, make it a condition for your acceptance criteria (you have those don't you :)
-
Unclear definition of what “integration” means, hence different expectations by different stakeholders.
The term integration is used very loosely in the industry, hence it is quite easy for a vendor to claim they have integration with another product. For example, vendors often claim that they have an “integration adapter/probe/connector” for product X, just relying on their ability to receive traps or having an API. We have seen these type of solutions that did not even have the traps configured or tested, hence causing significant amount of “unforeseen” integration work, significantly increasing the implementation costs.
-
Difficulty in defining the specifications of the solution in advance (functional specifications) due to lack of understanding of all components.
Integration work often requires good understanding of the environment; all the tools and the data sources involved. The necessary information is often not available when projects are defined, forcing “guesstimates”. Amount of work required to come up with the functional specifications is often more than what can be handled in negotiation/pre-sales phase since it may require significant amount of work. Without proper functional specifications, there is always the risk of different understanding/expectations between the parties involved.
-
Ad-hoc, custom development rather than re-usable components.
Most integration projects are custom development projects. The integration components provided by the vendors can be considered reusable components and do help but in most cases majority of the functionality is still implemented as custom code. It's not an uncommon for us to find ourselves scratching our heads looking at some smart (not being sarcastic:) piece of perl code written by a previous consultant. The more custom code there is, the higher the risk of failure.
-
Lack of resources who are both trained/experience developers and have understanding of the problem domain (IT management tools/processes)
You can find people with development skills, you can find people who knows the management domain, but it's quite difficult to find people with both skill sets. As the sophistication of the integration solution increases, the quality of the solution suffers if the people implement the solution lack solid development skills (we often do:). It is one thing to develop scripts to glue things together quickly, another to develop a sophisticated, maintainable solution.
-
Not so truthful marketing messages that implies a wonderful world of management solutions where everything is so easy to implement and integrate (out-of-the-box anyone?)
The gap between the marketing speak and the reality in the field is significant to say the least. This causes problems for the industry as well as for the customers. The customers either buy into the message, hence not prepared to meet the challenges of integration, or completely cynical (often rightly so) since they've been burned too many times in the past. The distrust makes it difficult to have a productive relationship even when both parties have good intentions.
-
Difficulty in maintaining the integration in time as different components of the management solution changes, along with the interfaces.
The management tools/solutions need to align with and facilitate the processes they support (not other way around). The processes are often in flux and change depending on the requirements of the business. The management tools and hence the integration solutions need to be agile enough to adapt to these changes. It is not uncommon for the integration adapter to be the obstacle in front of implementation of a new business requirement due to difficulties in adapting the integration solution to the new business requirements.
You have others? If so, help me make this the top 10 list :)
