Integration strategy is more than a poster on a wall

A lot of people get overly hung up on the word “strategy” when all it really means is that you have a documented plan for how you want to approach something and have identified the guiding principles under which you will attempt to operate. Your integration strategy should try to help align people engaged in systems integration projects across your business, encouraging them to approach challenges consistently and work towards a common set of objectives. It is the rallying call for action and the benchmark against which integration project outputs are evaluated. Or at least, it should be!

Strategy without tactics is pointless. Tactics without strategy is painful.

The integration strategy defines the intended direction of travel and should be supplemented with project specific assets such as detailed system integration plans and reference architectures.

Defining your integration strategy doesn’t have to be overly time-consuming, complicated or onerous. Integration strategies should be relatively high level and focus on setting expectations and defining business aspirations rather than being overly prescriptive or technical. Integration strategies are supposed to be a tool that helps integration project participants to understand what is expected of them, not a bureaucratic overhead that constrains innovation and introduces delays.

What goes into your system integration strategy?

Ambiguity and misinformation fill a communications vacuum. And yet many IT functions fail to clearly define what it is that they want from their integration projects let alone how they want those integrations to be designed, managed, or delivered. If integration failures are to be minimized it is imperative that the integration strategy is defined, documented and communicated to those at the front line doing the work.

The 10 tenets of a “good” IT system integration strategy

Most people struggle to describe what a good system integration strategy looks like. Too high level and glib and it becomes a thing of ridicule that is ignored by the masses. Too detailed and prescriptive and no-one can get their heads or arms around it, let alone attempt to implement it. The key thing to remember is that system integration strategies are supposed to be a device that management and practitioners can use to ensure they’re all facing in the same direction and focused on the same goals… It is about facilitating a meaningful dialogue between those paying for the activity and those performing it. It’s about establishing a common vocabulary and shared frame of reference so that everyone involved understands what is expected and why. It’s also important to explain your integration strategy in business terms that are easily understandable to non-technical executives.

Multishoring recommends that the following guiding principles should be evaluated and prioritized to help define a workable integration strategy that will focus your people on the things that truly matter and drive the right kinds of attitudes and behaviors:

• Scalability – Integrations should be designed in such a way as to scale in line with predicted transactional or volumetric growth projections without suffering from performance degradations or any changes in stability and reliability. Burst conditions should be modelled and the integration solution should be designed to handle such situations without outages.
• Security – The delivered integration should be free from all known vulnerabilities at the time of deployment. Control measures commensurate with the level of risk associated with the data being integrated should be implemented to safeguard data privacy and prevent security events that could lead to data breaches, loss, or contamination.
• Privacy – Sensitive information should be protected as far as is reasonably practicable and all integrations should be compliant with all relevant data protection regulations. Access controls to limit unauthorized and inappropriate data access should be implemented where necessary.
• Maintainability – Integration related documentation should be developed to a level that is sufficient to enable someone with the appropriate skillset to get up to speed with the deployment quickly and understand the integration architecture so that they are able to troubleshoot and/or modify the integration if required.
• Future-proofing – The use of open-standards and non-proprietary protocols for data transfer, storage, manipulation and, external event initiation should be prioritized wherever practical. Staging tables, intermediate repositories and data driven translation mappings should also be considered to help isolate the integration from upstream and downstream systems changes as far as possible. Integrations should be made as platform and tooling -agnostic as possible without impacting their ability to fulfil the other requirements of the integration strategy.
• Pre-existing infrastructure leverage – Where middleware, integration platform or, tooling investments have already been made, the adequacy of these historical methodologies and approaches should be evaluated before investigating the use of alternative toolset. The costs associated with the use of existing capabilities should also be considered as it may be price prohibitive to use existing capabilities for lesser priority workloads or tasks.
• Efficiency – Integrations should be designed to be as efficient as possible. Storage, compute and comms capacity requirements as well as resource consumption profiles should be considered within integration architecture reviews. Elegance and simplicity of design should be favored where achievable within the other constraints under which the integration is being developed. Performance issues often result from developers that fail to optimize their code and waste valuable system resources with wild abandon.
• Monitorable – Integration designs should include provision for the status, performance and behavior of the integration to be monitored externally. The necessary hooks, exception handling alerts, error log outputs etc necessary to be able to track and determine the health of the deployment should be included. Thresholds and event triggers that warrant investigation or remedial / contingent action should be defined and systems management tools configured appropriately.
• Periodic review – The integration’s design and its performance should be reviewed periodically to ensure that it is effective. Risks associated with changes to inbound data profiles or transactional volume should be assessed to ensure the integration remains viable and is likely to continue to operate within the defined performance parameters. As the threat landscape evolves it is important to continually reassess the security of an integration just as you would for any other deployed solution.
• Skills availability – Developing robust integrations requires personnel with the pre-requisite skills and experience. Such skills are often scarce and integration design decisions should be mindful of the availability of suitable resources and the ability to assure staffing continuity across releases and projects.

But what actually is the integration strategy and how should it be presented?

Different organizations use different communication mediums. The integration strategy could be documented in a poster on a wall, buried within a procedural manual, or printed on a mouse mat to help keep it top-of-mind. It could be the first slide used in every integration project status meeting. It might be a 30 second video module used to familiarize new starters during the project onboarding activity. It could be the basis of a pre-project initiation checklist and the post-project review. It could be many things. To be frank, it should be many things. To get ideas to stick they must be hammered home from a variety of angles over time. Consistency, repetition and persistence pays when it comes to winning over the hearts and minds of the technical rank and file.

“But we haven’t got time to define our integration strategy”

It’s often said that failing to plan is tantamount to planning to fail. The path to project failure is paved with good intentions and miscommunications. Good integrations don’t just happen by chance. They are a result of a definite set of approaches and activities all focused on mitigating risk and driving efficiency.

Given that integrations are critical to the business and that they typically persist for many years it is essential that they be treated with the same level of project governance and management attention as any other critical IT infrastructure investment. There is little point spending thousands or millions of dollars on front- and back- office business systems if the fabric that is used to connect them is not fit for purpose due to a lack of attention or investment.

The Multishoring approach…

Integration is what we do. Our team has witnessed the impact of poorly thought out or non-existent integration strategies many times. We understand and believe that a clearly defined integration strategy is a fundamental enabler of integration project success. A good strategy that has been effectively communicated to all involved parties ensures everyone understands where they stand, their role in mitigating risks, and helps people to avoid common pitfalls in order to ensure that your project is successful.

Whether we’re in a turn-around situation helping to get an off-the-rails project back on track, or working on a net new integration, we focus on the things that truly matter and make it work within the constraints you define. Some organizations consider a defined integration strategy to be an “optional extra” – This is invariably a mistake.

Depending on your appetite for risk, available budget, or timeline, we will work with you to define the optimal schedule of works so that you feel confident in the delivered solution and its ability to run as designed issue free for as long as you need it. We don’t over engineer projects to artificially inflate the scope of works and we don’t skimp on activities that will materially impact the integrity of the delivered integration.

Integrations may be complex, but they do not need to be complicated. We use our experience and expertise to take challenging integration scenarios and make them happen. We do what is needed to make your integrations stable, secure and scalable so that you can focus on other things.

Share article on: