The Weakest Link

The eight most common reasons integration projects fail

Ninety percent of organizations still lack a postmodern application integration strategy and will continue to do so through 2018, according to a Gartner press release earlier this year. This lack of integration strategy and related skills is resulting in “integration disorder, greater complexity and cost” according to the same Gartner press release.

So, maybe the previous blog, titled “Application Integration is no longer a problem”, was somewhat overly optimistic or premature. We received a number of responses on that blog from people explaining the failures and struggles they have experienced with application integration. Understandably these responses were sent off-the-record.

Many of the problems mentioned fell in the category ‘general IT project risks’, such as scope creep, poor planning, conflicting departmental requirements, resistance to change, poor data quality, technology focus instead of business focus, and so on.

However, a number of the problems were specific to application integration projects. The eight most commonly mentioned reasons are listed below:

  1. Increased complexity was not recognized
    Implementing applications from multiple vendors introduces additional integration complexity compared with a single vendor strategy. The expected business benefits from selecting ‘best-of-breed applications’ need to be weighed against the additional integration effort. If the decision for a hybrid system approach goes ahead, the integration effort needs to be properly planned and budgeted for. Although this may seem obvious, it is often underestimated by the users involved in the initial purchase decision.
  2. False assumption that the Enterprise Application Software (EAS) vendor will handle integration
    Many organizations mistakenly assume that their EAS vendor (vendor of ERP and other Line of Business systems) will take care of application integration. While most EAS vendors offer APIs to get data in and out of their own solution, these APIs do not know what is at the other side. The customer is responsible for integrating these other applications.
  3. APIs offered by the vendor are too basic
    The APIs provided by the EAS vendor may work well for data access, but not for Business Process Integration (BPI) workflow scenarios. A proper BPI solution is needed when the integration requirements go beyond simple data access, especially where the actions that need to be triggered from one system to another are conditional or complex.
  4. No cross-platform integration tool or expertise
    Integration by nature requires tools and expertise on multiple platforms. Not only to create, test and implement a solution, but also for ongoing support, problem solving and possible future customization. Make sure to select an integration tool that can be deployed across multiple platforms, including Cloud platforms. Also, staff with a variety of technical backgrounds needs to be comfortable using the tool.
  5. Real-time – Near real-time – Batch
    No proper consideration has been given to which inter-system transactions should be processed in real-time, near real-time or batch. First of all, make sure you select an integration solution that can handle all three scenarios and that it performs well in all three with peak volumes of data. Secondly, classify your integration needs in real-time, near real-time and batch. Where real-time is not required, specify the frequency of an integration process. For example, should it run every minute, every half hour or every day.
  6. Processes are not fully automated
    Processes that are “almost automated”, but still have a small manual step somewhere, form an increased risk for errors and bottlenecks. For example, manually moving a file from one location to another or converting a column/field to different coding or standards. Again, a good BPI solution should be able to handle data transportation and transformation, as well choreographing the related processes in all relevant systems.
  7. A patchwork of Integration solutions
    The integration challenges that come with a mixed vendor and hybrid Cloud environment, are in many ways similar to the challenges that come with integrating with business partners. To keep costs and required skills under control, select a business process integration solution that can handle a variety of integration scenarios, such as EDI, XML, CSV, web service, Pop3, FTP, and so on.
  8. No proper error handling processes
    Inevitably at some point something will go wrong. The data may not match the schema defined for the transaction/message, a connection error may occur, an encryption/decryption key may fail, and so on. Error handling will be needed, such as sending an alert to an operator, triggering an error correction procedure, setting a restart point, logging the event in an error report, and more. A proper BPI solution will include an operational dashboard and handle these administrative tasks.

Application and Business Process Integration solutions have become easier to use and more affordable than the traditional heavy weight Enterprise Integration Bus (ESB) solutions. However, organizations still need to plan and get skilled for the additional challenges that come the postmodern application mix and match environment.

A cross-platform no-code application and business process integration solution will make responding to the dynamic EAS and IT landscape simpler and increase the chances of success.

Whitepaper: Choosing the right Business Process Integration solution
Business Process Integration customer project examples
Where heavy customization or in-house development is required, a cross-platform low-code development environment will help to bring down silos as well.



Marjanna is responsible for LANSA’s marketing activities in Asia Pacific, editing the LANSA Review magazine and writing customer case studies. Her career started as a COBOL and RPG programmer in the Netherlands, followed by 10 years as a developer, analyst and founding partner at PT Sistima, a small software house in Indonesia, which offered its own localized ERP solution and general IT services. After moving to Sydney, Australia, Marjanna joined Aspect Computing and later LANSA, where initially her responsibilities included consulting on data warehousing projects and developing LANSA training materials.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.