Reference Architecture

• 1: Views and Viewpoints
• 1.1: End Customer
• 1.2: CEO
• 1.3: CFO
• 1.4: CTO
• 1.5: CISO
• 1.6: Marketing Director
• 1.7: Sales Director
• 1.8: Brand Manager
• 1.9: Head of Legal
• 1.10: IP Lawyer
• 1.11: Product Manager
• 1.12: Delivery Manager
• 1.13: Technical Design Authority
• 1.14: Software Developer
• 1.15: Data Scientist
• 1.16: Machine Learning Engineer
• 1.17: Security Engineer
• 1.18: Auditor
• 1.19: Compliance Officer
• 2: Drivers and Constraints
• 3: Capabilities
• 4: Assessment of Readiness

1 - Views and Viewpoints

“Simply put, a view is what you see, and a viewpoint is where you are looking from.”

— The Open Group Architecture Framework

Continuous Delivery is a methodology that helps optimize the process of one group of people creating value for another group of people. To implement the methodology successfully, it is first necessary to understand what everyone in the chain needs, and to communicate to all of them that you understand their needs and have an easily explainable way of making their lives easier.

In this section, we look at the process from the perspective of each of the key stakeholders, to understand how this impacts them and to spell out the value added from their perspective.

1.1 - End Customer

Viewpoint

The End Customer is the reason that this business exists. At the point of sale, the Customer has a problem and we offer a solution that can address that problem in such a way as to release sufficient value to make it viable to maintain that solution for the lifetime of the product.

Customers may have a very different appetite for new solutions. Those towards the Early-adopter end of the distribution will be excited by the opportunity to collaborate iteratively using the benefits of Continuous Delivery to discover brand new solutions to their problems. Those towards the opposite end of the distribution will only be comfortable purchasing mature solutions that many other customers are already using successfully and will benefit only marginally from the use of Continuous Delivery.

Customers are always very busy, focusing on the demands of servicing their business, despite the pressures of the pain points that they experience. As such, they have a limited attention span and will need to see positive outcomes that have a direct effect upon their bottom line as rapidly as possible or they will lose interest in the product discovery process.

View

As a customer, I have a problem that I need to be solved for me, at a price that is less than the cost it is currently causing me. I may not initially be aware of the true nature of this problem, but I almost certainly know the pain it is causing me. I may not be able to describe the solution I need and will probably ask for things that are familiar, but which don’t effectively address my real problem.

Your potential solution sounds interesting, but I need something that I can use in my business today to help create additional value for my customers. I’m not really interested in a demo about pet stores, I need to be able to apply your solution to my data in the real world before I can say if it really solves my problem.

I have people coming in here every week, offering me ‘silver bullet’ solutions but my real problem isn’t werewolves and I frankly don’t trust anything you say. Prove that you can solve this in a month any you have my attention.

Value Add from Continuous Delivery

• Run small, focused experiments in live production environments
• Iterate rapidly to discover features that add real value
• Ability to experiment safely in production
• Ability to react quickly to unexpected issues
• Ability to fail fast and move on if no real value identified

1.2 - CEO

Viewpoint

The CEO is responsible for scaling the company and driving profitability. They are ultimately responsible for shaping the business model and the target operating model of the company. They are the primary point of communication between the executive team and the board of directors and will often be the public face of the business. The CEO has the most influence over the performance of the business.

View

As CEO, I need to tune the running of the business so that we are producing products that solve important customer problems, and that we are able to do so faster and more effectively than our competition. I want to demonstrate product-market fit within a given resource window, so that I can make the decision to scale that product or pivot to something else. I need us to be able to learn as quickly as possible without making mistakes that will kill the company. I want us to produce quality products, so that we can minimize churn and grow virally in the market.

Value Add from Continuous Delivery

• Being able to get from an idea for a product, to having that idea be testable with real customers, in the shortest possible time
• Being able to learn rapidly by experimentation with the minimum of up-front investment
• Being able to tightly control risks through good governance and automation
• Being able to safely empower my team to do amazing things, whilst retaining the culture I wish to promote
• Being able to react quickly to changing market conditions
• Being able to put out fires quickly and safely, enabling us to enhance rather than degrade reputation

1.3 - CFO

Viewpoint

