This research is part of five reports looking at the alignment of business and technology within a Digital Business Platform. Other reports will focus on Digital Feedback Loops, how the API is the Product, Rapidly Building and Deploying Applications, Automated Deployments, and Controlling the Operational COGS.]
Premise: While it’s not a metric that is measured on any balance sheet or executive dashboard, “Idea to Execution Time” (I2ET) may become the most important measurement of any Digital Business Platform. As the face of every business becomes more digital, shifting technology from a cost-focused domain to a market-focused domain, the ability to rapidly build, test and deploy applications will become a more defining competitive advantage in nearly every industry. Enabling the business to generate new ideas and on-going iterations, and then facilitating those into digital products.
Somewhere along the line, the reasoning behind the phrase “time is money” got bifurcated between business leaders and IT leaders. In wanting to deliver products to market faster, business leaders realized that shorter amounts of time are equal to greater revenues. In wanting to maintain the uptime of IT services, IT leaders realized that greater amounts of time are equal to higher availability. But in the digital world, these divergent approaches will need to be more unified and collaborative in order for the business to be competitive in a world where customers’ willingness to wait is rapidly decreasing. Wikibon looks at how business and IT leaders can reconcile and rationalize the need for faster delivery of applications, while also delivering higher levels of availability and security.
[Definition] Idea to Execution Time (I2ET) – A two-part business metric that [a] measures a company’s time to move from a new idea to the market-facing execution as a digital product; and [b] measures a company’s time to iterate or exit the original idea based on digital feedback loops from the market.
The framework for accelerating I2ET will incorporate these core capabilities:
- Build Smaller, Build Faster, Update Frequently. Instead of building monolithic applications that can take 12-24 months to be updated, tested and deployed, digital businesses are building smaller, distributed applications that can be modified and updated on a more frequent basis. These microservices are best rendered as APIs providing a product-level service. Over time, these microservices will often be reused in new ways by other aspects of the Digital Business Platform.
- Building and Deploying on a Cloud Native Platform. The fewer people making technology infrastructure decisions — especially developers — the better, because it assures greater infrastructure simplicity, operational coherence, and more rational IT cost structures. Structured and Unstructured Platforms allows developers to focus their attention on the application and not on the underlying infrastructure and operations. This creates a more consistent experience for both Development and Operations teams.
- Continuous Integration and Continuous Deployment of Software (CI/CD). To accelerate the I2E time cycle, software must be built, tested and integrated in highly automated pipelines. This is known as Continuous Integration and Continuous Delivery. The CI/CD model allow frequent updates to microservices throughout overall product lifecycles.
VIDEO: Richard Haigh, Operations Manager at Paddy Point Betfair, talks about how his engineering team is now able to more rapidly move applications from inception to production by using highly-automated environments.
Moving from Monolithic Applications to Microservices
The Cloud Native platform and CI/CD pipelines provide the underlying infrastructure to build digital applications. These two dynamic elements are much different than most existing IT organizations have in place today, and are critical factors for IT to get right as they move to the cloud. But without a change in philosophy about how applications are developed, businesses will not be able to optimize their I2E times and market impacts.
Conway’s Law tells us that companies build systems which ultimately align to their internal communications patterns. In order to change how the company will organize and operate in the digital era, there will need to be changes in organizational structure as well as application development. The change in application philosophy is the movement from monolithic application architectures to more distributed microservices architectures. They small application domains allow individual elements to be added, changed or removed without impacting the other elements of the overall digital product. The microservices approach delivers three key advantages over monolithic applications:
- Small Teams, Smaller Failure Domains – Microservices are able to be developed and maintained by smaller teams, which can adapt to change more quickly. As changes to the microservice are made, their impact has a smaller area of potential risk if an error is introduced.
- Autonomous Services – As applications are distributed into smaller functions, each function can be designed to be independent of the others. Services interact with each other through standard APIs. If services need to be changed, it can be done independently of other services.
- Rapid Testing and Deployment – With a CI/CD pipeline in place, the smaller updates to the microservices can be rapidly tested, integrated and deployed without causing impact on the broader digital application.
Overall, while the microservices architectural philosophy can introduce additional management complexity due to the large number of services, it brings a style of application development which can move much faster in bringing new digital products to market.
Cloud-native Platforms – Abstracting Away Complexity
In order to accelerate the pace of I2ET, digital businesses must focus on systems to build, test, integrate and deploy new software. Every born-in-the-cloud company, whether it’s web scale companies like Google and Facebook, or disruptive startups like Netflix and AirBnB, employs a cloud-native platform today. Transitioning businesses will also seek to leverage cloud-native platforms to help standardize and simplify how they deploy and manage faster-moving application environments.
Cloud-native platforms enable developers and operators to accelerate I2E through three core architectural capabilities:
- Simplify how developers can move applications through the Dev/QA/Staging/Production lifecycle. This can be done through various types of artifact to application packaging.
- Tight integration with CI/CD pipeline system to automate testing and integration into existing systems.
- Simplifying the overall operations of the cloud-native platform by automating elements of scaling, monitoring and overall system availability.
Leading cloud-native platforms (built on technologies such as Cloud Foundry, Docker, OpenShift, Kubernetes, Mesos) also provide one additional attribute that is a critical consideration for businesses managing the transition to market-facing applications; the ability to abstract the underlying cloud (e.g. AWS, Azure, Google Cloud Platform, OpenStack, VMware, etc.). This abstraction means that the Cloud Native platform can be run in either a Private Cloud or Public Cloud environments, or bridge those environments to create a Hybrid Cloud. This allows IT organizations to leverage the most appropriate resources (scale-out infrastructure, machine learning, database-as-a-service, industry-specific compliance frameworks, etc.) for any digital product requirement.
See how Verizon was able to rapidly deploy a massive amount of NFV infrastructure for new mobile applications and subscribers.
Continuous Integration / Continuous Delivery – The ERP Supply Chain for Digital Bits Factories
As discussed in “Controlling the Operational COGS,” the analogy between a 20th century factory and 21st century data center allows parallels between a physical supply-chain and digital CI/CD pipeline. To ensure that IT organizations can accelerate I2ET, they must have a pipeline that can manage the initial application deployments as well as ongoing iterations and updates. This framework, known as Continuous Integration and Continuous Delivery (CI/CD), allows developers to focus on writing applications and making frequent updates, and then automates the necessary testing and deployment to the cloud-native platform.
Without a CI/CD pipeline system in place, the digital bits factory would have to shut down and reconfigure “production lines” every time a new product update is needed. By providing the structure for automated testing, the CI/CD system also reduces I2ET and improves overall software quality by reducing human inputs and errors.
Depending on the pace of change for the digital products, the CI/CD system may get frequent usage or have spiked usage patterns. This is another reason the overall Digital Business Platform should be architected to run on any cloud infrastructure (public or private).
