So you’re changing your integration platform. Great! Change is often good, but can be hard to do. Breaking up with old systems – and habits – is often easier said than done, especially in highly complex environments.
New integration platform: The obvious challenges
Odds are that when you buy (or consider buying) a new shiny technology system, you:
- Will have built your business case around it
- Know all (or most of) your use cases
- Are prepared to have to replace one or two of the existing systems with the new one
- Will most likely look at those dependencies and make sure you’re cutting the right ties between the right systems at the right time
Changing an integration platform implies that you have considered the above and are also prepared to tackle challenges, such as:
- What the new kit is made of, (e.g. the language(s) supported by the new integration system) vs. the old one and its implications (e.g. availability of required developers’ skills)
- The well-known processes wrapped around the old system vs. potential new ones that might be needed when the new system is in place
- The amount of time the new integration system might need to run in parallel with the old ones along with the cost implications
The old system seems hard-coded into an organization when it’s time to change it. But systems and the processes wrapped around them are not everything. People, their skills and their ability to adopt new systems and to adapt to new ways of working where necessary, especially against an imposed timeline, are a huge part of a successful change.
This is even more important when discussing an integration system, which often impacts multiple lines of business.
3 factors that can indirectly (but greatly) influence your success
If we are to widen our perspective, three themes shape up that seem to have a great influence on the way we can drive the adoption of a new integration system from a very early stage, even before we choose the platform.
Strategy alignment: Know your “whys”
The benefit of this may not be immediately obvious, but it is important to keep an open eye on the holistic strategy. Know at every turning point what is the wider general direction of travel for your organization. Follow it when it changes and know what it is that you are ultimately trying to achieve – and why.
For example, if the business strategy is to drive-up revenue through increased sales or to open up processes to partners and customers, you may want to deliver in line with these goals. If you don’t do this, you risk delivering a solution that goes against the direction of travel set by the organization or something that has less value than it could have had.
Having regular checkpoints throughout delivery will help you ensure that you are aligned from day one to go-live. Write or adapt the integration strategy and the API strategy for your org, especially if the new system is brought in to support or introduce new ways of thinking and working.
If you intend to bring the new system to support your efforts to transition to a composable business model, you may want to start thinking of APIs as products. It’s important to have this goal described and communicated to your org as early as possible, ideally before bringing the new platform in. The Integration or API (Product) Strategy can be great means to do that.
Articulate the goals and objectives of your integration project clearly, link them to the strategy, and communicate them widely to all the right stakeholders. This will streamline your path to success by giving you the buy-in from the supporters that you may need on the journey and by preparing your company for a smooth adoption of the new system when the time comes.
Technology landscape: Know your “whats”
Know the wider As-Is and To-Be technology landscapes – at least at a high level, for context.
No, you don’t need to know every bit of detail of the As-Is technology landscape, but you do need to understand what matters to you. Similarly, you do need to be flexible and allow your slice of the To-Be architecture to pivot as and when the organizational wind changes course. Ignoring the architecture altogether, tempting as it may be, will not serve your best interest when driving a change like this in complex environments.
Knowing the wider technology landscape is essential when you drive any type of technological change because it helps you to see ways of having the new system(s) assimilated within the landscape seamlessly. It is even more relevant when introducing an integration platform because this platform will very likely be the backbone of your application network. This means that it will greatly influence and be influenced by this wider technology landscape.
Moreover, innovation opportunities are often hiding in plain sight, and having a clear view of the technology landscape can sometimes enable you to drive innovative initiatives from the inside out.
Identify the list of foundational APIs that you will build with the new system and establish the right priority for them. Consider business priorities, budget availability, and more, but factor in reusability as well. The savings potential might be surprising. Map technology to business outcomes and value objectives
Efficient operations: Know your “hows”
On one hand, the old way of doing things is not always the best way going forward. On the other hand, new ways aren’t always necessary.
There are a variety of operating models out there, most of them revolving around Agile methodologies. You will likely be tempted to adapt your current operating model to the examples you see outside of your business, but you’ll need to also keep in mind the multiple threads of change happening within your org. Getting the right balance is instrumental to avoiding the deep scars that organizational change can often leave behind.
Be mindful of the people who will implement the change and the people who will operate the new system. Consider what would work best for them. Your operating model should include details such as:
- Funding model
- Support model
- Collaboration model
- Communication plan(s)
- Training plans
Expert support is available out there and the objectivity brought by an outsider’s viewpoint can often help with balancing the decision-making in this area.
- Governance isn’t popular, but it needs to be considered: Do you need it? If you don’t, why not? If you do, what type? Consider ways of making it easy for people to be compliant, document and communicate the processes around it, not just what’s expected. If you choose to transition from heavy-weight governance to a lightweight one, consider the implications and the right time and way of transitioning.
- Build a roadmap: A long-term program roadmap is a must. Apart from laying out a clear delivery plan with key milestones and dates you commit to, it will also keep you on your toes when you will be tempted to pivot unnecessarily. Be prepared to make changes to it though when truly necessary.
The short project roadmap or plan will help your teams align to your long-term roadmap and will identify blockers, risks, and dependencies in a timely manner. Publish and give visibility to the roadmap to the widest possible audience.
In a nutshell, some ways of doing things are smoother than others, and choosing the right one requires some careful consideration of the options available. After all, change doesn’t always have to hurt. Small tweaks can often ease heavy burdens greatly. If you can take some pressure off your teams on the journey, why not do it?
Bonus tips: Aim to run light
- Consider getting help when you can. Go to (the right) partners for help with delivery when necessary and sensible – not just for the sake of it
- Reuse (templates, blueprints, accelerators, etc.) when possible and it makes sense to do so
- Consider automation opportunities where relevant – whilst avoiding the trap of complexity increase for your technology landscape
- Consider setting up a cross-functional team, e.g. a Center for Enablement (C4E), to enable your teams with more than just training and tools. Help your team find what they need when they need it, and support behavioral change.
- Track your progress. Accountability feels easier when you know where you stand and why
Conclusion
There are no precise, foolproof, and repeatable solutions for a guaranteed, successful transition or migration exercise. Intuition and the ability to adapt to given situations or react to given data (or lack of it) play a key role in the process.
However, having a checklist of the things that should be done normally is a good foundation on which anyone has a better chance of building successfully. Experience, lessons learned, and beaten paths are often the core ingredients for intelligent and inspired improvisation.
We’ve taken the liberty of creating a downloadable checklist for you:
