No matter how much digital transformation you have already achieved, the work is not finished. Digital transformation is an ongoing process that demands continuous dedication and a sustained focus on improvement. It truly is a journey, not a destination.

In an effort to capture industry best practices, The Open Group has been working to embed several core value streams into its IT4IT Reference Architecture — a framework designed to help IT organizations manage end-to-end digital services. These value streams are essential for managing digital transformation at enterprise scale. If you want to achieve true organizational agility and increase release velocity, there is no reason to wait to get started.

The Six Value Streams: An Overview

The core concept behind all six value streams is continuous improvement. The era of creating a fixed annual plan at the beginning of the year — only to watch it slowly fall apart as market conditions shift and user expectations evolve — is over. Today, businesses must be genuinely agile, constantly adjusting to market needs and reacting to unexpected complexity.

The concept of continuous improvement is not new. But efficiently managing agile improvement across the planning, development, and delivery of transformative digital services remains difficult at enterprise scale. It requires a significant change of mindset and meaningful upfront effort. The six value streams described below provide a practical framework for getting there.

1. Continuous Build and Test

Continuous build and test is grounded in the principles of continuous integration. Most organizations have already adopted core agile strategies: prioritizing features, writing source code, and running iterative test cycles. The challenge is applying this consistently across an enterprise with dozens or even hundreds of development teams.

At that scale, organizations must find ways to standardize the build-and-test process. This means efficiently reusing resources and code across teams, centrally managing user requirements, and continuously validating security across the entire portfolio. Maintaining consistent product quality when many teams are working in parallel is one of the most complex operational challenges in enterprise software delivery.

• Standardize CI pipelines across teams to reduce drift and enforce quality gates.
• Centralize dependency and code reuse to avoid duplication and reduce maintenance overhead.
• Embed security testing throughout the build cycle rather than treating it as a final gate.

2. Continuous Deployment

Continuous deployment is already a recognized component of the IT4IT architecture, but many organizations struggle with it over the long run. Putting a product into production is straightforward — the difficulty lies in maintaining full visibility into what has been released, where it was deployed, and when.

Maintaining a product three years after its initial release becomes especially complex when you are supporting multiple versions across global environments. Key questions organizations frequently fail to answer consistently include:

• How do you patch individual versions of an application running in different environments?
• What are the inter-product dependencies for each deployed version?
• How do you monitor the entire application estate as it grows in size and age?

A mature continuous deployment practice requires robust release tracking, dependency mapping, and automated rollback capabilities — not just the pipeline tooling that gets code into production in the first place.

3. Predictive Service Management

Once products are in production, they must be actively maintained. In many DevOps teams, a developer informally assumes responsibility for monitoring and patching applications. This approach does not scale and creates single points of failure as the application portfolio grows.

Effective predictive service management requires a centralized console from which all products can be monitored in accordance with the service levels they must deliver. This monitoring capability must be predictive — not just reactive — and should incorporate risk assessment based on the business criticality of each monitored service.

Mature predictive service management includes the following capabilities:

• Full-stack visibility across both cloud and on-premises environments.
• Automated runbooks for investigation, escalation, and remediation workflows.
• Intelligent runbook selection, where the system automatically identifies and triggers the appropriate remediation procedure based on detected conditions.
• Business-impact-aware alerting that prioritizes incidents by their effect on critical services.

4. Continuous Feedback

A critical but frequently overlooked element of digital transformation is the systematic collection and routing of feedback. In most organizations, this process is ad hoc and inconsistent — feedback generated by operations teams, help desk groups, and monitoring systems rarely finds its way to the product teams who can act on it.

A continuous feedback loop requires building a system that automatically collects signals from production operations and service management, then routes that information to the right people. At a minimum, feedback should reach the product development team so it can be incorporated into ongoing development efforts. Ideally, the most actionable insights should travel further upstream to planning and portfolio management, where they can influence prioritization and future product design.

Without a structured feedback mechanism, development teams are effectively working blind — optimizing for assumptions rather than observed reality.

5. Continuous Exploration

Continuous exploration complements continuous feedback, and it addresses one of the most persistent challenges in large enterprises: managing a portfolio of thousands of products and applications while continuously aligning that portfolio to evolving business needs.

A static, annual planning cycle cannot keep pace with the rate of change in modern markets. Instead, organizations need a dynamic planning model that creates a continuous dialogue between what is being developed and what the business is actually requesting. This requires the ability to:

