Avoiding the Dark Clouds in your Multi-Cloud Architecture

Multi-Cloud ArchitectureThe term ‘multi-cloud strategy’ is now commonly coined as a way of describing an architecture with different cloud environments working together. Gone (long gone!) are the days when the trailblazers were taking tentative steps by acquiring a handful of Salesforce licenses. Today almost any business process can, and is, being processed using a cloud application or via a cloud platform along the way. Most businesses have the likes of AWS, Microsoft Azure or Google Cloud Platform sitting alongside strategic applications such as Salesforce, SAP, Oracle, Workday – with important niche applications like Anaplan, Eloqua and payroll systems complementing them as and where needed.

So, a multi-cloud strategy is the new norm, but care must be taken to avoid inadvertently creating a storm along the way.

One of the problem clouds that I refer to is the crucial cloud that invariably underpins the whole multi-cloud strategy – that of the Integration Platform as a Service (iPaaS). This is the essential glue that allows data to flow from on-premises platforms to the cloud, and from one cloud application or platform to another. Getting this element of your cloud architecture wrong can prove to be a problematic mistake.

Multi-Cloud Architecture

Avoid the most obvious traps

Getting your cloud integration strategy right is crucial, so here are the key pitfalls to avoid:

  • Unconsciously acquiring multiple integration solutions

Perhaps the most common mistake is ‘accidentally’ acquiring multiple cloud integration tools. I met a customer last month that had somehow managed to imbed 5 different types of integration solutions from five different vendors. They did this simply by failing to get ahead of the issue. Each time they acquired a new cloud solution for a specific use case, they managed to buy an integration solution to cater for that need. The result is a confused integration team that are skilled in multiple different technologies but without any expertise in any of them. When a new requirement came across the desk, the team chose to use the integration tool that best suited the team member that just happened to be available to help on the project – not the solution best suited to support and scale the business.

  • Obsessing about the short-term need

I ask every customer I meet one very important question – “what are your cloud plans next year”. That’s a tough question to answer but it’s so important to understand. In all too many cases, the integration solution a company ends up acquiring is based upon the initial use case. The team selecting the cloud integration tool looks at the immediate need and the likely budget allocation for that specific project. This is a great strategy for ensuring a successful project in the short-term – but leads to a rip-and-replace in the medium term. I recently worked with a global CPG client where they had bought a point solution for an API platform requirement – but then rapidly realised that it completely failed to enable them to move large batch environments.

  • Creating fragmentation through point solution deployment

The iPaaS market is moving at a fast pace. In just the last 3 years it has gone from a largely batch and real-time integration platform area to an all-encompassing data management platform. To validate this point it is worth reading the latest Gartner research on the ‘Hybrid Integration Platform’. Customers looking at an iPaaS or ‘cloud integration platform’ in 2018 are no longer looking for a simple point and click integration solution. They are now looking for a vendor that can satisfy a true set of ‘platform’ requirements (including but not limited to batch integration, application integration, API management, data quality, master data management, et al). In the last few years customers have created a fragmented cloud data management architecture by addressing niche needs with point-solution deployments. For example, buying an API management platform, a separate Data Quality tool, a cloud batch integration solution and so on. Again, the end result is a complicated, fragmented data architecture that cannot scale.

  • Failing to have a comprehensive data management strategy

As project teams are assembled and start to tackle that next business issue, it is vital that they are informed by a robust architecture plan with data integration as a core component. Too many times I see teams stumble into short term solutions simply due to the lack of an overarching strategy.

Let me give you a great example of this. I recently worked with two separate Public Sector bodies embarking upon a migration of key IT applications to the cloud. The first had a strategy. They looked at their plans for the replacement of multiple systems and the flow of data that underpinned those changes. They built an architecture based upon a multi-cloud approach and sought a vendor with enterprise data management capabilities to meet the key needs of today and tomorrow. They then built a team that would focus on those platform skills ahead of any technology selection for the line of business applications. The other local authority failed to create a strategy. They had an initial need to replace a finance system – only one element of a larger ‘transformation’ to include multiple application rip and replacements and a major project to tackle GDPR. They tackled the finance application integration as a one-off issue – selecting a relatively unknown batch integration tool but with a plan to replace that in the future or to bring another tool in to work alongside for the GDPR need. A short-term fix – which will take some backing out in the future as they disconnect the integrations.

  • Placing the right long-term bet

As the multi-cloud strategy is rolled out and as integration and data quality processes are configured across and between the new architecture components, be aware that whatever technology foundation is selected to be the glue between those technologies needs to endure long after the SaaS and PaaS applications are deployed. The iPaaS should sit at the middle of your newly transformed architecture for many years to come – at least the next  4-5 years . As such, placing the right bet and selecting a safe pair of hands is arguably the most important selection criteria. Think – will the chosen vendor be around in 10 years (will it be acquired or does it have critical market share)? Will it cater for the new technology hitting my sector – like IoT for example? Does it have R&D investment that will keep up with the main competitors? Is it capable of playing in the new ‘Hybrid Integration’ arena and keeping up with market trends? Are you confident it will connect to your future cloud application and technology choices?

Summary

In the new age of ‘multi-cloud’, data has never been so important. Creating an ensemble of the world’s leading SaaS and PaaS vendors can truly revolutionize the architecture of any business and fulfil their data-driven digital transformation strategy. However, like any great orchestra, it is only as good as the person conducting it. Creating a rogue storm cloud at the very heart of your best of breed clouds can be a time-consuming, stress-inducing mistake that can really rain on your parade!

Comments