The CFO is responsible for all of the financial structure of the organization, and for ensuring compliance with applicable financial legislation.

View

As CFO, I need to ensure that money is being used efficiently to further the goals of the business. I need to collect regular evidence that we are not spending excessively and I need to be comfortable that we are not incurring significant financial risk.

Value Add from Continuous Delivery

• Ability to build financial models to predict costs of development and release activities
• Ability to track actual spends against the model at fine granularity
• Ability to embed financial compliance tasks in release process where needed
• Ability to link expenditure to business value created
• Standard approach to controlling Cloud resource spending
• High quality metrics and audit trail

1.4 - CTO

Viewpoint

The CTO is ultimately responsible for all engineering activities. They are the final owner of all technical debt and play a critical role in managing technology risk.

View

As CTO, I need to be able to ensure consistent engineering across all our product lines. My role is to ensure that we are able to use technology to accelerate the delivery of business products to the market. I need to be able to review all architecture and design decisions. I want to minimize the level of technical debt held by the organization. I want to be able to scale my team with minimal overhead so that we can continue to meet the needs of the business. I want to ensure that we are building defensible assets, so that we can add value to the business.

Value Add from Continuous Delivery

• Reduced time to market
• Reduced time to recover from failures
• Consistent engineering process across all deliveries
• Standard approach makes it easier to scale teams
• All engineering activity goes through approved governance process
• Technical debt visible and repeatably testable

1.5 - CISO

Viewpoint

The CISO is responsible for ensuring that the organization and its customers’ data remain secure, and that the organization remains compliant with applicable security legislation.

View

As CISO, I need to be able to ensure that everything that we produce, conforms to our security policy. I need to maintain a culture of personal accountability for security, across the organization. I must be sure that we have the ability to recover rapidly from a disaster scenario such as the loss of a data center. I need to be informed immediately of any intrusions into our systems and must be able to implement an effective incident response in a timely manner. I need the ability to maintain audit trails of all activity across sensitive areas of the system and to be able to preserve forensic records to support potential legal action.

Value Add from Continuous Delivery

• Ability to shift-left on security, embedding security concerns into design, implementation and testing phases
• Ability to automate security compliance testing and apply it to every build
• Ability to react to Zero Day issues and release patches in hours
• Ability to monitor asset security quality on an ongoing basis
• Ability to apply security policy to all build and release activities consistently
• Ability to audit and monitor all release activity
• Leverage the automated CI/CD process to rebuild rapidly following a disaster

1.6 - Marketing Director

Viewpoint

The Marketing Director is responsible for the overall marketing strategy for all product lines. They span multiple products and are concerned with the alignment of market positioning, messaging and go-to-market plans across all products. They set the market differentiation approach for the business and ensure alignment between marketing activities and sales channels.

View

As Marketing Director, I want to be able to ensure that our go-to-market plans are practical and achievable. I want to be comfortable that all our product lines fit with a consistent marketing strategy, providing a coherent set of offerings to the market and offering many opportunities for up-selling and cross-selling. I need to have good data about our customers that I can analyze across products in a reliable way that gives me useful information.

Value Add from Continuous Delivery

• Being able to verify consistency across products
• Being able to standardize and re-use data collection and analysis tools
• Being able to react quickly to changing market conditions
• Being able to react quickly to unexpected failures and demonstrate mature process for managing risk

1.7 - Sales Director

Viewpoint

The Sales Director defines and executes the sales strategy for the organization, setting the direction for various sales teams across all sales channels.

View

As a Sales Director, I need to be able to help customers understand the value of the product that we make. I need to be able to ensure an ongoing pipeline of new sales prospects and to maintain good customer retention, minimizing the cost of acquisition and retention. I am keen for us to have products that are so compelling that our customers help to sell them to others because they like them so much.

I need the customer to understand that we understand their problems and have good solutions to mitigate the risks associated.

I need to understand when something that we are working on will be available to customers, so that I can be selling this in a timely manner. I need to be able to resolve unanticipated customer problems rapidly and effectively.

Value Add from Continuous Delivery

• Customer-driven product creation
• The ability to discover good products, with the customer
• High quality metrics, to understand customer behaviors and preferences
• The ability to react quickly to customer requests and problems