• Continuously revise scope and budget allocations across development teams.
• Respond to new business requirements in near-real time rather than at fixed planning intervals.
• Incorporate user and market feedback directly into prioritization decisions.

In short, true agile development must not be constrained by a waterfall-style planning process. Continuous exploration ensures that how the organization spends its development investment is always aligned with current business reality — and that alignment is revisited constantly, not once a year.

6. Service Onboarding and Consumption

When an organization deploys a product, it is really deploying a system that enables the consumption of services. Users are not asking for a product in the abstract — they are asking for a capability: the ability to send an email, pay an invoice, generate a report, or access data.

This distinction matters because it points to the need for a centralized service catalog: a governed registry through which users can discover and consume services, and through which the organization can maintain visibility into service ownership, state, and usage patterns.

Many organizations skip this step entirely. Services are pushed into production and become available to everyone, with no formal onboarding process and no accountability for ownership or lifecycle management. The alternative failure mode is equally common: each service has its own bespoke onboarding and lifecycle process, making it impossible to manage consumption at scale.

A well-designed service catalog solves both problems by providing:

• A consistent onboarding process for all new services.
• Clear ownership and accountability for each service.
• Usage monitoring and governance across the entire service portfolio.
• A discoverable interface for end users to find and request the services they need.

Putting It All Together

Deploying these six value streams across your IT infrastructure creates a genuinely efficient and standardized IT management system. Together they cover the full lifecycle of digital service delivery — from initial planning and exploration, through build and deployment, to in-production management, feedback collection, and service consumption governance.

The relationship between the six streams is not linear. Continuous feedback feeds continuous exploration. Predictive service management informs continuous deployment. Service onboarding and consumption depend on everything upstream working reliably. The value of the framework comes from treating these streams as interconnected, not as isolated practices.

The Open Group’s IT4IT Reference Architecture provides a structured basis for implementing these value streams at enterprise scale. The framework is designed to help organizations transform IT in manageable steps, leverage automation to reduce risk, and design operating models that can adapt continuously to changing business demands. Organizations that want to begin this work do not need to wait for any particular standard revision — the principles are actionable today.

This article is based on concepts drawn from The Open Group’s IT4IT Reference Architecture and originally sourced from TechBeacon.

Why Enterprises Are Betting on DevOps

A benchmarking study by the Hackett Group, titled Beyond World-Class Service: IT’s Digital Capability Imperative, identified DevOps as a key enabler of digital transformation. The report concluded that “agile, DevOps and continuous development models are well-suited to digital business transformation, which demands accelerated development, rapid prototyping and incremental value.”

Supporting evidence comes from a Forrester survey of 4,976 IT professionals, which found that firms with high-performing business technology solution delivery organisations were 1.5 times more likely than their peers to exceed profitability, market share and productivity goals.

European adoption is already significant. A survey of 750 IT decision-makers conducted for Claranet found that 29% of European businesses had already adopted a DevOps approach at the time of publication, with a further 54% expecting to do so within two years. Respondents cited better applications (54%), greater operational efficiency (53%), and improved customer satisfaction (45%) as the primary drivers.

Despite this momentum, translating DevOps intent into tangible outcomes is proving harder than many organisations anticipated. Three recurring challenges dominate enterprise conversations: broken delivery pipelines, difficulties scaling DevOps culture, and acquiring the right skills.

Fixing a Broken DevOps Pipeline

“There is an understandable rush to implement DevOps as the promise of delivering technology faster and more efficiently is compelling,” says Tim Russell, chief product officer at Perforce. “The immediacy of action often drives quick-fix or easiest-path solutions that, in turn, drive significant yet unintended downstream costs and efforts, even if it seems as though improvements are visible in parts of the process.”

Chris Hill, software development manager at Jaguar Land Rover (JLR), described this challenge in a video interview with Computer Weekly filmed at DOES 2017 in London. “A poor software development lifecycle is slower than it needs to be, has roadblocks and a slow path to production,” he said. If a developer cannot clearly see how to get code into production, or the path is convoluted, features are simply not released as quickly as they could be.

JLR faces a constraint that is common in embedded-systems industries: when putting software into vehicles, the team does not have the relative simplicity of a web deployment model. Spinning up a fleet of physical vehicles to run automated test suites is not feasible, so the team relies on virtualisation and software-based infrastructure to build code that is representative of the production vehicle’s operating environment. This is a reminder that some technology constraints are genuinely immutable and cannot be resolved purely through cultural change.

