Improving your Software Delivery Performance with Ensono Stacks v2.5

For more than 10 years, we have been helping our clients deliver digital transformations that enable better business outcomes. On reflection, the most common issue we have helped clients to address is improving upon poor software delivery performance. It is rare that a client will ask us for help in this area; delivery issues are often hiding in plain sight. It is more common for a client to know what business outcomes they want to achieve without knowing how to get there. Software delivery performance is nearly always at the heart of how we achieve good business outcomes for our clients.

But what is software delivery performance, and why is it so important?

But, as an industry how do we objectively measure the efficiency and effectiveness of software delivery?

Since 2016, an organisation called “DevOps Research and Assessment” (DORA)[1] have annually published a document called the “State of DevOps Report”, which uses its research across the industry to define (and refine) key metrics for measuring software delivery performance. Each year the metrics and the targets evolve, but currently[2], those metrics are:

• Deployment frequency, meaning how often does your organisation release software into production.
• Change lead time, meaning how long does it take for the code associated with a new feature to go from committed to deployed in production. Change lead time is a subset of Cycle time, which is a subset of lead time.
• Failed deployment recovery time, meaning how long does it take to recover from a failed deployment.
• Change failure rate, meaning how often do changes to software in production introduce a failure that requires immediate intervention.

Of particular note here is the “Change lead time” metric; it only measures the tail end of the software development life cycle, because it is easiest to measure, and a good indicator of a broader metric called “Cycle time”. Cycle time measures not only the time taken to go from committed to deployed code; it includes the time taken to develop a feature, which forms part of an even broader metric called “Lead time”. Lead time measures the entire time taken to go from developing an idea to production, which is ultimately the cost of a features development. In Ensono, we measure all three of these metrics; Ensono Stacks helps to shorten both the Change lead time and Cycle time metrics.

[1] See https://dora.dev/ for more information.
[2] See https://cloud.google.com/devops/state-of-devops for more information.

Each year, the bar for what “elite” performers looks like gets higher, but the 2023 targets are:

• Deployment frequency, at multiple deployments per day, on demand.
• Change lead time, less than one day.
• Failed deployment recovery time, less than one hour.
• Change failure rate, between 0% and 5%.

It’s easy to understand why software delivery performance is valued by technologists, but at a more macro level, why should businesses care about it?

The value of high software delivery performance is not just limited to reducing costs and delivering software more quickly; there is strong evidence that high performance in software delivery leads to more positive overall business performance.[1] More specifically, high performers in software delivery have twice the organisational performance (considering metrics such as profitability, market share and productivity) and twice the non-commercial performance (considering metrics such as customer satisfaction, experience and achieving goals). Digital is no longer siloed from a business’ outcomes; it is at the centre of successful business in both hard and soft measures.

Much of the time in Ensono, we are helping our clients understand the importance of being a high performer in software delivery, and how this performance influences positive business outcomes. At the same time, we are trying to give people a better mental model of how software delivery works; often you will hear people using building analogies to explain software, using statements like “we build the foundations and then we scaffold the structure” and so on. Whilst these are useful ways to visualise the invisible, these statements are also somewhat misleading. Software development is very different to building houses in two important ways; it is both iterative in nature and a continuous long-term investment. Software is built (or compiled) every day from the very start of a project, and that continues through support until the time the software is finally retired, long after the “project” was supposedly completed. What happens if we ignore either of these concepts? Inability to iterate leads to an inability to deliver new features with confidence. And an inability to continuously invest in the software long term leads to exposure to ongoing risks such as security vulnerabilities.

[1] See research from book Accelerate by Nicole Forsgren et al  2018.

Ensono Stacks  is our investment in improving software delivery performance.

Ensono Stacks is an investment aimed at improving team velocity and efficiency. It is the foundation to providing continuous support and modernisation through our SRE Service. And it directly supports improving DORA metrics in multiple ways:

• Higher deployment frequency, through comprehensive templated independent CI / CD pipelines for a large and growing set of workloads across multiple environments in Azure and AWS.
• Reduced cycle time and change lead time, through proven code generators and pre-built packages for workloads built using JavaScript (Next.JS), Java (Spring Boot), C# (.NET) and Python
• Reduced  failed deployment recovery time, through embedded observability and fault tolerance baked in.
• Reduced change failure rate, through the implementation of automated QA practices across all levels of a workload being delivered against proven architectural patterns.

