Continuous delivery (CD) as an engineering practice is taking hold at enterprises everywhere. Most forward-looking app developers' efforts rely on CD to one extent or another. Typically, that is in the form of a functionally automated pipeline for code promotion and some test execution. Some amount of the delivery work, such as database changes, provisioning or configuration management tickets, production signoffs, etc., is still done manually. These forward-looking teams, therefore, have a CD pipeline that "works" reasonably well.
There is an old engineering adage that accurately describes the attitude many such teams have towards adopting CD: "First, make it work. Then, make it work well. Finally, make it work quickly and efficiently." Today, enterprises are getting through the first and second phases of that adage in their CD adoption efforts, but they are going to want to reach the third eventually-and that's where the difficulty lies. Organizations in this position should start planning for phase three now to avoid the expense and disruption of bringing it under control later down the line.
A Pipeline of Pipelines
Enterprises attempting to transform their app delivery approaches typically rely on team-level efforts. As a result, they usually have app delivery pipelines in different areas of the business. Many of those current efforts have a very limited scope, only focusing on the basic functional tasks of the specific technical environments of the specific application system they support. Sometimes the focus may even just be on a subset of those environments. Furthermore, the pipelines are often duplicative of each other across teams-even if the technology stacks are the same. There is nothing but manual effort and spreadsheets coordinating the pipelines.
This is a result of teams' natural, but narrow, focus on their functional needs. The narrow focus can create architectural problems when it comes to helping adjacent delivery pipelines-especially if the tech stacks among the adjacent teams are different. That is because most team-level tools do not support the variety of tech stacks present in many enterprises. As a result, these function-focused automated pipelines still rely on manual management techniques for higher-level needs, such as cross-app dependency management. These enterprise needs are less technically focused or have other, larger business aspects that are beyond the scope of a team's responsibility-even if the team's activities impact those needs.
As development teams build out newer applications that expand to become critical pieces of enterprise software infrastructure, they discover that they now need something to manage their "pipeline of pipelines." No matter how consistently the involved teams' individual pipelines work, their narrow focus limits visibility and constrains their ability to effectively manage complexity for the business stakeholders. That blinds business stakeholders to the progress of key features and defects and is exacerbated when there are dependent projects. Existing data reported by team-level tools does not help (and may even hinder) coordination, security, quality, or compliance efforts, because the data resides in so many formats and tools across the various teams that it is impossible to correlate.
Enterprise-Grade Continuous Delivery Solutions
So, how do enterprises progress from scattered CD pipelines that merely "work" to CD pipelines that "work quickly and efficiently" at the scale they require? They switch to a model-driven approach that enables them to leverage the functional effectiveness of team-level efforts and, without throwing those away, thread them into a coherent and manageable whole. These models ? a hallmark of enterprise-grade CD tools ? enable enterprises to gain a clear, end-to-end understanding of complex value streams at both the technical "works" level and the management "works quickly and efficiently" level.
A model-driven approach to bringing disparate team efforts together:
- Eases coordination among dependencies by supporting heterogeneity in tools and team preferences and supporting the breadth of enterprise technology equally (containers, cloud, platforms, legacy distributed, mainframe)
- Increases visibility by providing a broad framework that collects data (both statistical and business-stakeholder relevant, e.g. feature/defect progress, etc.) for coherent reporting to the business and management
- Improves security by providing a consistent framework for enterprise security and compliance concerns, managed consistently for all teams with minimal duplication
The emerging awareness that CD requires different or additional tools to manage the complexity in an enterprise context is a natural outcome of the constantly evolving modernization of software delivery practices. It is an example of why CD practitioners and evangelists talk about the adoption of such practices as a "journey". With that journey will come learnings that shift team managers from being excited that something works "well" to an urgency toward taking the next step on their journey to make them "work quickly and efficiently."