1.8 - Brand Manager

Viewpoint

The Brand Manager ensures that all product lines and services align to the brand values of the organization. They coordinate marketing and product activities in line with the overarching strategy.

View

As a Brand Manager, I need to make sure that all of our products align to our brand. I must be able to enforce consistency across all our product lines, so that our customers recognize and understand our brand and how our product offerings fit within that, I need to ensure that everything that we publish aligns to the values and ethics of the organization. I would like to be able to verify that all assets that we produce conform to our style guide and branding guidelines.

Value Add from Continuous Delivery

• Ability to incorporate brand values during the design and development phases
• Ability to standardize process across multiple product lines
• Ability to automate checks for brand compliance
• Ability to integrate values and ethics checks into release processes

1.9 - Head of Legal

Viewpoint

The Head of Legal manages the corporate legal strategy to protect the organization and to ensure corporate compliance with legal requirements in appropriate jurisdictions. They manage interactions with government bodies and regulators. They also advise the board and the executive team on legal matters relating to the operation of the company.

View

As Head of Legal, I need to be able to ensure that the organization is complying with statutory requirements. I must be able to facilitate internal audits and compliance checks. I must be made aware of any incidents that may result in legal risk to the organization. I want my team to be able to manage and protect the assets of the organization.

Value Add from Continuous Delivery

• Automated compliance processes
• Audit trail
• Forensic data management
• Incident detection and reporting

1.10 - IP Lawyer

Viewpoint

The IP Lawyer is concerned with protecting intellectual property from criminal attack, abuse and trademark violation. They manage trademarks, patents, copyrights and other trade secrets. They may be involved in licensing of IP to other organizations, franchising, distribution or the sale or transfer of technology.

View

As an IP Lawyer, I need to be able to assist the organization in protecting the value of its IP. I must be able to ensure that access to IP remains only with authorized parties, both inside and outside the organization.

I need to know that we are only sharing what we intend to share with our customers and partners and that we are not unintentionally leaking trade secrets to competitors. I need to be informed of attacks upon our IP, such as theft or piracy. I need to know about abuses of our trademarks and copyright.

I need to be sure that we are not unintentionally abusing the rights of others. I need to understand the implications of the licenses of every Open Source dependency. I need to understand that our customers are conforming to the terms of the licenses in respect to products that we provide to them, and that we are conforming to the terms of any licenses imposed upon us by our suppliers.

Value Add from Continuous Delivery

• Automated management of the content of release distributions
• Control over access to source assets
• Control over access to production assets
• Audit trail of access to protected information
• Ability to scan all release activities for compliance
• License scanning on dependency tree
• License management on dependency tree
• Implementation of license management flowing to customers

1.11 - Product Manager

Viewpoint

The Product Manager is empowered to create products. They are responsible for evaluating opportunities, deciding what is worth building and are accountable for the success or failure of a product. Product Managers are not people managers and not responsible for the management of design or engineering teams. They are experts in the customer domain who fully understand the business model and operating model of their company and are focused upon applying technology to create products in the target market.

View

As a Product Manager, I want to be able to run experiments with customers, so that I can evidence product-market fit, or lack thereof. I need my team to be focused upon getting experiments in front of customers, capturing valuable metrics and learning from the results. I have a limited budget, both in resources, and in the amount of customer attention that I can hope to capture, so I need to iterate fast and effectively to maximize the chances of discovering a hit product.

Value Add from Continuous Delivery

• Being able to get from an idea for a product, to having that idea be testable with real customers, in the shortest possible time
• Being able to learn rapidly by experimentation with the minimum of up-front investment
• Being able to tightly control risks through good governance and automation
• Being able to safely empower my team to do amazing things
• Being able to react instantly to new information from customers
• Being able to recover rapidly from unexpected situations without causing unacceptable levels of risk

1.12 - Delivery Manager

Viewpoint

The Delivery Manager’s role is supporting the scaling process. They are responsible for knocking down barriers and getting approvals in place to allow the team to deliver product at pace. They coordinate dependencies across teams and help coach Agile process and rituals.

View

