Every IT organization that wants to remain relevant in the digital era has probably taken a hard look at how companies such as Facebook, Twitter, and Amazon have leveraged DevOps to move at the speed of a bullet.
Company executives see these companies as an inspiration, and the pressure is on to become more like them. So why, after about a decade, is the move to DevOps still a major challenge in the enterprise?
Because there's a major flaw in the current model. The popular references to DevOps transformations are applicable only to organizations born in the digital era. The people in those organizations range from millennials to Generation Z'ers, their processes are agile, and their technologies are cloud-native, with the focus on web and mobile apps.
That's very different from IT organizations in, say, financial services, government, or automobile manufacturing. If yours is a traditional enterprise, you have more Generation X people, waterfall-oriented processes, and technologies that range from mainframe to client/server to cloud.
In the traditional enterprise, your challenges—even your definition of "faster"—is different from what the digital natives are experiencing. Your organization has a different DNA. And while you might be inspired by the Facebooks and Googles of the world, the road maps those organizations followed aren't entirely relevant to what your organization needs to do to transform itself.
One way forward is to create a software factory, as we did. Here's why.
The software factory-approach to transformation
At Micro Focus, we needed to transform ourselves through DevOps to be able to continue to empower our customers with their own digital transformations, as well as to continue to grow our business.
To drive this transformation we launched a software factory program (SW Factory), an integrated set of tooling, services, data, and processes that help our engineers to plan, build, test, release, and/or operate and manage the software we deliver to our customers.
Figure 1. The four elements of the SW Factory.
We started with a mission statement and defined the value we wanted to get out of the program. We wanted to integrate our product groups and facilitate a DevOps transformation by providing a cost-effective, common set of engineering tools and services that could deliver at higher speed, at high quality, and at scale.
While we needed to control costs, we had to deliver faster, with no compromise on quality, and we thought we could achieve this by providing the required people, processes, and tooling—and by continuously improving.
[ More from Yaniv Sayers: Got technical debt? Get a grip! ]
Mind the challenges and gaps
We then analyzed our starting point to identify our challenges and gaps. Here's what we found:
Tool redundancy and sprawl
This had resulted in expensive, complex engineering factories. We had multiple vertical tool chains and factories, and almost every team had its own tools. For example, we had more than 30 defect management systems, over 20 source code management (SCM) systems, and more than 10 artifact repositories. This complexity had evolved over many years, through mergers and acquisitions.
Multiple service providers
This added both confusion and delays to product delivery. For example, when a product group required an SCM tool, it was unclear who owned that. It might be provided by IT, the services organization, or someone within the product group. Defining clear services, ownership, and the interfaces between providers and consumers was key to improving agility.
Lack of visibility for data required to power end-to-end value streams
This was most often due to broken or unavailable integrations. Consider, for example, our process for handling a customer ticket. While tickets usually went through support, in some situations they were elevated to the R&D team, which issued fixes or product enhancements and communicated that back to the customer through support.
Without standard processes and integrations across the business ecosystem, such as between the support system and the SW Factory, customer experience could be significantly affected.
Suboptimal productivity and quality
This was due to a lack of alignment among, or collaboration within, the product groups. We needed a methodology and framework to manage a large portfolio in an agile and coordinated fashion.
Establish your guiding principles
To address these challenges and transform, we came to the following guiding principles.
Strive for agile delivery from the get-go
- Deliver a minimal viable product (MVP), starting with a core set of services that have proved themselves internally to generate value and with minimal risk to the business.
- Gradually expose services, starting with local pilots by a few teams. Then, gradually scale to the portfolio,
- Continuously collaborate with the consumers (the product teams) to get their feedback and align demand and priorities accordingly.
Establish a service broker operating model
This requires clear roles and responsibilities for the service owner and for service delivery. For every service there is a service owner role that acts as a product manager for the service and is responsible for driving value and customer satisfaction. There is also a service delivery role, responsible for continuous service availability and support.
Deliver end-to-end value streams
Base these on the IT4IT framework, with standard processes and integrations between the SW Factory and the business ecosystem.
Leverage the SAFe framework
This framework will help align our portfolio, deliver faster at scale, provide the required training, and empower our people to evolve.
Other principles included:
- Use our own tools and solutions first.
- Become a reference implementation for enterprise DevOps transformation.
- Serve as an early adopter of our own products; share our experiences and provide feedback to product groups.
Results and next steps
We have been able to deliver the SW Factory as an MVP and transition a significant portion of the organization to it in just 18 months. This created minimal disruption to the teams—and we are already seeing substantial improvements in delivery speed and quality.
To build your own software factory, start by aligning your expectations with those of the organization. "DevOps" is an overloaded term, with many interpretations, so you need to be more concrete.
Identify the value you hope to gain, your challenges and gaps, and then create your own guiding principles. Clarify what are you actually after and what are you looking to achieve in practice, and you'll be ready for a DevOps transformation.
Keep learning
Get up to speed on digital transformation with TechBeacon's Guide.
Download this free IDC white paper, "Enabling End-to-End Digital Transformation".
See IDC's Futurescape: Top 10 predictions for digital transformation.
How important is digital transformation to your org? Take our survey and find out how you stand next to the competition.
Thinking of making a change? TechBeacon's Careers Topic Center provides expert advice to prepare you your next career move.