Legacy IT presents a related obstacle. Justin Dean, senior vice-president for technical operations at Ticketmaster, described at the Cloud Native Computing Forum how DevOps principles can still apply to teams managing legacy software stacks. At Ticketmaster, the team that writes software also carries operational duties. A key part of Ticketmaster’s DevOps transformation involved giving those teams access to the technical environments needed to deploy software independently.

One practical approach Ticketmaster adopted is a formalised work pipeline: tasks requiring legacy team involvement are submitted through a structured queue. Once completed, the DevOps team proceeds with deployment. Dean’s assessment of containerised delivery was direct: “When you deliver software in a container through a pipeline, it forces a massive change. This single-handedly had more impact than anything else and dovetailed into DevOps.”

The Challenge of Scaling a DevOps Culture

Culture remains one of the most cited barriers to successful DevOps adoption. While DevOps is often framed as a software development and IT operations concern, sustained success requires a shift in mindset across the wider business — including product, finance, and senior leadership.

BBVA, the multinational banking group, has applied DevOps at scale across multiple regions as part of a broader transformation programme. Speaking at DOES 2017, Brian Timmeny, head of advanced engineering, DevOps and IT processes at BBVA, acknowledged that “when you scale DevOps at more than a team level, some things can become more prescriptive.” His advice to large enterprises: start with a simple, clear message — “you are going to achieve speed and you are going to achieve quality.”

With around 140,000 employees and approximately 12,000 developers, BBVA’s transformation had to involve the business directly. The bank began by working to define what a “BBVA product” actually means internally. “One of the key tenets of DevOps is for a team to have end-to-end responsibility for the product,” said Timmeny. “You have a team that will build it, deploy it and monitor it — they will own it, cradle to grave.”

The difficulty is that large organisations are typically structured by function, not by product. Timmeny’s practical solution was to establish truly self-sufficient internal teams first, then gradually wrap a business function around each team. “This gives us a place to start — to have a set of core principles that, to begin with, can be done in a minimal viable way. Over time, everything else will evolve.”

This approach required top-down executive support, which was available at BBVA in part because the financial sector broadly recognises the urgency of technological transformation. Without visible leadership commitment, scaling DevOps culture across a large enterprise is likely to stall.

Getting the Right Skills

Hiring external experts to close a DevOps skills gap can seem like the fastest solution, but Forrester cautions against relying too heavily on external recruitment. Its report Organise and Staff I&O Pros for Successful DevOps Practices noted that DevOps role vacancies rose by 15% between December 2015 and December 2016, pushing salaries up — while also increasing the risk of candidates who have “DevOps washed” their CVs to appear more experienced than they are.

Forrester principal analyst Amy DeMartine articulated the broader skills requirement: “The success of the integrated product team relies on the ability to pull expertise from all resources required to create a successful digital solution. Resources from application development and IT and operations professionals need expertise from security professionals, customer experience professionals, QA, and enterprise and business architecture professionals. The success of these teams is measured by meeting the customer experience goals.”

Tom Clark, head of common platform at ITV and a DevOps advocate, offered a more direct hiring framework when speaking to Computer Weekly at DOES 2017. “As technology has moved forward, the skills you require have moved up. But at ITV we have boiled it down to two qualities: you have to be smart and you have to be kind. Anything else is a bonus.”

At ITV, “smart” means the capacity to adapt to change — since today’s tooling will not be tomorrow’s. “Kind” means the ability to integrate into and strengthen a team. Clark put it plainly: “Don’t be a douche, just be nice.”

Key Takeaways for DevOps Practitioners

• Audit your pipeline first. Visible improvements in one part of a delivery pipeline can mask deeper bottlenecks downstream. Map the full path to production before selecting tools or restructuring teams.
• Legacy integration needs a formal interface. A structured work-queue model between legacy and cloud-native teams, as used at Ticketmaster, can reduce friction without requiring a full legacy re-platform.
• Define what a “product” means in your organisation. DevOps team ownership is meaningless without a shared, business-level definition of the product a team is responsible for.
• Scale culture top-down and bottom-up simultaneously. BBVA’s experience shows that executive sponsorship is necessary but not sufficient — self-sufficient teams must also be built from the ground up.
• Screen for adaptability, not just current toolchain knowledge. Given how rapidly the DevOps toolchain evolves, the ability to learn matters more than familiarity with any specific tool.
• Be wary of CV inflation. With DevOps salaries rising and demand outstripping supply, skills validation during hiring is essential.