As a Delivery Manager, I want to be able to optimize my resource usage and delivery time, so that I can meet my Objectives and Key Results. I want to be sure that business process is supporting my team and not getting in the way of them delivering product to customers. I want knowledge to scale easily across all my teams so I can grow as fast as the business needs for the product to attain market leadership. I want a clear picture of the state of my product at any moment in time, so I can manage the delivery effectively.

Value Add from Continuous Delivery

• Being able to automate large parts of the business governance process to avoid manual decision-making and sign-off delays
• Having standard processes for all parts of the product release, so teams always know what they are doing
• Having great observability, so it is always clear what state the product is currently in
• Having processes that can be scaled at minimal overhead, so the business can scale at the necessary pace
• Having the business and engineering teams aligned so that approvals to go live are simple and trustworthy
• Being able to recover rapidly from the unexpected

1.13 - Technical Design Authority

Viewpoint

The Technical Design Authority is responsible for the architecture of all products within the company. The TDA is typically a jointly held role comprised of a number of architects who are responsible for ensuring that non-functional concerns such as safety, privacy and scalability are being considered as part of engineering deliveries, and that economies of scale are accessible to the business through the efficient re-use of technologies, services and patterns, across products. This architecture team is often responsible for translating between business and engineering domains and liaises between product and enterprise governance teams.

View

As Technical Design Authority, we want to have a consistent suite of technologies across the enterprise continuum, so that we can have consistent processes and minimize cost of ownership. We want to be able to easily review architectural designs to ensure that non-functional requirements are being considered appropriately. We need to be able to check that engineering deliveries are in compliance with the architecture requirements.

Value Add from Continuous Delivery

• Being able to ensure that designs include all functional and non-functional requirements
• Being able to validate that releases meet functional and non-functional requirements
• Simplifying the process of re-use for components and services
• Being able to decouple dependencies whilst increasing re-use
• Being able to provide automated audit trails to enterprise governance teams

1.14 - Software Developer

Viewpoint

Software Developer roles typically span a wide range of engineering specialties. Generically, a Software Developer is concerned with transforming specific user stories into deployable assets using conventional (procedural or declarative) software techniques.

View

As a Software Developer, I want to be able to put my feature into production so that I can complete this User Story in the current sprint. I want my code to meet the acceptance tests so that I can be confident that it does what is required of it. I want to minimize the amount of complexity inherent in my code so that I can ensure that it is reliable and maintainable.

Value Add from Continuous Delivery

• Reduced lead times in delivering new capabilities
• Reduced time to restore from failure
• Reduced change failure rates
• Increased deployment frequency
• Automated testing
• Automated deployment

1.15 - Data Scientist

Viewpoint

A Data Scientist is responsible for mining data sources to extract subsets of the data that can be used to create useful information based upon statistical or machine learning techniques.

View

As a Data Scientist, I want to be able to apply mathematical techniques efficiently to large volumes of data. I need to be able to access large stores of structured or unstructured data, clean, validate and separate the data into versioned training and testing data sets.

I need to be able to inspect this data for inherent bias and process it to maintain privacy. I need to be able to train models or run regressions.

As part of the training process, I need to be able to test the performance of my models against a target threshold. I would also like to evaluate the resulting model against our corporate values to ensure fairness and freedom from bias.

I must be able to demonstrate an audit trail of my training activities to regulators to support compliance activities.

Value Add from Continuous Delivery

• Reduced lead times in delivering new capabilities
• Increased deployment frequency
• Reduced risk to the organization
• Path to regulatory compliance
• Standard ways of working

1.16 - Machine Learning Engineer

Viewpoint

Machine Learning Engineers are responsible for taking data and math-centric assets like ML models and integrating them into production-ready products. The role encompasses all the challenges of conventional asset development but must also resolve the issues of versioning very large data sets and efficiently moving large volumes of data onto high-performance computing infrastructure for training operations. Typically, ML models are high risk assets as they use large volumes of sensitive data to create assets that undertake decision-making activities, hence there are increased governance and compliance requirements that must be met to maintain safety and privacy.

View

As a Machine Learning Engineer, I want to be able to be able to manage machine learning models safely and reliably in production. I need to be able to access large stores of structured or unstructured data, clean, validate and separate the data into versioned training and testing data sets.

I need to be able to transfer this data to a Cloud facility or dedicated high-performance computing environment where I can leverage large numbers of GPU or TPU resources to process the data and extract trained models.

