At Wheeve, we believe successful a integration capability is built on a strong vision and strategy for achieving it.

In this article we want to give you a flavour of what an integration strategy should look like.

Let’s at least get some of the terminology straight as the terms is used very loosely in the wider community. I’m not saying that my definition is better than anyone else’s, or that anyone else is wrong; I just want to be clear with my audience what Wheeve mean by these terms.

There are really two components to a strategy: (1) a Vision and (2) a Strategy to achieve it:

Vision. A description of a desired state. In the case of the integration vision, that means the desired configuration of people, processes and technology that support effective systems integration for the organisation.

Strategy. The significant steps the organisation will take to to achieve the vision, bringing into being that desired configuration of people, processes and technology.

So far so good, if a little abstract. It follows that the vision comes first, and then the strategy is written. It’s a bit like what architects do with target states and roadmaps, only at a much higher level.

While there are glancing similarities, a strategy is most definitely not a roadmap or a (project or programme) plan. These come later, work at a more granular level of detail, and are designed for a different audience. Remember that the audience for us is strategic budget holders and decision makers – not implementors.

The Vision answers Why, What, How, Who and Where? It defines the desirable end-state that your enterprise wishes to achieve. It does not concern itself with how to get there.

It is important to understand that the audience of this material is primarily *not* those that understand middleware, API gateways, microservices, messaging and so on; it is actually senior stakeholders that will be asked to put their hands in their pockets to invest in the vision. These are the people that must be convinced that this integration technononsense the right thing to invest in.

Historically, this is a particular problem with integration platform implementation programmes, as senior management either have no idea that such a capability is even needed, let alone what it is. Worse still, if they have heard of it, it’s most likely been in the context of something going wrong and costing them money (as old adage goes; you only hear about it when it’s broken).

Fortunately, times are changing, albeit slowly. Most senior stakeholders will at least have heard of APIs, and many will believe they need them, even if they don’t really know what they are or how to build them.

So, the first task of the vision is to educate: to explain what integration is and why it’s important. All your stakeholders will understand that the value of data (No? Really? Where have they been?) The task here is to explain that to get the most value, it must be accessible and easy to move around in a secure and controlled way. Furthermore, it must be made clear that as the organisation evolves to use more and more cloud services, core data often no longer sit in central, clearly-bounded, IT-managed systems. Managing access to that data and connecting systems together across these environments is not optional; it is essential.

We find that some well-chosen examples from the following categories of concern will bring the message home loud and clear:

• Business needs and objectives (call them journeys if you must) that require access to data and/or functionality hosted in multiple business systems to operate.
• Business challenges that arise because underlying data is not integrated effectively.
• Business opportunities that cannot be realised because integrating the data is either too costly or time-consuming.

You’ve explained the problems you can solve, needs you can meet and opportunities you can enable with this integration thing, but most budget holders also need confidence that this course of action is the de facto right one.

Therefore the initial section should always include a few examples of well known successful organisations (if possible, in your market sector) that are benefiting from a strong integration competency. It also pays to include analyst data showing the general trend in the integration market place (up, up, up!).

In the context of this discussion, we’re talking about the technology here. As we at Wheeve say – people and processes are equally important, but we’ll come to those in a moment.

The technology set that you will choose to implement your integration capability is, of course, extremely important. It must meet the requirements of an increasingly diverse set of stakeholders (see below), and will inevitably need to bridge both on-premise and cloud business systems. The requirements expressed earlier on will inform the technology choices you will make, and it is likely that you will be mixing and matching from more than one vendor – such is the fragmented nature of the market at present.

Great integration solutions don’t just happen. It takes much more than technology to deliver set of APIs that unlock business value. The processes for governance, management of demand, development and support are critical to delivering high quality integration outcomes. The vision must paint a picture of an operating model that works for the future way the organisation will operate – agile, proactive and responsive to change.

The processes for delivery must be underpinned by strong processes for governance – to make sure teams deliver what was asked for rather than being distracted.

This aspect of the integration vision doesn’t have to be very detailed; but it must highlight any significant and fundamental changes to processes that are anticipated, such as a move to Agile, DevOps in the development teams.

It is quite possible that the most fundamental changes you envisage in your integration future are not technological at all; it may well be people and teams that require the most radical change.

• There will likely be new skills requirements, and you may need individuals with different experience to your current in-house team.
• The team may be centralised or distributed, or a mixture of the two.
• You may consider outsourcing part or all of the integration function. This may be to a niche provider (an excellent idea, hint, hint); you may choose to take advantage of an offshore or near-shore model to manage costs.
• Your team may include not just deep integration professionals; there may also be tools for ad-hoc integrators and/or citizen integrators to enable simpler integrations to be taken away from a centralised team.

These decisions are complex and require careful thought; they require you to consider not only your ideal end-state but also to be realistic about the level of change that is appropriate both within your IT organisation and in the wider IT-literate community.

Where the Vision painted a picture of the destination, the strategy traces the route you will take to get there. As with the vision, we must explore the strategy from many perspectives, including but not limited to:

• Technology. How will the landscape evolve into the target technology landscape? What existing assets will be retained? What investments must be honoured? How will transitions be managed? Big-bang or phased transition states? How will any cloud components be adopted? etc.
• People. How will individuals be retrained and reskilled? What training will be required? How will staff changes be handled? How will new teams be brought into being? What contracts with outsource providers will be needed? How will any temporary team requirements be met?
• Processes. How will new processes be implemented? How will changes in processes that impact wider teams be co-ordinated? How will changes to governance be implemented and supported so that they are effective?
• Communications. How will changes be communicated to the wider organisation? How will you ensure buy-in to the change not just at the start but for the duration of the initiative?
• Timescales. What will be done when? What dependencies will determine the order of implementation, if any?
• Principles. What principles will drive and shape the strategy? These should be directly related to existing business and IT principles and values if at all possible.
• Finance. How much will the change cost? How much will the future operating model cost to run? How will the change be funded? What changes to internal financing will be needed? What are the financial benefits of the change?
• Location. How will any changes ot the location and scope of teams be implemented?

I won’t go into each of these now, as each will be as individual as your organisation. What’s critical is that your audience understand not only what you intend to achieve, but can see a realistic and realisable path to get there. Without this, you will just be another dreamer that gets despatched from the boardroom with a “no”, or at very best a “more work needed.”

This short introduction to strategic planning for integration illustrates the complexities involved in getting an effective integration vision and strategy in place. It provides a high-level framework for you to develop a strategic plan unique to your organisation; one that will capitalise on your existing strengths in this area and recognise areas for change.

One thing is for sure; there is no one-size-fits-all approach and you will need to devote a significant amount of time and effort to getting this right in the context of your organisation. If that seems somewhat daunting, then why note let Wheeve help? We offer a cost-effective consulting package to work with you to document your Vision and Strategy for you; saving you time and ensuring you get an end-product that will be understood, supported and, ultimately, funded by senior stakeholders in your organisation. Why not discuss your requirements with us? [email protected] or 01923 590095.