Successful Integration

Ten Top Tips for Successful Integration

Once the preserve of large organisations needing to merge their systems as a result of Merger and Acquisition (M&A) activity, Enterprise Application Integration (EAI) is now becoming more commonplace. Due to their flexibility and relative inexpense, digital and web technologies are firmly established as the medium of choice for rapid development of front end applications. However, businesses are still keen to maximise their investment in legacy systems and harness the data and intelligence that resides within these systems.

Unfortunately, projects with EAI requirements involve many interactions between applications and the nature of this complexity increases the likelihood of project failure. There are a number of integration toolsets available to help organisations overcome the intricate nature of these projects, yet these are themselves technically difficult to implement across a range of operating, applications and technology environments. Despite these technical complexities, the main points of failure for projects involving integration are driven by business, organisation and design issues.

Based on his experience at Amaze of delivering successful digital solutions that integrate into back-end systems, Damien Mannion has put together ten tips of how to ensure your integration projects deliver against business objectives.

Introducing complex EAI technology without a specific business problem to solve will result in a white elephant implementation. The most successful implementations form part of a large programme of work with a well defined business benefits case.

If senior management are not supportive of the integration solution, the work will be under funded, under resourced and therefore unable to cope with the complexity and scale of the task ahead. Senior management must place significant importance on integration work and free up their brightest and best people to work in this area.

The goal of integration is to enable business processes to be realised across different application and technology boundaries.  If the business processes are not fully understood, the technical implementation of these processes will inevitably be incorrect. To avoid this pitfall, ensure that your integration team are actively involved in business process design at an early stage and have thorough understanding of the benefits case.

When defining architecture, there is a tendency to assume that applications and technologies will behave as documented, which often proves incorrect because of differences between the target and vendor’s documented environments. This assumptions-based approach is risky because the cost of making change after the design and build stage is orders of magnitude higher than at the earlier architecture stage.

To maximise the chances of achieving your business objectives adopt an evidence-based design approach throughout the implementation and do things for a reason not a whim.

Some organisations believe that procurement and installation of an EAI toolset will in itself resolve their integration problems. This is a major mistake and significant effort must be expended in producing a strategic integration framework based on the chosen EAI toolset. The framework must define EAI architecture, scalability, resilience, application interaction design templates, error management, message tracing, message versioning, deployment between environments and operational management. Without this framework in place, every interface will have to resolve these issues independently resulting in a number of incompatible solutions for the same problem, considerable waste of effort and high operational costs.

If you do not have specialist Enterprise Architects available in house, contract the required personnel before the project commences. It has become the norm to outsource project roles either by engaging a project partner or setting up an off-shore delivery capability. Outsourced resource providers compete by pricing based on the minimum skill set to fulfil the stated requirement. Classic under estimating of the scale of work required to successfully deliver an integration service results in project resources incapable of recognising the non-functional requirements and inadequately skilled to resolve consequential issues.

It is vital that your integration team’s scope includes end-to-end delivery of messages. This should include: generation of message, transportation of message, delivery of message and management of an undelivered message.

Integration design teams who have their scope limited to message transportation cannot perceive the big picture of implementing business processes across applications. This often results in problems at the application sending and receiving interface boundaries which are time consuming and expensive to resolve without a single owner.

Integration component delivery patterns must be sufficiently agile to continually deliver improvements to business processes for many years after the initial implementation. Business processes change because organisations must adapt in order to remain competitive; therefore software delivery patterns must not limit an organisations ability to implement change.

The process to promote integration components between development, test and live environments must be major design consideration from conception to delivery. An integration solution that is inflexible and difficult to change will not be able to cope with a continually evolving world and will only be able to deliver outdated, uncompetitive business processes.

Using an iterative software delivery pattern also mitigates the size and complexity risks associated with a ‘Big Bang’ approach. Bundling the integration solution with applications makes a project unnecessarily large. The integration framework should be implemented and tested before the applications are delivered.

Performance considerations should be an integral part of the architecture, design, build and test phases of your project. Performance testing that starts after build and test phase is too late to influence major changes to architecture that will improve performance. If the system underperforms it will not gain user acceptance and the business benefits will not be achieved.

Don’t become complacent once the project is deployed. To ensure maximum availability and performance and to allow for continuous improvement, monitoring tools must be in place to detect and analyse failures, resolve lost message reports and measure throughput. The integration team must be pro-active in resolving failures and have an error handling process in place before implementation. An inability to detect and resolve integration problems will quickly result in a loss of confidence in the implementation and will inevitably be considered a failure.