Enterprise Software Development: DevOps Evolution Model, CI/CD Pipeline Modeling, and Software Factory Benefits

Enterprise software development is complex; only companies that can quickly deliver high‑quality software to respond to market changes can dominate in the digital age.

There is no magic potion for achieving the required level of business agility. It requires a shift from traditional waterfall thinking to a lean‑agile mindset with relevant principles and practices.

Scaled Agile Framework (SAFe) provides guidance for transforming IT organizations, outlining seven core capabilities needed for success in the digital era: organizational agility, lean portfolio management, enterprise solution delivery, agile product delivery, team and technical agility, continuous learning culture, and lean‑agile leadership. Success still depends on diligent execution, ideally with the help of a SAFe program consultant.

Leadership involvement, consistency, and systems thinking are key success factors for transformation. Two useful models and advice on combining them with the Software Factory method are presented to improve DevOps implementation and enhance business agility.

DevOps Evolution Model

As Peter Senge described in *The Fifth Discipline*, teams and organizations need a shared mental model to reach consensus on problems and collaborate on solutions. To illustrate this, the author created a DevOps Evolution Model during training sessions to explain how teams progress on their DevOps journey.

The model shows how moving unfinished work leftward shortens delivery time and feedback cycles. Unfinished work includes testing, security checks, audits, documentation, open‑source legal assessments, and compliance checks that occur after a feature or story is marked "done".

Left‑shifting unfinished work enables faster feedback, more usable product releases, and quicker defect fixes, which in turn accelerates the process, improves quality, and allows more frequent releases that respond rapidly to demand changes.

Figure 1: The DevOps Evolution Model covers four main stages of the DevOps journey and visually shows how an organization matures from an immature to a more advanced model.

CI/CD Pipeline Model

The Continuous Integration/Continuous Delivery (CI/CD) model was derived from the author’s SAFe DevOps training and subsequent workshops. It models the end‑to‑end pipeline at the process level, diving into detailed CI/CD stages and related build and integration activities. In complex enterprise environments, many process problems stem directly from immature CI/CD pipelines.

Creating the model requires gathering all stakeholders to map the entire pipeline (build, integrate, deploy, etc.) as nodes (components) and edges (relationships). Teams often assume they already know their end‑to‑end pipeline, but in practice they rarely have a complete view.

The CI/CD pipeline model provides a global perspective. In large solutions, no single person can understand the full end‑to‑end flow; by assembling the right people, sub‑optimal local optimizations become visible, allowing focus on efficient end‑to‑end improvements.

For example, teams may claim they build and deploy several times a day, when in fact they are repeatedly building and deploying the same code or component.

The key issue in CI/CD improvement is not the number of pipeline runs but the time it takes for code to move from writing to a production stage. This is the most important question to ask for each contribution.

Shortening delivery time improves quality because defective components can cause a domino effect, delaying dependent work. Discovering defects late in the development cycle forces shortcuts or workarounds to stay on schedule, reducing quality and increasing technical debt.

Figure 2: A CI/CD pipeline model for a large‑scale enterprise product with over 100 million lines of code (click to enlarge). Orange sticky notes represent major components (nodes), blue arrows describe build, integration, and deployment steps, pink notes show cycle time, lead time, and %C&A, and green notes indicate staged deployment of the final product. "LST" stands for Large Solution Train, "ART" for Agile Release Train.

Enterprise Benefits of the Software Factory Method

Large enterprises are often seen as dinosaurs without DevOps, losing market share to smaller, more agile newcomers. While transformation is challenging, SAFe can help enterprises succeed, enabling rapid creation or modification of development value streams because teams share a common language and mindset.

The Software Factory empowers teams to adjust development settings quickly to meet changing business needs, shorten upgrade and start‑up times, reduce cognitive load, and promote left‑shifting, thereby accelerating delivery.

Complex toolchains required for enterprise software increase cognitive burden. Keeping up with tool updates, server upgrades, plugins, test‑automation tools, and compliance checks adds pressure and creates a mismatch between product expertise and new feature delivery, often resulting in unstable and unreliable CI/CD pipelines.

"Pipeline as a Service" can address these issues and boost productivity. Dedicated experts maintain and continuously improve the service used by multiple product teams, relieving developers to focus on core responsibilities of building high‑quality products quickly.

Standardizing development tools enables better integration and makes it easier for teams to work across products, as they become familiar with a common set of tools and core processes. A standardized toolset forms the foundation for modern software development practices such as shared code ownership and internal open‑source.

Applying the Software Factory approach to tool standardization can dramatically reduce licensing and maintenance costs while decreasing the number of integrations and synchronizations required between tools.

If you have a large number of tools, you will encounter many unreliable, half‑functional integrations and costly maintenance work, leading to unnecessarily high total cost of ownership, busy staff, and unreliable development data flows.

Standardization must be balanced with flexibility. The recommendation is to standardize as much as possible while preserving freedom where needed. Not every tool or process is a candidate for standardization. Software Factories typically start small and evolve based on adoption and user feedback. Figure 3 shows a validated Software Factory architecture with core elements.

Figure 3: Micro Focus Software Factory architecture/blueprint, illustrating the main components and categories of a fully featured Software Factory (click to enlarge).

How to Start

Mastering enterprise software and networked physical systems is complex and has no simple, one‑size‑fits‑all solution. The Scaled Agile Framework and other frameworks can provide guidance and a solid foundation for digital transformation journeys.

Advanced DevOps models combined with the Software Factory method can enhance and complement these frameworks, allowing organizations to thrive in the digital age.

About the Author

Zeyang is a DevOps practitioner focused on sharing enterprise‑level DevOps operations and development techniques, primarily covering new Linux operations and DevOps courses. With extensive hands‑on experience, his courses emphasize practicality and have earned broad student recognition. All course content originates from real‑world enterprise applications.

Enroll in the DevOps pipeline practice course to learn the technology and acquire in‑demand skills.