Ensono Stacks v2.5 represents a major milestone in our ongoing investment since v2 was released in 2022. There is so much we have covered in this release that we will be putting out a series of technical articles providing more detail, but the following section describe how Ensono Stacks v2.5 supports improving your software delivery performance.

Improving deployment frequency

Ensono Stacks v2.5 has added two new workload targets for provisioning infrastructure as code using Terraform templates using the Stacks CLI[1]:

• Data Platform on Azure
• Web Application on Azure

The Data Platform on Azure workload provisions a medallion data lake (ADLS) with pre-built bronze and silver layers of the data platform implemented using Azure Data Factory, Databricks, and Microsoft Fabric. The Data Platform workloads create a fully featured CI/CD pipeline across multiple environments.

The Web Application on Azure workload replaces the previous front-end infrastructure provisioning and has been completely rewritten to follow the micro-factory and developer native philosophy of Ensono Stacks v2[2]. As such, the Web Application on Azure workload in Stacks now fully embraces the value of the Nx[3] build system, which solves several front-end specific developer workflow issues such as automated dependency updates, which is a major area of complexity in front-end development using open-source packages.

Reducing cycle time and change lead time

To compliment the new Data Platform on Azure workload, Ensono Stacks now includes Python based development templates and packages to help build new data platform features (such data ingestion, data quality and curation etc) more quickly.

For web application workloads, Stacks extends the out of the box feature set found in Nx, providing additional Generators and Executors to cover common repeatable use cases in web application development. For example, Stacks has a REST client generator[4], which is used to accelerate the development of the client code required to consume a REST web API (such as a microservice).

One of the emerging front-end patterns of the past few years has been the adoption of micro front ends in web applications. Like micro-services, micro-front ends break down the feature set of an application into smaller independently deployable units that together provide an entire application. Microservices and micro-front ends contribute to reducing lead time by enabling parts of the application to be independently deployed. Stacks now supports the use of module federation[5] using Nx and Next.JS[6] to build and deploy micro front ends.

Ensono Stacks’ alignment to the micro-factory philosophy means that any developer can get value from Stacks, even if they don’t use Stacks to provision the infrastructure. Indeed, any JavaScript developer can get value from Stacks if they are not invested in Nx. Stacks also supports modernisation use cases for front end development, where JavaScript developers are aiming to modernise existing web applications (also supported in .NET service workloads).

Reducing failed deployment recovery time

Our automated testing practices (baked into Stacks CI/CD) now extend to infrastructure testing using Chef InSpec[7] and Checkov[8]. Infrastructure testing moves Stacks further into the operational world by providing pipelines that test for static code issues and compliance and configuration drift both during and after deployment. This ensures that a system’s configuration remains evergreen, reducing operational risks.

Reducing change failure rate

Support for Playwright[9] for functional end to end tests, including a Playwright Nx Generator. Playwright is a cross browser, cross platform, cross language framework for testing and has quickly established itself as an excellent choice for end-to-end testing. Its support in stacks sits alongside existing functional testing options in Stacks (Cypress, Selenium and Serenity).

The future roadmap

Ensono Stacks is an open-source project and in a future article we will publish its road map openly to community for feedback to help prioritisation of new features. Follow the plans for Stacks in the coming months ahead here.

See Ensono Stacks in action

---

[1] See https://github.com/Ensono/stacks-cli/releases for more information.

[2] See https://www.ensonodigital.com/blog/announcing-amido-stacks-v2-the-road-to-micro-factories for more information.

[3] See https://nx.dev/ for more information.

[4] See https://stacks.ensono.com/docs/getting_started/rest-client/ensono-stacks-rest-client for more information.

[5] See https://webpack.js.org/concepts/module-federation/ for more information.

[6] See https://nextjs.org/ for more information.

[7] See https://docs.chef.io/inspec/ for more information.

[8] See https://www.checkov.io/ for more information.

[9] See https://playwright.dev/ for more information.