Digital Transformation: How to get the real benefits.

Who is currently part of a big digital transformation effort? Who’s busy with a move to the cloud? Anyone currently implementing Agile & DevOps?

It seems like everyone I meet at a conference or meetup and every large organization I read about is in the middle of a Digital Transformation. It must bring great results! I mean, if everyone is on the bandwagon, there must be a huge bottom line impact to warrant the investments!

When I research the topic on what is a successful transformation and what that requires I find it hard to get real numbers. That makes sense, because how do you measure it? According to a research paper by Deloitte¹ on the topic companies are starting to show growth in “Digital Maturity”. A big impact of being digitally mature is the ability to experiment and becoming more flexible. I would argue that the IT capability to learn and adapt is crucial, but to truly bring value needs to be aligned with business initiatives of the organization. Digital transformation is not about IT.

Digital transformation is enabled by technology. The technology available today allows us to operate in new ways. The hyper connectedness of enterprises brings major opportunities to change our way of working. Data collected is at levels never seen before and we have the power to analyze it all and use it to guide our decision making. Everyone and everything is always online.

Digital transformation is a holistic change

The massive shift required to adapt to the market quickly requires an IT capability to deliver new features and products continuously. However, if your IT organization is now moving much faster, but the product planning cycle is still constrained by annual definitions of projects that lead to budgets for a year, how much benefits can you really get from your ability to adapt technically?

Let’s use an example of a digital transformation technology improvement that is well established to see what is needed to get the real benefits. We could choose from “public cloud”, “big data”, “microservice architectures” and many more. The downside of these is that there is not as much maturity in these technologies yet and there is still a lot of movement. One technological approach that has had a huge impact on the industry that is fairly mature is Continuous Integration / Continuous Delivery (CI/CD). I’ll use this as a way to analyze what we need to do to gain the maximum benefits from it.

Example: Getting the real benefits from CI/CD

I am a huge fan of Continuous Integration / Continuous Delivery (CI/CD); the process of fully automating the software delivery process so that in the most mature form every code change committed by a developer can be propagated without human intervention to production. Development, QA, Operations and supporting functions need to operate at a very high level of technical best practices to support this approach. It reduces stress in the organization commonly associated with releases to production and improves the feedback loop to developers immensely (from months to hours).

Unfortunately, I’ve also seen quite a few times how organizations do not leverage the true potential hidden in this new way of working. The business case for projects have to be in before the end of year budgeting cycle, so that they can be planned for the year ahead. In business and IT we are still left guessing what might happen a year or more from now to forecast the expected revenue we will receive from this next initiative. Do you know what the quality of your forecasts are for projects of this size?

In “Beyond the Goal”, Eliyahu Goldratt lectures about technology.² He takes a holistic approach like he did for manufacturing with “The Goal” and applies Theory of Constraints. He begins with the basic premise that;

“Technology can bring benefits if, and only if, it diminishes a limitation.” — Goldratt, Beyond the Goal

To get the benefits he proposes we must answer the following 4 questions:

1. What is the power of the technology?
2. What limitation does it diminish?
3. What rules helped us accommodate the limitation?
4. What rules should we use now?

Let’s answer these questions for CI/CD and see where it leads us.

What is the power of the technology?

To get to the power of a technology, just ask all the proponents. In fact, you will probably need them to stop talking about it.

A CI/CD implementation delivers:

• A repeatable, automated way of building your code
• Automated testing in all environments to validate the code is working
• Single click or fully automated deployment of the packages onto your environments

There is much more than this, but let’s move on…

What limitation does CI/CD diminish?

In the old way of working you would need to manually build your software on your machine and upload a package to your servers. Those packages would then have to be installed by operations following a detailed plan. Then your testers would need to test the environments before moving to the next phase where users would manually test your software. This process requires a lot of organization and alignment, is high effort and introduces a major risk of human error. A full run through the system up until the deployment into production would likely take a few weeks for a moderately complex system, up to a few months for the really complex application stacks.

What rules helped us accommodate the limitation?

Because of the high-effort of testing and deployment as well as the impact on organizations to organize all required people to work on the release, most organizations chose to batch feature changes into larger releases. You would release anywhere from once a year to once a month following a feature roadmap. The release to production with many manual steps would usually leave the system in a state where it was down during the release and that meant that a maintenance window was needed. We needed to work weekends for the releases and scheduled many dry-runs to validate the release was possible inside the time constraints.

What rules should we use now?

Now that a release is a non-event that you can easily execute at any time, without any downtime for end users, with very little effort and energy in the pipeline phases we can rethink our whole approach. Here are some suggested new rules:

• Make your changes to production as small as possible, ideally every reviewed code change is deployed to production, preferably multiple times per day.
• Involve the business before development starts to define automated acceptance criteria that can be used to automatically validate the feature to be built has been built according to specifications.
• Prefer a fix-forward approach (release a new version with bug-fixes) rather than a rollback approach (undo a release after issues are found).
• Examine your governance processes for any further steps that are required right before deployment to production and move these to a phase before development starts. Consider Audit, Security and Compliance for example. How can you address the needs for control through the automated pipeline?

What if we just implement the technical best practice?

To implement CI/CD requires a significant investment of time and money. Some organizations that have done so are now moving much faster than their competitors. However, if you hold fast to a release to production schedule of once every 3 months for example nothing really changes. You will have less testing effort and faster releases, sure, but you do not get the benefit of a continuous stream of valuable software released to your customers. You will not know if the new feature is going to be adopted until it is released and you will not know if it causes any issues with existing features. Lean, Theory of Constraints, DevOps, Agile; all of these practices have a similar message.

• Optimize flow & throughput.
• Optimize for fast learning & feedback.
• Be responsive to changes in the market.
• Continuously improve in small incremental steps.

A multi-month release cycle with a lot of planning and overhead does not fit those goals. The technology is here, but the technology has only removed the limitation that used to be there. It is up to you to change your mode of operation to leverage the benefits of the technology, or you will only see incremental improvements.

Conclusion

Digital transformation and the technical improvements are all amazingly powerful; microservices architecture, big data, data driven decision making, automation, internet of things, the public cloud, API management, etc. The power of these new technologies will only bring real benefits if you investigate which rules are in place in your organization and in how you interact outside your organization that accommodated the limitations of the old technologies. A digital transformation is a holistic change and it requires much more than a great technical partner to implement the new technologies in your organization. To gain real benefits you must explore what policies and rules you have in your current governance and decision making process, such as annual project budgeting, audit requirements and semi-annual release cycles. You will see massive bottom line impact only if you look at how you do business now and how data and hyper connectedness can enable you to change that.

Footnotes

1. Research by Deloitte on Digital Transformations https://www2.deloitte.com/content/dam/Deloitte/nl/Documents/technology/deloitte-nl-consulting-coming-of-age-digitally.pdf
2. Beyond the goal https://www.amazon.com/Beyond-Goal-Eliyahu-Goldratt-Constraints/dp/1596590238