I would like to be able to version all training data and trained models so that I can run iterative comparisons and regression tests on newly trained models.

As part of the training process, I need to be able to perform integration and acceptance testing on the model produced.

I must be able to maintain a forensic audit trail of all training and deployment activities to support compliance activities. I need models to integrate seamlessly into the asset management and release process for the product within which they are a part.

I must be able to efficiently manage the utilization of expensive compute resources.

Value Add from Continuous Delivery

• Minimizing risk associated with ML
• Reduced lead times in delivering new capabilities
• Reduced time to restore from failure
• Reduced change failure rates
• Increased deployment frequency
• Automated testing
• Automated deployment
• Regulatory compliance

1.17 - Security Engineer

Viewpoint

Security Engineers are responsible for ensuring that product is produced and maintained in a way that is secure and facilitates ongoing monitoring and intrusion detection.

View

As a Security Engineer, I need to be able to apply best known methods for security to the implementation of product features. I must be able to test all application code against a defined set of standards. I must be able to understand the levels of risk present within our software supply chain.

I need to be able to continuously scan all our assets for newly evolving vulnerabilities that occur within our dependency tree. I must be able to monitor all production environments for signs of attack or intrusion.

Should an incident occur, I must be able to support the response and preserve forensic data, as required. I need to have control over who can access and change specific assets and must have an audit trail of all such changes.

I need to be able to apply security patches in the shortest possible time following the discovery of a zero day vulnerability.

Value Add from Continuous Delivery

• Reduced lead times in delivering new capabilities
• Reduced time to restore from failure
• Reduced change failure rates
• Increased deployment frequency
• Automated testing
• Automated deployment
• Ongoing asset inspection

1.18 - Auditor

Viewpoint

An Internal Auditor is typically responsible for testing internal governance controls or investigating potential fraud or other compliance violation.

View

As an Auditor, I want to be able to validate the operation of governance controls. I need to be able to review business processes. I need to evaluate risk management procedures. I need to ensure that we are compliant with all legal and regulatory requirements.

Value Add from Continuous Delivery

• Existence of automated processes for release of assets to production
• Existence of audit trails for change and release of assets
• Existence of governance processes for testing delivery against non-technical concerns

1.19 - Compliance Officer

Viewpoint

A Compliance Officer is responsible for reviewing policies and procedures to ensure that the organization meets regulatory requirements. They carry out compliance audits and facilitate the remediation of any issues uncovered.

View

As a Compliance Officer, I need visibility of all policies, processes and procedures. I must be able to audit all regulated activities.

Value Add from Continuous Delivery

• Existence of automated processes for release of assets to production
• Existence of audit trails for change and release of assets
• Existence of governance processes for regulated activities

2 - Drivers and Constraints

“To truly motivate others

1. discover what their motives, desires & drivers are

2. genuinely connect with and support them from the heart.”

   — Rasheed Ogunlaru

In this section, we get to grips with one of the most common misconceptions about Continuous Delivery, which is to think of it as an engineering approach to optimize software development.

In reality, software rarely, if ever, exists for its own sake. We build software to solve a problem in the physical world, generally in the form of a product that is being created by an organization.

As we have already seen from the previous section, there are always many stakeholders involved in the development of a product, each with their own views associated. Any of these stakeholders may be able to legitimately block the release of a product, based upon concerns raised from their viewpoint.

By treating Continuous Delivery as an engineering discipline, we make the mistake of optimizing for the views of the CTO, or the Software Engineers. For many, this appears to be the path of least resistance because they are attempting to implement Continuous Delivery from within an engineering department. In practice, this is nearly always a dead end. The engineering team exists to serve the needs of the organization, so optimizing for those viewpoints alone can quickly take you outside the context of the real problem at hand and results in an inevitable battle with all the other stakeholders. ‘Winning’ that battle can destroy the organization, and losing it destroys confidence in Continuous Delivery as a methodology for success. It is advisable never to get into this dilemma.

Continuous Delivery, therefore, is best understood as a methodology for accelerating the delivery of product, in the face of all of these conflicting concerns.

To understand how to do this, we must first be able to reconcile all the views and viewpoints from the previous section. We do this by setting out the overarching set of drivers and constraints for the product line which we will use subsequently to resolve any conflicts.

