When I joined Intrado in 2015, it was a very cloud-negative organization that was set on leveraging its on-premises infrastructure first and foremost. While there was a desire to move faster than our internal hardware and virtual machines would allow, our process was slow – taking 60 to 90 days to spin anything up.
We made the decision to take a multi-cloud approach for a number of reasons. For example, our organization is unique in that we acquire anywhere between four and six companies a year – sometimes more – which poses some infrastructure challenges.
[ Read our related article: Multi-cloud vs. hybrid cloud: What’s the difference? ]
Every time we spearhead an acquisition, we pull in a new technical architecture. Because some of these companies are on their own cloud journey, we don’t perform a lift-and-shift between providers, ensuring we don’t upset their trajectory. Instead, we aim to insulate, optimize, and enhance what they’re doing.
We also have a number of customers that compete in some way with Amazon. They wanted to ensure that their workloads that support their business don’t also engage their competitor. A multi-cloud approach enabled us to avoid this.
For these reasons and others, our stack includes Amazon Web Services, Microsoft Azure, and Google Cloud Platform, as well as our own on-premises stack.
A framework to follow
Given the volume of acquisitions we perform, we needed to contain cloud sprawl, because it’s easy for folks to ask for X environment in Y location. Our position is, “Sure – do that, but we’re going to pull you back into an abstracted environment.”
Because of this, we needed a clear, articulated process for platform simplification. We have an overall strategy for Intrado, and a more tactical implementation of it at the product level. We have more than 750 applications in our portfolio, each with its own set of business drivers, outcomes, and staff that runs it, for example. You need to balance that with what you want to accomplish and the general manager’s business goals. The customer doesn’t care where it is – they just want the product to work.
The framework we developed and use is based on five elements: use cases, technology, process, competency, and culture.
Use cases: Say, for example, you have a communications platform that is core to a company’s business. It has a voice platform layer, an IVR, a contact center layer, a notification component, and so forth. It might have been tightly coupled to .NET, which might make Azure an option.
Or, you have a system that’s a better candidate to go into GCP, but there might be a need to partner with Microsoft. In that case, we’ll run this workload in Azure because of the business relationship, not necessarily the technical environment.
Technology: In this part of the framework, we consider how we’d be able to eliminate technical debt and control cost.
Process: We look at the CI/CD processes and the security footprint. How do we manage that from both a static and interactive code analysis perspective?
Competency: We also factor in the competencies of your current staff. What do they need to be trained on? And how do we avoid an orphan set of capabilities in the company?
Culture: The key tenets for my team are shared enthusiasm, collective speed, radical collaboration, deep agency, and restless ingenuity. If you don’t believe in shared enthusiasm, pretend until you get there. Collective speed is a culture with a bias for action, where everyone works in short, iterative loops. Radical collaboration encourages the best outcomes from mashups from diverse skills, while deep agency is being very clear on the goals while giving people the authority to make decisions. Finally, restless ingenuity is where you wed resourcefulness with creativity.
This framework gives people the latitude to question whether one way is the best way. Never try to solve a legal problem with a technical solution. Never try to fix a culture problem with technology, because that won’t work. And don’t artificially create processes without the context for a larger organization, because at that point, it’s just theater.
Why multi-cloud worked
As with any major change, we experienced some resistance, particularly from the middle management level. This “frozen middle” was actively hostile to the idea of cloud, and we needed to address it appropriately. We adopted a pirate mentality in that we were transforming our agenda and executing it – but not everyone was part of that future. That’s the tough part.
As some of these folks were leaving, I told them, “As you land at your next company, it will look like this, too. If it doesn’t look this way on day one, it will at some point because this is where the industry is going.” That’s a reality they need to accept.
As we moved through our multi-cloud strategy, we were able to give new and current staff a first-class developer experience. We didn’t want to acquire a cloud-native startup and ask them to regress 10 years in their ability to execute. Ultimately, this mindset has helped us to retain talent.
A focus on value creation
It also enabled us to get good at value creation. There’s a difference between operational variability and value creation: Many organizations make decisions around eliminating variability, but that’s a very operator-intensive view. You get good operationally but have stability, scalability, and time-to-market issues. They take this route because they’ve been burned by cowboy development.
Multi-cloud enabled us to take a different route that was focused instead on value creation. Products go to market quickly because we give the product development teams a first-class experience and latitude to incorporate new or different technologies without suffering through bureaucracy and internal processes that are built to say “no.”
Our multi-cloud approach has turned Intrado from a cloud-negative company into an organization that not only supports cloud, but embraces speed, agility, stability, and operational excellence. This experience has been pivotal during acquisitions and moreover, enabled their – and our – upward trajectory.
[ Learn the do’s and don’ts of cloud migration: Get the free eBook, Hybrid Cloud for Dummies. ]
