You can use The Open Group’s IT4IT Reference Architecture to deploy agile at enterprise scale, using either SAFe or other scalable agile methods—and that's exactly what our team did. The result: We increased our release cadence by a factor of 10.
Our larger vision is to have a single enterprise DevOps capability, extending agile development concepts out to the full loop of continuous development, integration, deployment, and feedback as part of an effective release management strategy.
Using the reference framework, we automated across all of our tools to facilitate collaboration and sharing within and across Micro Focus' global R&D group, which consists of more than 4,000 people who work in more than 500 SAFe teams in 200 product groups. Along the way we rationalized upwards of 100 tools down to 10 that, together, form a functional tool chain for enterprise-scale SAFe.
Here's how we did it—and what you can learn from our experiences using IT4IT and SAFe to increase release velocity at scale.
The vision
Here's what our end-to-end vision looks like:
Figure 1: Enterprise DevOps use cases—the flow of digital transformation.
In the diagram above, each numbered item represents one of our use cases. These range from "Continuous Exploration" in use case 1 to "Forward to Backlog" in use case 6. Our development method is based on SAFe, so our focus is on integrating and automating our use cases, then implementing the tool chain all the way into production.
Automation is key. IT4IT shows the way.
We wanted standard tools to allow collaboration and sharing within and across our entire global R&D group.
Automation across those tools is essential for SAFe and DevOps to be efficient. IT4IT describes a best-practice tools architecture, including functionality and data flows, to guide and prescribe how to integrate and automate the tool chain.
Our large product groups have around 25 teams that come together to create a product release every few months. At the other end of the scale, smaller groups may have only one or two teams, creating a new product or perhaps maintaining a very old one.
Because our organization was created through more than 30 acquisitions, every group made its own tool choices.
To set up a SAFe environment, each team put tools in place to efficiently run agile: a tool for managing sprints, a tool for managing tests, a tool for build and compile, and so on. They might quickly glue them together with various degrees of testing. Of course, every team is doing it differently.
There were some very efficient individuals and teams, but in the aggregate they were less so.
For instance, as an enterprise we found ourselves trying to integrate a dozen source-control products with probably more than 30 deployment instances. Without integration we couldn't reuse resources across the groups. It's possible, but complicated. A better choice is a single platform.
Each tool and configuration is also supported by its own skills and operational knowledge. As soon as we wanted to cross-pollinate across teams, we found that every developer had to be retrained. We didn't have a strong basis for cross-team working.
The IT4IT Reference Architecture guided our roadmap out of these difficulties.
Also, our best-of-breed SAFe platform is delivering a high degree of efficiency across the global group. It provides very powerful systems of insight into what is going on, not only within each SAFe team but across the SAFe team ecosystem.
How we chose our tools
Our global tools group chose several of our own tools, along with several open-source options. In all cases we have used IT4IT as the template for standardized integrations between functions and to guide integration of heterogeneous tools within functions.
The dominant software component is top-level project control and orchestration software, which we used to control sprints, user stories, defect management, backlogs, sprint plans, epics, test status, and so on.
Around this core we have added other tools as needed, to have the full pipeline working. Everything is mapped to IT4IT functional components, data objects, and information flows.
We have wrapped our experience up into what we call a model office, which is our prescriptive implementation of enterprise DevOps, and implemented it with several customers.
In each target landscape we look at what to transform and what to keep. We have our own components but also integrations to third parties, both commercial and open source.
Whether a customer wants to do exactly the same depends on its situation.
Drill down into the tools
The main tools in our ecosystem are not the whole picture.
For example, there may be a distinction between test execution (control) and test tool (run). Subject to the overall orchestration, we "subcontract" load testing, security testing, and so on—there are several third-party tools to support specific types of testing. But we maintain global orchestration and a global view of test automation.
In the same way, we orchestrate a continuous build pipeline with a single controlling tool that coordinates more specific build tools such as the various compilers.
Going out of scope
As we learned to implement SAFe at scale, we began to worry less about some tools.
For example, we haven’t focused on IDEs because we don't get anything out of standardizing in that area. As long as developers check in their source to Git and follow their pipeline tasks in the Kanban, things work well. But the tools we're using integrate with all of the major IDEs, so our developers get a seamless experience no matter what their choice of IDE may be.
And we found that for some of our development groups wanting to work in agile frameworks other than SAFe, the tool chain still works very well. This means we can unify reporting and portfolio management even if not all teams are using SAFe. This is very important to transform an organization, because it allows several different methods to be used in the transition period.
Also out-of-scope are matters such as coding standards that are best left to individual teams.
There is much value in standardizing on the use of common software components. But that is an enterprise architecture question, not a tooling issue, and so falls outside the scope of standing up the SAFe tool chain.
The value of architecture
The IT4IT backdrop allowed us to truly understand which components we needed to have, and to define the interactions among those components.
Not only can we theoretically demonstrate that this works, but we can show it in practice. For example, we have experience rationalizing a very large tool set down to the 10 that now form our functional tool chain for enterprise-scale SAFe.
Our standardized tool chain is now in use by almost all of our own global teams, and the architecture is delivering value for customers as well. Ours is quite possibly one of the largest global implementations of a scaled agile development.
Besides the direct value in efficiency, measurement, and collaboration, having the integrated working tool chain is the best possible platform for educating groups in understanding agile and DevOps, because we have a demonstrated methodology maintained by the "A team."
For our organization, the SAFe tool chain, supported by IT4IT, is delivering real bottom-line value.
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
