Just commit. What’s so hard about that? In truth, there’s a reason why commitment phobia is a punchline and it’s tough to settle on a place to go to dinner, let alone make a critical choice like when or how to start the application modernization process.
For starters, there are so many questions to ask. For example:
- What is the status quo of each software initiative?
- Which applications are driving value for the business? Which aren’t?
- When and how should I break my monolith into microservices? What’s the risk?
- Should I move to the cloud – private, public, hybrid?
- Everyone is talking about containers and Kubernetes, do I need this?
This is by no means an exhaustive list, but a sample of what might come up when considering where and how to start a digital transformation journey. Questions, buzzwords, and trends abound, and it can be easy to get trapped by analysis paralysis until enough time has gone by that indecision has become the decision.
According to Forrester’s Predictions 2019, 25 percent of firms will decelerate digital efforts in 2019. For many organizations, slowing the pace of innovation directly results in lost market share due to more nimble competitors entering their space.
“In 2019, digital transformation moves from super-wide enterprise efforts to a pragmatic, surgical portfolio view of digital investments with the goal of making incremental and necessary changes to operations. – Forrester Predictions 2019
The key to starting and committing to the application modernization process is to start small and scale up as you learn. Following trends is not going to bring the organizational change needed for a successful digital transformation. It takes practical, incremental, and iterative progress.
Here are a few practical steps for getting started:
1. Start small with a small team or innovation group and scale up from there.
Trying to make a decision on how to proceed with digital transformation across your entire organization is a monumental task. You risk introducing a lot of variable change all at once that can turn chaotic if not managed well. Starting with a small team or innovation group reduces the stress and minimizes the initial impact of getting started. Behavioral science experts call this the “pick one and go” method for overcoming analysis paralysis. Essentially, if you are overwhelmed or unsure about all of your options, just pick one and try it. Collect feedback, evaluate the outcome, iterate, and scale up from there.
When choosing a team or developing an innovation group, avoid thinking along legacy lines which divide teams by stages of the software lifecycle. Think about building a cross-functional team of 8–12 people who can focus on developing the culture, process, and tools needed to continuously deliver software.
2. Make smaller changes.
Keep in mind that the impetus for digital transformation and, more specifically, application modernization, is driven from a business need to deliver value to customers faster. So, making smaller changes to release faster is the single most important change you can make.
Adopt the mindset: what is the smallest possible change I can make to improve something, and how do I get it out as quickly as possible? At GitLab, we call this the minimally viable change (MVC), and it’s what allows us to ship nearly anything within a single release. This is especially important when approaching legacy software. If you start making a ton of big changes over a few weeks, the risk of breaking something and not understanding what change caused the error grows exponentially with every change.
With an MVC mindset, you can experiment with what works best without risking downtime. Smaller changes are easier to review, understand, and roll back if necessary.
3. Prioritize mastering continuous delivery and deployment (CD).
You have your team assembled, you’ve made MVC your mantra, and now it’s time to establish a clear goal. If you’re just starting down the application modernization road, chances are that you don’t quite know what strategy is going to work for your organization yet (that’s what the innovation group is for!). What you do know is that you need to be able to ship features to production faster while maintaining stability and security. By prioritizing understanding your current deployment pipeline and how to automate to achieve continuous delivery, you discover how the underlying infrastructure needs to change.
Author Gary Gruver outlines this philosophy in his book, "Starting and Scaling DevOps in the Enterprise". He writes:
It is my personal experience that creating, documenting, automating, and optimizing deployment pipelines in large software/IT organizations is key to improving their efficiency and effectiveness. – Gary Gruver
Start with a single application and document how a change goes from idea all the way to production and monitoring. This will give you a good understanding of how it’s currently operating, what its dependencies are, and how you can start to decouple.
Finally, the end goal is to enable teams with fully automated CI/CD pipelines so developers can get their code to production faster. Taking both a cultural and technological approach to change is needed to adopt DevOps methodology.
Are you ready to commit to your digital transformation journey? Get inspired and learn how Ask Media Group modernized their architecture and development with microservices, containers, and kubernetes.
