September 27, 2017
Organizations of all sizes have attempted to revolutionize their business under the umbrella of “digital transformation,” but many of these efforts have failed to achieve the desired results. Contrary to broadly-held beliefs, the root cause of such shortcomings is often not the technology that was selected, but rather the misapplication of technology to the problem—or a misunderstanding of the problem itself.
The dizzying pace of technological change also means that digital transformation activities look vastly different now than they did just 18–24 months ago, making it difficult to benchmark results. Even the phrase “digital transformation” is squarely focused on the technology. The reality, however, is that all business problems involve people and process components that must be part of the solution.
Despite these common obstacles, the ability to digitally transform a business is one of the most critical ingredients to virtually every organization’s competitiveness. The evolution of software architecture patterns, new organizational approaches to development and operations management, and the wide-scale adoption of agile software development practices have all created significant opportunities to streamline operations and reduce expenses. At the same time, these improvements have introduced new challenges for even the most technically savvy IT teams.
Overcoming these challenges and realizing the benefits related to digital transformation requires broad organizational commitment and a focus on achieving specific benefits. Quantifying the benefits in business and IT terms is an important step in gaining buy-in to transformation efforts and in measuring success. Fortunately, there are benefits that affect nearly every aspect of modern companies that make building a business case based on your return- on-investment (ROI) possible. In order to quantify that ROI, it’s important to first understand what is typically involved in digital transformation efforts and the components that make it possible.
Establishing a common understanding of “digital transformation” within your organization may seem like a basic place to start, but gaining this consensus upfront lays the groundwork for good measurement of your ROI later. Modern definitions of this increasingly popular phrase typically include one or more of the following:
Dramatically improving customer experience through the use of modern tools, from enhanced mobile experiences to personalized interactions based on data science to pervasive networked devices.
Operational enhancements through digitized processes, modern application development, and infrastructure-hosting technologies; enables IT teams to work more efficiently, respond more effectively to evolving customer needs, and make more cost-effective use of their resources
New and significantly modified business models enabled through primarily digital means
While many of these transformations are directly customer- or employee-facing, all of them required a fundamentally different way of operating their technology resources. In many cases, they also required a different business or product mindset.
Digital transformation initiatives often focus solely on IT enablement, i.e., allowing technical teams to develop and deliver software faster and cheaper. However, if this transformation isn’t coupled with a parallel business process transformation, the new capabilities won’t be fully leveraged and the transformation won’t have the expected bottom line impact.
In order to make use of an enhanced technical delivery capability, business teams need to adopt a culture of agility and customer focus. This requires accelerating the product development lifecycle for both new and existing products, i.e., getting good at gathering customer data, synthesizing it into an ever-evolving strategy, and quickly translating that strategy into tangible features that respond to market conditions and customer expectations.
Slow development and delivery cycles have traditionally forced businesses into long planning cycles. Unable to respond to change in the short-term and unable to predict market conditions in the long-term, businesses have had no choice but to chart a long-term course and commit to it in even as circumstances changed.
To hedge against the uncertainty of long-term customer and market conditions, businesses have traditionally focused on factors more within their control to drive new products and services. As a result, internal factors such as existing company resources and organizational competitive advantages often become the driving force behind innovation, rather than customer needs and market opportunities.
Digital transformation allows businesses to become much more customercentric. As time horizons shorten, customer needs become clearer, more reliable drivers of business value. Rapid development and deployment of technology allows businesses to make decisions based on current market opportunities and on customer demands.
Any successful digital transformation must involve a transition in how a business manages their digital customer experiences. Whether software is in active development or is already deployed and functioning well, it needs to be actively managed or risk falling behind the ever-changing needs of its users.
The long-term health of a software product is directly related to how efficiently it can move through the software development lifecycle of strategy, design, build, and measurement.
The short development timelines made possible by agile development allow business teams to adopt lean product development approaches. At its core, lean methodology is about the rapid experimentation and measurement of new product ideas. Validated learning is valued over all other metrics and real customer feedback becomes a central driver. Because digital transformation lowers the cost of experimentation and failure and accelerates this process, businesses can take bigger risks and reap bigger rewards, and do this more often.
Digital transformation impacts internal information systems just as much as it does customer-facing ones. Too often, the quality of internally-facing software is overlooked. The excuse, “They have to use it,” precludes attempts to create better software for enterprise employees.
The quality of internal software ultimately impacts the quality of the external customer experience. For example, more timely information in the hands of customer service representatives leads to better customer service. Easier to-use data management tools reduce costly data entry errors. Interoperability between systems leads to smarter cross-channel experiences that will impress the customer.
Digital transformation is about a cultural transformation. Companies that fully embrace it use the same methodology and tools to develop any software, whether it’s customer- or internally- facing.
The view of digital transformation activities within IT organizations is often focused on technology and tools, but it’s important to consider the people and process implications as well. While the tools are an important part of the solution, they must support the processes and organizational designs of the business. The effect of digital transformation is usually different for existing applications using legacy technology (“brownfield”) and new software developed using modern software architecture and development techniques (“greenfield”). It’s important to take these differences into account when thinking about the ROI implications of a transformation strategy.
One way of visualizing the technology, people, and process implications is shown below in Figure 1. Technology is shown in the teal boxes with multiple layers, starting from the bottom with cloud hosting (both public and private) and building additional capabilities on top of each layer. Continuous Integration and Continuous Delivery (CI/CD) tools enable automation of build, test, and deployment processes. DevOps and Agile processes (shown in blue) govern how those technologies are used. Infrastructure operations, along with application development and delivery teams, represent the organizational constructs and human resources that execute those processes and leverage the technology. (shown in light green) Security typically governs all of these elements, oftentimes with its own requisite people, process, and technology.
Figure 1. Digital transformation requires a combination of technology, process, and human resource capabilities to be effective.
The advantage to using greenfield projects to begin a digital transformation effort is the absence of technical debt that often makes fitting legacy applications into modern infrastructure so challenging. On the other hand, greenfield projects typically deal with new products where requirements may not be well understood and new technologies and processes are introduced all at once. In this scenario, mitigating risk and creating a mechanism for lessons to be learned and shared quickly is absolutely critical.
Greenfield digital transformation efforts are typically a good place to implement a Platform-as-a-Service (PaaS) hosting strategy, coupled with infrastructure automation and CI/CD capabilities. This combination works well because greenfield projects, which readily lend themselves to CI/CD automation, are often more easily executed using Agile processes than brownfield initiatives are. Additionally, greenfield applications can usually be delivered in smaller units of work that form a minimally viable product (MVP), which accelerates the pace at which the organization can learn from experiences. These types of initiatives may be viewed as less risky ways to experiment with new hosting arrangements, whether through a public cloud provider, a hybrid approach spanning public cloud for non-production environments and private cloud for production environments, or just better utilization of on-premise infrastructure.
These projects are also good places to begin testing assumptions and validating ROI from these efforts. Because of greenfield projects’ self-contained nature, it’s generally easier to identify metrics that contribute to ROI benefits. As we’ll discuss later, ROI can come from a variety of sources, such as faster, more frequent product releases, fewer production incidents, more efficient use of compute and/or storage resources, or improved ratios of operations personnel to infrastructure. Before embarking on a greenfield effort involving these new technologies, it can be instructive to select a few key performance measures to compare legacy systems to the greenfield application.
Potential candidates for greenfield ROI metrics include the following (see Table 1). Such metrics are often beneficial on their own, but also are easily correlated with financial performance metrics.
Table 1. Examples of ROI metrics to be used for a greenfield initiative.
Transformation using brownfield applications can be advantageous because the challenges associated with legacy systems and the process and technology that supports them are usually well understood. As a result, improvements in these systems can be powerful for the business and makes quantifying the effect of those improvements easy. However, these applications typically have significant technical debt and often are deeply embedded in business operations, making change to them more risky.
Successful transformation of such systems relies on careful planning, so a detailed roadmap that outlines incremental changes in a risk-controlled fashion is essential. Incremental changes can begin anywhere in the stack, but often start with one of the following:
CI/CD tooling provides a framework for automating and controlling the software development and release pipeline. CI tools focus on reducing the friction and inefficiencies involved with building and testing software. Developers often spend too much time solving for how to integrate code changes from across a development team, reliably build the application in a repeatable way, and perform basic tests on the software (e.g., unit tests, integration tests, security vulnerability scanning, code quality analysis).
These challenges are amplified as applications become more modular (e.g., when decomposing monolithic applications to microservices) and as dependencies between modules multiply. CI tools integrate closely with developer tooling like source control, build systems, dependency management systems and testing frameworks, eliminating many of the tasks that distract developers from actually building software and enable developers to manage the complexity of highly modular systems.
To achieve higher velocity, the software release process must become so mundane that a release is basically a non-event.
Similarly, continuous delivery tools focus on simplifying the process of releasing software to customers. In many organizations, software releases are a highly manual, human-centric process. Such a process is inherently risky because of the likelihood of human error. As a result, software release events happen less frequently than desired because of the effort required to ensure each event is successful. To achieve higher velocity, the software release process must become so mundane that a release is basically a non-event. To accomplish this, enterprises can look to integrate CD tools with operational systems, such as a PaaS or IaaS, to affect the changes necessary.
CI/CD tools generate ROI by making development and operations staff and processes more efficient and by eliminating human error that can lead to production incidents. Equally important is the role that CI/CD tools in fully realizing the value of investments in PaaS. While CI/CD and PaaS solutions provide benefits on their own, the full value is only realized with a combination of the two.
Virtually every organization involved in software development has some sort of source control system. Artifact management is a corollary to source control. Where source control systems are purpose-built for managing text (in the form of source code and configuration files), artifact management systems are designed for managing binary files and other non-code digital artifacts. These types of files, like compiled libraries, play an important role in the software development process but often are ignored by traditional tools.
Left unmanaged, they can lead to variation in the software build process. For example, an open-source software library may be incorporated into software as a dependency in the build process. If that library is retrieved from a public web site, it’s possible for that library to change without a developer’s knowledge. Similarly, as multiple versions of many software libraries exist, it’s just as important to version control the compiled version of the library as it is the software itself. Finally, many organizations are sensitive to inadvertently introducing open-source libraries with unfavorable licenses or known security vulnerabilities to their product. Artifact management solutions provide a control point for ensuring only approved open-source libraries are used as part of the build process.
Similar to CI/CD tools, artifact management solutions have value independently but generate the most ROI when coupled with other components. By using artifact management as part of a broader CI/CD pipeline, companies can mitigate hidden risks in the build process. Such risks are difficult to detect and predict until they lead to a production outage from a bad build due to poor dependency management or IP litigation caused by a lack of control around third-party libraries.
APIs are a central component to digital transformation efforts for multiple reasons. For some organizations, part of their transformation strategy is exposing APIs to third-parties to create new product offerings or to support additional channels for customer interaction. Other organizations use APIs as the glue between components within their microservice architecture Irrespective of specific transformation strategies, virtually all organizations find some benefit from the flexibility provided by API-centric design of systems. API management tools provide important functions that support API ecosystems including: security, auditing, message transformation, protocol translation, and developer documentation. API management is important to digital transformation efforts because many of the functions they provide are difficult and costly to create from scratch. The ROI that comes from API management investment arises from both the cost avoidance of having to implement their features in a proprietary fashion coupled with the avoidance of costly production incidents or security vulnerabilities from defective implementations.
Cloud infrastructure plays an important role in digital transformations by creating (or increasing) the elasticity of infrastructure. This grants a more flexible, demand-based approach to infrastructure management, as opposed to lengthy and tedious hardware procurement processes that often have long-term capital implications.
In the case of public cloud (or the public portion of hybrid cloud) deployments, that elasticity can also be beneficial by offering more finegrained control over infrastructure expense and by an important role in digital computing, particularly when coupled with a PaaS with auto-scaling features, enables much better utilization of computing resources. The combination of these benefits typically lowers—or at least slows—the infrastructure expenses.
When calculating ROI from cloud migrations, it is important to consider the following:
Every organization has different objectives and a unique roadmap for their digital transformation efforts, but some common themes exist for how to quantify ROI across all organizations. Building a quantitative business case for digital transformation requires an accurate baseline against which you can compare your performance. The most common methods for quantifying improvements from digital transformation require a reliable means of answering the questions in Table 2 with precision:
Table 2. Examples of ROI metrics to be used for a greenfield initiative.
With a baseline established for these questions, ROI from digital transformation typically falls in one or more of the following categories. Product Feature Velocity Accelerating Revenue Product feature velocity is typically accelerated in digital transformation efforts by one or more of the following:
Building an ROI case for these benefits usually involves conducting a pilot with transformed technology and processes and measuring the improvement over an established baseline. Alternatively, a more “tabletop” analytical exercise that looks at specific bottlenecks in the process, estimates the improvement provided by changes, and applies metrics from industry benchmarks can also provide good guidance.
For example, an analysis performed by IDC of organizations using Red Hat OpenShift as their primary application development platform found a 66% improvement in application development lifecycles and 35% reduction in hours per application developed. By quantifying the value to the business— usually in terms of revenue—of each feature, and calculating the additional number of features possible per year, it becomes a simple exercise to show the value created through transformation.
Legacy IT operations is one of the largest drivers of expense in many organizations. The IT operations ROI from digital transformation typically comes from improved labor efficiency provided through the following changes:
Again, the ROI case for these benefits is most impactful when based on a pilot or proof-of-concept using these technologies deployed in a realistic setting. That can be a significant undertaking, so referencing publicly available information on efficiency can be helpful. IDC’s analysis found a 35% reduction in the IT staff time required per application developed.1 An important factor in achieving these benefits is reaching a certain scale of applications using the transformed technology. It is difficult to recognize the advantage when only 1% of the IT environment has been addressed, but the value becomes much more evident when 10%–25% of the environment has been modernized.
Unplanned outages are extremely disruptive to business. Although some costs, such as brand/reputational damage or added regulatory scrutiny, can be difficult to quantify, outages in revenue- producing systems can be measured more easily. The following changes often influence these costs:
This ROI case can be difficult to justify without the benefit of hindsight. However, it is possible to estimate benefits by analyzing historical failure modes and identifying outages that would likely have been prevented by taking the steps outlined above as part of a digital transformation. Accurate categorization of the root cause makes this exercise much easier to begin. Once candidate incidents have been identified, it’s useful to have a detailed target state architecture in mind to then perform a tabletop analysis of each incident to determine which incidents would have been avoided or shortened by using a PaaS with automation.
Infrastructure expense is a significant contributor to overall IT expense for most organizations. Reducing this expense as part of digital transformation usually relies on making more efficient use of compute resources, particularly by increasing the density and utilization of virtual machines by using IaaS or PaaS solutions. A secondary benefit of IaaS and PaaS, coupled with automated infrastructure provisioning, is that adding new infrastructure becomes a much faster process. As a result, it’s easier to order infrastructure when it is truly needed rather than having idle hardware ready to respond to demand. Finally, elasticity of compute consumption in the public cloud means that infrastructure can be consumed only when it is necessary, making it much easier to reduce infrastructure expense during periods of low system utilization.
Calculating the ROI for these scenarios usually centers on calculating current and target server utilization rates and determining if existing infrastructure can be retired and how much infrastructure can be avoided being purchased based on target utilization.
The use of CI/CD tooling and automation can be a significant efficiency gain for software development teams. For instance, customers using CloudBees Jenkins Enterprise have reported one week of development productivity gained monthly by automating build processes, reducing or eliminating time spent resolving faulty code merges, and dynamic scaling of build environments based on demand.
The ROI of these tools can be calculated in a similar fashion to the IT operations labor efficiency. Recent research indicates that DevOps developers spend more than half their time on non-design, non-coding tasks that don’t contribute to strategic initiatives. Conservative estimates suggest that efficiency equal to 0.4 full-time employees per development team is possible with only a quarter of manual tasks being automated and as many as 1.35 full-time employees for teams with fully automated CI/CD tasks. Beyond the automation benefits, there are additional gains that can be realized for teams where manual build or merge processes contribute to unplanned, manual developer involvement.
It is critical to consider which components are necessary for a successful transformation effort, build a roadmap for execution, socialize the plan and ensure broad organizational support. Being able to express the value of the effort in terms of ROI—and tying that ROI to specific, tangible changes—is important to earning that buy-in.
Digital transformation is a necessary activity for many organizations to remain relevant and enable new business opportunities. In addition to its strategic importance, the components necessary to deliver such a transformation often has other financial benefits that provide a return on investment. It is critical to consider which components are necessary for a successful transformation effort, build a roadmap for execution, socialize the plan and ensure broad organizational support. Being able to express the value of the effort in terms of ROI—and tying that ROI to specific, tangible changes—is important to earning that buy-in. While technology and tools are important, the organizational and process aspects must also be planned. Calculating ROI can seem daunting, but existing research and expertise can help make informed assumptions.
1 - Carvalho, Larry and Marden, Matthew. IDC. The Business Value of Red Hat OpenShift. 2016. Electronic.
Founder, Chief Executive Officer
DevOps Capability Lead
Chris has more than 15 years of technology leadership experience with a specialized focus on financial technology solutions in the consumer, commercial and wealth management space. He has led software development, infrastructure, and QA organizations at multiple Fortune 100 companies and also helped grow and launch a number of early-stage technology companies. Chris’s technical expertise, startup experience, and global program management background enables our ability to support a wide range of clients at all stages of transformation.
Srinivas "CJ" Coimbatore has over two decades of experience in diverse disciplines such as sales, marketing, software development, architecture and delivery, and has worked with teams in all of the major geographies. He is an effective change agent and is very interested in collaborating with teams that are involved in transforming their process through DevOps. In his spare time, he follows Formula 1 racing teams, rides his motorcycle, and—along with his friends—helps raise money for children with health challenges and for the Pediatric Brain Tumor Foundation, Make-a-Wish Foundation, and Angels Among Us. He hopes to eventually spend more time teaching math and science to children.
In this new video series from Levvel, our experts discuss the disruption happening in the insurance industry, common pain points, stories from the field, and the opportunities for established insurers to modernize and level the playing field.
Data can be easily transferred, but how can we successfully communicate another person’s feelings through user research? What is the best way to communicate our user’s journey? The answer starts with empathy and storytelling.
At the end of lunch with a mentee, I used the items on our table to express the fundamental concepts of Kubernetes. Sometime after explaining the purpose of the Kubernetes scheduler, she asked a question I spent the next several weeks thinking about.
Throughout this series we'll provide answers to frequently asked questions surrounding product management for RTP, such as managing the product(s) long term, dealing with cannibalizing current products, and more.