Transformations of any kind are difficult. Ask around and you’ll hear a lot about the need to transform the way you deliver IT services, but there is no one answer on how to do it. And the one thing I have learned from all of the parenting advice I have received is that when there are many different answers for the same problem, you are on your own.
You need to find your own way to solve the digital transformation problem. And context is important, whether you’re transforming your organization or trying to figure out how to get your child to sleep.
Here's how to understand your own context, along with some pragmatic steps I advise my clients to take to set themselves up for success. But first, understand that this kind of digital transformation is not easy; it requires dedicated support, and it can't be just a hobby. If you have the skills needed in-house, free those people up to focus on the transformation, or get some help and pair your people with experts from the industry to drive the transformation together.
Here are the three main areas of a transformation: creating a good first roadmap, structuring your DevOps tooling, and measuring the progress of your transformation and providing ongoing steerage.
How to create a roadmap in a brownfield environment
When you start a new project and build new applications, it is relatively easy to leverage DevOps principles and practices: You just start building them out in parallel with your systems. Unfortunately, most organizations deal with many legacy applications that work within a complex web of dependencies and integrations.
Over the years I have come up with a working strategy to make meaningful progress in these brownfield environments. I call it the "minimum viable cluster," and the idea is to identify a minimum cluster of applications that, when improved, will improve the speed and/or quality of delivery.
[ Special Coverage: DevOps Enterprise Summit 2018 London ]
Look for applications that have a significant effect with respect to investment volume, cluster centricity, and frequency of change and that have delivery dependencies with only a small number of other applications. These are the clusters you should address together.
Systems thinking teaches that if you have dependencies but improve only one of the applications in the cluster, your organization will not realize a benefit. You must address the full cluster to make progress. Often this is not a binary decision but requires some judgment as to what is part of the cluster and what is not. Applications that are affected 75% of the time when your target application changes should be part of the cluster. Manage the other 25% as exceptions.
Here are the steps I follow:
- Pick one of the highest-priority applications as your starting cluster of one (ideally based on some kind of portfolio analysis).
- Understand which applications you must change in order to make a change to the chosen application/cluster.
- Determine a reasonable cut-off for those applications (e.g., only those that cover 75% of the usual or planned changes of the chosen application).
- Continue with steps two and three until the application set stabilizes to a minimum viable cluster.
- If the cluster has become too large, pick a different starting application or be more aggressive in step three.
Usually a cluster of three to five applications is reasonable. Anything larger is pretty much unmanageable.
Once you improve this first cluster, you have two choices: Extend the cluster to more applications based on the next bottleneck applications in the ecosystem, or pick a new application and identify its cluster. Keep evolving clusters once they are on the improvement journey, as success breeds success.
Sometimes you might have improved a cluster so much that further improvement will not provide any more benefit until other systems have improved. Continuous lightweight governance will ensure that you use your organizational change energy in the right places.
How to choose the right DevOps tools to support the roadmap
Take a pragmatic approach to DevOps tooling, since no one tool set is better than others. Most organizations aim for a common tooling backbone consisting of both open-source and commercial products, although some teams stray from the commonly accepted tool set because of their specific requirements. It’s more important to manage the variances than it is to try to get everyone to use the same tools.
It is, however, important to understand what it means for tools to exist in an ecosystem. Good DevOps tools:
Support APIs whenever possible. A good question to ask is whether you can trigger all of the functionality available through the user interface (UI) by way of a command line- or programming language-based API.
Provide version control of configurations in text-based files suitable for the likes of Git. Version control within a tool counts for very little, since you can't integrate it across the ecosystem.
Support multiple environments ( e.g., development versus production). How easy is it to promote configuration? How does the tool allow you to merge the configuration of different environments (code lines)?
Have a supportive licensing model. You want everyone in the company to be able to use the same tool. If it’s not open source, does the tool license work on ranges of user numbers (e.g., under 100, 100-300, 300-1,000), or is it even an enterprise licensing agreement (ELA)? Or do you have to provision it per user?
Part with data easily. You want to be able to analyze and correlate, which means you must be able to export the data for further analysis. Tools that populate only their own dashboards and analytics with no way to export the data hinder real insights.
Follow these points and you will build a strong tooling backbone that will support you through your transformation. If you end up with tools that do not integrate well, you’ll face challenges later on. Such tools are great in the beginning but become a hindrance later.
Consider your DevOps tools as you would any other application. Treat them with the same DevOps practices of automation, analytics, and version control.
How to guide the journey with the right dashboard and metrics
IT teams traditionally have not done a good job of handling the data they create while delivering and running services. The data has remained hidden in systems along the software supply chain (e.g., requirements tools, testing tools, deployment tools, monitoring tools) and is not centrally accessible. That makes it difficult to make decisions based on data or to correlate that data to understand how activities influence one another (e.g., if your automation test coverage increases, does this actually reduce defects in production?).
Business people talk about using analytics and big data to make decisions, but IT often ignores the opportunity to use data to make better delivery decisions. Improving your ability to use data is crucial to driving your digital transformation. As you change things, make sure you can see that things improve and that you can keep identifying the next problem that you need to solve. If you rely only on impressions, gut feel, and manual analysis, you will struggle to stay relevant. You need a more systematic approach.
To address this, my team developed a Splunk dashboard. We feed all data created during delivery and operations into a common data model and present this in the common dashboard. In this way we can examine trends across key dimensions, such as defects, build and deployment performance, and so on. We can determine where problems occur and can come up with experiments and ideas on how to address process bottlenecks and areas of quality concern.
The dashboard moves the discussion from a qualitative argument to one based on hard data that shows where problems lie; it makes those problems visible without the need to switch back and forth between tools. We can use the same analytics ideas as the business side and apply them to IT, which is extremely powerful.
If you still run your IT organization based on Excel spreadsheets and PowerPoint, you need to make this change to succeed with your transformation. The more automation you have and the faster you want to deliver, the less you should rely on slow, manual data gathering.
Pick a reporting platform and start building out your dashboard. The data quality might not be that great at first, but as you start looking at real-time data, your discipline will gradually get better until your dashboard becomes your window into delivery, enabling you to steer your transformation.
The last ingredient for DevOps success
Leveraging data and using common DevOps principles goes a long way toward navigating DevOps transformations. I showed above how to identify your first set of applications on which to focus by looking at data about your applications, how to use DevOps principles to identify a good set of DevOps tools, and how to use analytics to drive your transformation. The last ingredient for success is to be rigorous in your continuous improvement efforts.
For each improvement, set clear success criteria and come back after the implementation to see whether it improved the situation. This systematic learning will be the ongoing change engine for your transformation that will keep you going even when you encounter setbacks. Remember, DevOps is a journey, not the goal.
For more on pulling off an IT transformation at enterprise scale, see my presentation at DevOps Enterprise Summit London on June 25, and read my new book, DevOps for the Modern Enterprise: Winning Practices to Transform Legacy IT Organizations.
Keep learning
Get up to speed on digital transformation with TechBeacon's Guide.
Download this free IDC white paper, "Enabling End-to-End Digital Transformation".
See IDC's Futurescape: Top 10 predictions for digital transformation.
How important is digital transformation to your org? Take our survey and find out how you stand next to the competition.
Thinking of making a change? TechBeacon's Careers Topic Center provides expert advice to prepare you your next career move.
