It’s an accepted truth that applications deployed one or two decades ago simply can’t deliver the performance, agility or efficiency necessary to keep up with the demands of today’s changing business climate. As such, smart organizations are rebuilding their application portfolios and migrating to the cloud.
At Slalom, we partner with companies like Boomi and our mutual customers to push the boundaries of what’s possible — together. We provide strategic guidance and technical expertise for companies large and small, across the U.S. and around the world. We are a purpose-driven consulting firm that helps companies solve business problems and build for the future, with solutions spanning business advisory, customer experience, technology and analytics.
And from this work, we’ve learned a few things about how to ensure a data and analytics cloud migration project runs as smoothly as possible. As with so many big undertakings, preparation is a key to success in cloud migration.
Here are five things to do before you begin buying software or writing code for any cloud migration project.
Begin your cloud migration project with a formal discovery process, and use that process to explore every aspect of the initiative. What needs to change? Why does it need to change? Who would be affected by the change? What would be the effects of migrating a particular application or group of applications to the cloud? What changes in staffing or workflows would be required to support the new cloud environment?
In this discovery phase, we take nothing for granted. We want to make sure the organization really understands what needs to be done, why it needs to be done, and how it’s going to affect the organization.
It’s important to note that cloud migration almost always means more than taking a business application running in an on-premise data center and replicating it in a public or private cloud. Every organization we work with wants to take advantage of the new features, the new interfaces, and open APIs available in the latest SaaS applications.
And even if enterprises didn’t know about these new features, the nature of cloud computing requires changes — often quite sweeping changes — to the status quo. Why? One reason is that cloud applications today are developed and managed using agile practices.
The application itself and any third-party services it depends on are typically being updated every two to four weeks, not every six months or longer, as was the case with legacy applications.
To keep up with a fast-shifting infrastructure, the new cloud services have to be designed and implemented to move at the same pace. For many organizations, that’s a significant change.
Which leads us to our second point.
Since moving to the cloud is almost impossible without adopting agile processes, if the organization’s development and operations teams haven’t yet adopted agile process, they’ll end up doing so now.
The effect of agile processes isn’t limited to the development team. Developers can’t work through burn-down lists if there’s no way to deliver updates continuously to production systems. Operations need to adopt agile processes to deliver continuous integration, keeping in sync with the development team. And business leaders need to be actively involved in prioritizing and approving features and enhancements.
These different teams work like an interlocking set of gears in a machine. Once the development gear starts turning more quickly to support agile processes, it forces all the other connecting gears to turn more quickly, too. This can be disruptive at first, but the long-term benefits can be profound.
The organization as a whole becomes more agile, which, most importantly, brings essential speed to operations and workflows. The business side can respond much more quickly to market opportunities and competitive pressures. Developers can implement new features quickly, addressing critical customer needs. And operations teams can be continuously optimizing IT investments to get the best possible performance.
When tackling cloud migration or any other major IT project, don’t just think in terms of technology. Ask about the impact on people and processes: which people are affected directly, and which people are affected indirectly? Who needs to be hired, and who might need to be re-assigned or re-trained? What’s the impact on processes? How should processes change? What’s the best possible outcome for making all these changes?
To handle all these elements — people, processes, and technology — successfully, it’s important to have a methodology. The methodology that we’ve created at Slalom is called the Product Engineering Methodology, or PEM.
The PEM is a four-step approach for us to engage our clients through the discovery process, and then take that discovery into delivery – the implementation phase – to build out what we initially discovered and have set out to do.
At every stage of the four-stage process, we’re thinking about more than just technology. We’re thinking about IT users and business users. We’re thinking about processes for developers, operations teams, and business users. And we’re thinking about the technology that supports and connects all these users and processes.
We want that technology to be able to support agile processes, so whenever possible we’re selecting solutions like Boomi that provide low-code development, streamlining integrations and enabling business users to play a larger role in creating and managing integrations and workflows.
When developing a plan, analyze tasks in terms of potential benefits and ease-of-completion. Plot possible tasks on a quadrant with axes of high benefit/low benefit and easy-to-do/hard-to-do. Once you’ve plotted these tasks, you’ll end up with four categories:
Start with the tasks that deliver high benefits but are easy to do. These “quick wins” will give the project some momentum and help win over any skeptics who are wondering if this project can really succeed. Low-benefit/hard-to-do tasks should be strongly de-prioritized. Everything in the middle will need to be sorted against organizational needs.
We recommend wrapping the discovery process with a few key deliverables.
These deliverables provide guidance for people working on the project. They also help business leaders and other stakeholders understand what’s being done and why it’s so important.
The vision statement lays out the organization’s long-term objectives for the project. The vision statement should also list any challenges identified during the discovery process, and it should identify possible solutions for these challenges so the organization can achieve its goals.
A second deliverable is a roadmap and implementation plan. The roadmap basically says, “All right, we’ve identified the strategy and set out possible approaches. Here’s how we’ll execute this work and achieve all the critical milestones.”
The implementation plan goes one level deeper and lists specific actions for the project. For example, if we’re migrating an application, here’s how we’re going to move the application, and here’s how we’re going to use Boomi’s integration platform to integrate with other key applications.
All the tasks cited go into a backlog list that the development and operations teams will work down, following agile practices. By working down the backlog list, they’ll perform the work necessary to move the project forward and to achieve the milestones identified in the roadmap and implementation plan.
Finally, there’s a solution architecture deliverable that builds on the other two deliverables and describes what the organization will achieve when the implementation is complete:
A good solution architecture should be able to answer these questions.
Follow the five steps outlined above, and you’re sure to have a more successful cloud migration project.
About the Author: Oliver Asmus is an information management & analytics leader at Slalom, New York. Slalom is a Dell Boomi partner specializing in IT consulting and systems integration projects.