In the start-up world, where Continuous Delivery was born, this process is trivial to the point of rarely being worth a mention. The north star is solving the customer’s problem in such a way as to demonstrate strong product-market fit. This driver is paramount, since if there is no product-market fit, there is no scaling and if there is no scaling then there is no exit, no payoff to everyone involved, and shortly thereafter, no company. The primary constraint is having very limited time and money with which to do this.

The reason why this is rarely explicitly discussed as the core of the methodology, is that in a startup environment, either everyone’s incentives are already aligned enough to naturally optimize for product delivery, or the business doesn’t last long enough for anyone to have conversations about it. Those who survive and thrive are the ones that allowed the customer’s behaviors to drive their product development process.

For all other classes of organization, however, there is a much bigger challenge that must be resolved.

In a start-up, all of your team are primarily motivated by the value of their equity stake in the product. The product has to succeed or they won’t be rewarded, so there is very strong alignment between the outcomes of the business, the customer and the team.

Contrast this with the situation where your team are recompensed based upon salary and bonus. In the short to medium term, their salary will continue to be paid regardless of the outcome of the product and their bonus is most likely linked to an annual, strategic plan for their department. Both of these incentives are entirely disconnected from the behavior of the customer. In these scenarios, team alignment rapidly diverges from the goals of the business and becomes either centered upon individual progression in competition with other team members, or departmental competition over conflicting role-based viewpoints.

To realize the benefits of Continuous Delivery within any organization that is not an early-stage start-up, your primary challenge will be in creating an incentive structure that is artificially re-aligned to the needs of the customer and the product, despite constant, natural pressure to diverge from this. It is not advisable to pursue a Continuous Delivery approach if you are unable to change the incentive structure of the organization. The outcome of attempting this path is that many additional barriers will be encountered, many of which can be traced back to “my bonus depends upon us NOT being able to achieve this”.

To build an effective Continuous Delivery process, you need to find outcomes that are aligned to customer needs, and then align incentives to these outcomes. By working through the positive views from each viewpoint, you can find a set of outcomes to work towards, which reflect the individual goals of each stakeholder and which can be expressed as overarching drivers for the team. Similarly, you can take the negative views from each viewpoint and translate these into constraints that must be worked away from.

Be aware that in a large organization, there will be conflicting drivers and constraints that must be explicitly reconciled and prioritized so that the team is able to progress autonomously without falling back into internecine fighting. For example, the legal and compliance teams might prefer that you didn’t do anything new, as this might introduce new and hard to quantify risk to the organization, but the process of discovering product-market fit requires than you not just do new things, but do them wrong until such time as you have acquired enough information to know how to do them right. Resolving this in a mature organization requires calm leadership and lots of negotiation. Seek boundary conditions and work inward from extremes. There will be examples of legislative compliance that are compulsory at scale, but which can be be mitigated whilst experimenting with individual customers, for instance. It is vital that you make it clear that you understand the concerns of each viewpoint, but then set these concerns in the context of the organizational and customer goals.

In the previous section, we introduced the idea of value add from Continuous Delivery, from the perspective of each viewpoint. This is fundamental to successfully implementing Continuous Delivery across the organization. To get the end-to-end Continuous Delivery process running as a finely tuned machine, it will be necessary to change the processes that exist within various departments and functions currently. This is typically a negotiation where the overarching drivers of the organization are insufficient to catalyze change. Instead, it becomes important to sell the individual benefits of the methodology in addressing the needs and concerns of that team or function. This must be done sensitively. Many of the benefits of Continuous Delivery are realized through increased automation, increasing quality, consistency and repeatability, but teams that have previously done the majority of their work manually will tend to see the prospect of automation as a threat to their jobs, or to their status as people managers. It is necessary, therefore, to show how increasing growth will inevitably lead to inability to stay on top of manual workloads, and hence carefully evangelize the idea of automation as freeing people up to do more important work with higher value add.

