Enterprise software development is a complex undertaking, and only companies that can respond to market changes by quickly delivering high-quality software will dominate in the digital age.
There is no silver bullet to achieve the level of business agility you'll need. It requires a transformation from a traditional waterfall mindset and old ways of thinking to a lean-agile mindset, with its associated principles and practices.
Scaling frameworks and DevOps approaches can provide the guidance you need to transform your IT organization—and the rest of the business. The Scaled Agile Framework (SAFe), the most popular scaling approach, spells out the seven core competencies you need to succeed in the digital age: organizational agility, lean portfolio management, enterprise solution delivery, agile product delivery, team and technical agility, continuous learning culture, and lean agile leadership. Still, success is not guaranteed, since it requires a careful implementation that’s best achieved with the help of a SAFe Program Consultant.
Leadership engagement, alignment, and systems thinking are my favorite success factors for a transformation. See my global SAFe Summit talk: SAFe Transformations: We know how to do it but why do some fail? ... and how can we correct the mistakes?
Besides the common success factors mentioned above, the frameworks are continuously evolving. Practitioners are constantly feeding learnings and experiences from the field back into the frameworks.
That’s what I did in my recent article, "Accelerating Flow with DevSecOps and the Software Factory," which highlights the importance of shift-left approaches and how you can apply those to accelerate time-to-market, improve quality, and reduce costs. Large enterprises especially can benefit from establishing a Software Factory, an integrated set of tooling, services, data, and processes that helps teams to plan, develop, operate, and manage software and solutions. (SAFe defines "solutions" as products, services, or systems you deliver to your customers.)
Here are two helpful models, along with advice on how you can combine them with a Software Factory approach to advance your DevOps implementations and strengthen business agility.
The DevOps Evolution Model
As Peter Senge describes in his book The Fifth Discipline, teams and organizations need a shared mental model to generate a common understanding of a problem and to collaborate on finding a good solution. To that end, I created what I call the DevOps Evolution Model. That model was developed during my training classes as a way to explain how people can best progress in their DevOps journeys.
This model can help you understand how to decrease lead time and reduce the length of the feedback cycle by shifting undone work to the left. (Undone work is additional work required to release a solution after the team is "done" with features and stories. Typical examples of undone work are any kind of testing, security checks and audits, documentation, open-source legal assessments, and compliance checks.)
Shifting undone work left enables your team to provide faster feedback, which leads to more usable products and faster defect fixes. This in turn accelerates flow and increases quality. Reducing or eliminating undone work leads to more frequent releases and improved responsiveness to requirements changes.
Figure 1: The DevOps Evolution Model covers the four major stages in a DevOps journey and shows visually how your organization can progress from a less mature model to a more mature one (click to enlarge). Source: Peter Vollmer
The CI/CD pipeline model
The continuous integration/continuous delivery model evolved out of SAFe DevOps trainings and follow-up workshops I conducted. It has similarities to SAFe DevOps Pipeline mapping, which models the end-to-end pipeline on a process level. The CI/CD pipeline modeling drills down on the detailed CI/CD pipeline and the associated build and integration process. In my experience, a lot of flow issues in complex enterprise setups are a direct result of having an immature CI/CD pipeline.
To create the model, you bring all stakeholders together to draw your entire pipeline process (build, integration, deployment, etc.) as nodes and edges. Nodes represent the components, and edges describe the relationships between the components. While you might think that your teams already know their end-to-end pipeline and would find this whole effort useless, this has never been the case in my experience.
The CI/CD pipeline model lets you see the big picture. In large solutions, no single person understands the end-to-end CI/CD process. By bringing the right people together, you can see the suboptimal results of local optimization and focus on highly effective end-to-end improvements.
For example, teams often claim that they build and deploy several times a day when in fact they are building and deploying the same code or components over and over again.
The key question for CI/CD improvements is not the number of pipeline runs but how long it takes from the time the team writes the code to when it arrives in staging or production. This is the most important question you should ask for each contributing component.
Because it reduces lead time, CI/CD modeling boosts quality. Defective components can have a domino effect on the integrated final product, since the development of components that depend on defective ones get delayed. Worse yet, if your team discovers defects late in the development process, committed schedules can’t be met, or you may need to create shortcuts or workarounds to stay on schedule. That decreases quality and increases technical debt.
Figure 2: Here is an example of CI/CD pipeline modeling for a large enterprise product with more than 100 million lines of code (click to enlarge). Each orange sticky tag represents a large component (node), while the blue arrows are the edges that describe the build, integration, and deployment steps. Pink stickies show the cycle times, lead times, and percentage complete and accurate (%C&A). The green sticky is the final, deployed product on staging. Note that "LST" stands for "large solution train" and "ART" stands for "agile release train." Source: Peter Vollmer
The enterprise advantage of a Software Factory approach
Large enterprises are often seen as dinosaurs that don't get DevOps. They lose market share to newly emerging, small companies that have agile and DevOps in their DNA from the very beginning. But while it’s true that moving a large enterprise forward is challenging, with the help of SAFe, you can successfully transform. You’ll be able to create or change your development value streams with minimal effort because people will already share the same language and mindset, and they will be able to quickly adjust strategy in response to opportunities or threats.
A Software Factory complements this ability by enabling teams to faster adjust the development setup to changing business needs and shorten ramp-up and onboarding times. In addition, it helps to reduce the cognitive load of your teams, and enables efficiency gains, fostering the shift left and shortening lead times.
The complex tool chains typically required for building enterprise software often result in cognitive overload for the teams that use them. Think about required pipeline improvements and maintenance activities such as keeping up with latest tool and technology evolutions, as well as upgrades to build servers, operating systems, plugins, test automation tools, and so on. Add to that cognitive load release deadline pressure and the need to keep up with product and domain expertise as well as new features and bug fixes, and it’s no wonder that many CI/CD pipelines are unstable and unreliable.
A “pipeline as a service” can solve these issues and boost productivity. Dedicated experts maintain and continuously improve services that multiple product teams can use, relieving development teams of that burden so that they can focus on their core responsibility of developing high quality products in short time frames.
To attain a faster response to change in your development organization you need to standardize your development tools. This allows for better integrations between the tools and makes it easier for your development teams to work on other products, since they will be familiar with all of the tools and core processes other product groups are using. A standardized set of tools sets the stage for modern software development approaches such as shared code ownership and internal open source.
Standardizing tools using a Software Factory approach can tremendously reduce licensing and maintenance costs, while also reducing the number of required integrations and synchronizations between tools.
If you have a menagerie of tools, you probably have a lot of unreliable, half-functioning integrations and costly maintenance efforts. That means unnecessarily high total cost of ownership, busy people, and an unreliable flow of development data.
But standardization requires a careful balance. My advice is to standardize as much as necessary while providing as much freedom as possible. Not all tools and processes are candidates for standardization. A Software Factory usually starts small and incrementally evolves based on adoption and user feedback. Figure 3 shows a proven Software Factory architecture with the core elements.
Figure 3: This is Micro Focus’ Software Factory architecture/blueprint, which shows the major components and categories of a full-blown software factory (click to enlarge). Source: Yaniv Sayers and Peter Vollmer
How to get started
Mastering enterprise software and cyber-physical systems is a complex endeavor with no easy solution or silver bullet. The Scaled Agile Framework and some others can provide guidance and a strong foundation for your digital transformation journey.
Advanced DevOps models, in combination with a Software Factory approach, enhance and complement these offerings so that your organization can thrive in the digital age. If you’re just starting your journey, get going in the right direction by talking to a SAFe Program Consultant Trainer (SPCT) or attend a Leading SAFe class.
To learn more about this topic, I recommend these reads:
- Accelerating Flow with DevSecOps and the Software Factory
- What is an SPCT and how can you become one?
- SAFe Transformations: We know how to do it but why do some fail? ... and how can we correct the mistakes?
- Why a Software Factory is key to your enterprise DevOps success
- DevOps at scale: how to build your Software Factory
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