A pattern will emerge as you progress on this journey. Teams typically evolve a risk management approach that involves adding increasing levels of manual compliance activities in a vain attempt to prevent further risk. Eventually this hits a point of diminishing returns and ability to grow further, stalls. Success in Continuous Delivery requires that you invert the mental model to one where risk is inevitable and unavoidable, but risk mitigation derives from being able to react so rapidly to the unexpected that impact of that risk is minimized to the point of negligibility. This means working to a process where instead of having many teams manually inspecting deliverables after the fact, to try to judge if they are safe to release, you instead have those teams working up front to provide sufficient automated testing and validation that you are able to reverse out any failures so fast that the impact is insignificant.

The engine that takes your products successfully to market are thus just a series of pipelines that provide sufficient automated validation to create confidence in the quality of the product release. What is in each of those pipelines? Well, you already know that, it’s the sum of all the concerns raised within the views and viewpoints section, reconciled against the driving needs of the customer.

3 - Capabilities

“To say ‘I did’, you must start with ‘I am’, ‘I can’, and ‘I will’.”

— Kurian Mathew Tharakan

Before embarking upon the transformation to Continuous Delivery, it may be advisable to carry out a capability assessment, in order to understand the scope of the changes necessary and the sequence in which you should tackle these activities.

It helps to keep in mind that in many cases, you are asking your team to turn their world inside out. They feel that they have a really strong grasp upon the intricacies of a given field, and you are going to ask them to see it again, from a new angle, as if for the first time. Some people will love that opportunity and leap in with glee, but many will be scared, suspicious and all too keen to flee back to familiar old habits at the first excuse. Because of this, it is generally unwise to try and perform an organization-wide transformation to Continuous Delivery as a ‘big bang’ rollout as you will risk triggering ‘corporate anti-bodies’ into play to return the status quo by undermining the change.

Instead, you might consider spinning up a new org unit, with the remit of creating a new product line, or entering a new market segment. This should then be staffed with an executive team who are fully bought into Continuous Delivery as an approach and who are empowered to act as scouts, breaking new ground and finding the path for the rest of the organization to follow, subsequently. This then gives you the freedom to set up new incentive structures for staff within this org unit which are better aligned to the methodology and the product goals. It is recommended to use this opportunity to bring in some new team members who have prior Continuous Delivery experience and set them up as mentors to the rest of the team. You can then start to bring across small numbers of staff from the parent organization and retrain them as they join the new unit. The first and most important goal is to create a culture within this new org unit that is properly aligned to the methodology, and to clearly weed out behaviors that tend to regress to old ways of thinking.

Let’s look at an example in order to better understand some of the patterns of change that are needed:

Many organizations are familiar with a way of working that involves passing a set of requirements to a development team, then accepting back a deliverable which the developers assert is ‘finished’. This candidate product is then passed around a number of departments to perform manual activities to ‘find things wrong with it’. This typically results in an iterative period of remediation and new inspections until enough people feel confident in the product to release it to customers. This rear-end loaded risk management approach adds weeks or months of delays to each release, and still cannot catch everything that could go wrong. Worse, it leaves the customer entirely out of the loop.

In practice, this approach is so slow and expensive that shortcuts are put in place to work around it. Here is a common example. The legal team managing the IP inherent in your product need to understand what components and libraries are being used to implement the product. If those libraries are commercial, does the business have appropriate licensing agreements in place to allow this usage? If the libraries are Open Source, are they licensed in such a way as to permit commercial use, or do they contain clauses that might require you to Open Source your own IP as a result of using them? This requires someone on the development team to trawl through every dependency (and all of its dependencies) to compile a list of applicable licenses. Then someone on the legal team needs to review those licenses and sign off on them as appropriate and properly managed. Run rear-loaded, this is such a laborious and mind-numbing process that it becomes a box-ticking activity that gets done once during the lifetime of the product and then everyone just pretends that new dependencies are not being added daily as the product continues to evolve.

To re-implement this as a Continuous Delivery capability, you have to invert the process and front-load it. The legal team needs to develop policy rules that generically describe classes of licenses to accept or block. The engineering team is then required to provide a Software Bill Of Materials that includes licensing information for every component, against every release. The final part of the capability is a release pipeline activity that scans the SBOM for policy violations. In this way, license management becomes a development activity because it is a prerequisite to get your code through the build process. Your legal team are then restructured to focus on rapid handling of exception processes (dealing with new license types, commercial license management etc.) so that developers can get what they need to build product, at the pace that they need to meet the business drivers.

Once you see this pattern, you will recognize it everywhere in large organizations and the solution is always to find those rear-loaded governance processes and front-load them with automation to free people up to handle the messy edge cases that will inevitably occur.

Before you rush into transformation, however, there is another key element that needs to be in place as early as possible.

Continuous Delivery replaces the ‘inevitably futile culture of expending significant effort to try and stop bad things from ever happening’ with a more pragmatic expectation that ’the unanticipated will always happen’ and the ability to react to it extremely rapidly and effectively. This requires that you put in place processes to react to failures in production as a priority, and that you transition away from a ‘blame culture’ to a ‘continuous learning’ culture where each failure is treated as a positive learning experience to help you improve your systems.

The end goal is to have automated infrastructure and deployment processes that can detect failures and reverse out changes to a last known good condition. If you are starting with a greenfield project, you can jump straight to this point by selecting appropriate tooling, but for most organizations, it will be necessary to develop a series of transitional architectures with manual intervention processes as a roadmap to reaching this goal. Do this early in the process and practice it regularly so that you can implement it smoothly when things do go wrong. The better you prepare in this area, the smoother the rest of your transition to Continuous Delivery will feel, because you have safety nets in place for every change.

An important part of your business change process will be to create and operate incident response teams that are supported with resources from each of the Viewpoints previously discussed. This has significant cultural as well as safety benefits. In your legacy operating model, it is very easy for ‘us and them’ divides to arise. Development teams are typically incentivized to improve quality and are harmed by their own actions if quality drops, but ‘gatekeeping’ teams performing manual reviews on the product rarely have skin in the game so can become perceived as ‘armchair referees’ rather than team players. It is useful therefore to have your supporting business teams embedded within the development process, creating policy to automate governance; AND to have those same individuals on incident response teams, so that they get first hand experience of managing potential policy failures. This creates a much more collegiate environment where everyone has similar skin in the game and everyone gets a better learning experience about what matters most.

It is advisable to temper your ambitions initially and instead create a capability review based upon realistic and reasonable expectations. Teams will need a lot of mentoring as they transition to new ways of working, so prioritize those business functions that perform the most critical governance activities for your product and start there, with a roadmap for other functions to transition as you get more practiced in operation. Remember that a key tenet of Continuous Delivery is creating an environment in which you can make lots of small mistakes that teach you what you need to know to succeed, but which also protects you from making a large mistake that can kill you. One of your first tasks will be to get people used to making mistakes and being praised for turning them into valuable knowledge. If a blame culture creeps back into your new org unit, things are likely to become political and your whole mission may be sabotaged. Plan your capability rollout in bite-sized chunks that allow your executive team to mentor and lead at a comfortable pace initially, until you have sufficient good habits in place to turn up the wick and really start to realize the productivity gains of Continuous Delivery.

As your new org unit becomes more practiced, start to transition more staff across from the parent organization and scale up, making sure to train people in the culture of the new unit as well as the process.

4 - Assessment of Readiness

“Action springs not from thought, but from a readiness for responsibility.”

— G. M. Trevelyan

How do you know if you are ready to start your transition to Continuous Delivery?

• Well, first and foremost, you must have secured robust commitment at board and executive level, with a clear remit for significant business change. Your management team should understand that they are changing the target operating model of the business and be fully bought into the extended journey that this will entail.

• You need to have secured a few key practitioners who will be your anchor through the inevitable confusion and doubt as you roll out new process. They will be the calm voices that guide everyone to the destination.

• You will have a reasonable understanding of your capability and have set expectations appropriately. You are in training to get to peak fitness to run the race that comes later. You don’t get to skip the training phase with a montage and some ’80s rock music. Your next step is to get the whole team fit for action and that will involve some sweat and pain.

• You have prepared some metrics to help you evaluate your progress. The DORA metrics are a good place to start. Don’t pick vanity metrics as they won’t help you.

• Finally, you have communicated carefully and positively with all staff. Your activity must be understood clearly as the path to more growth and prosperity for all. Rumours of secret plots to replace all staff with automation are all too easy to start and very hard to refute when you are building a lot of automation for unexplained reasons…

If you have these in place, you are ready to press ‘Go!’