Digital transformation is no passing fad. It’s a reality that every enterprise has either already faced or is actively facing. If you’re new to digital transformation, the good news is that many businesses have completed the first steps of this journey successfully, and there are significant lessons to learn from their experiences.
But no matter how much digital transformation you have achieved, the work is not yet done: Digital transformation is an ongoing process that requires continuous dedication and focus on improvement. It truly is a journey.
In an effort to capture the industry’s best practices surrounding digital transformation, The Open Group has been working to embed several core value streams that are essential for managing digital transformation into its popular IT4IT Reference Architecture.
This next evolution of the IT4IT standard is scheduled for release next year, but there’s no need to wait for the update to get started. If you want to achieve true agility across your entire organization and increase release velocity at scale, it makes sense to get started now.
At my organization we have adopted these six values, and we are working to embed the principles in all of our products and services.
Value streams: The six principles
The core concept behind the six value streams is continuous improvement. The days of creating an annual plan at the beginning of the year, then watching it slowly fall apart as market conditions change and user expectations diverge, are gone. Today, your business must be truly agile, constantly adjusting to market needs and reacting to unexpected complexities.
The concept of continuous improvement is not new, but efficiently managing agile improvement across the planning, development, and delivery of transformative digital services is still very difficult at enterprise scale. It’s a change of mindset that requires significant up-front effort. But these six guiding value streams can get you there.
1. Continuous build and test
Continuous build and test revolves around the concept of continuous integration. By now, most organizations have adopted the strategies that are endemic to agile: prioritizing features, creating source code, and continuously testing, all in an iterative cycle. But what happens to this process on an enterprise scale?
Companies need to find ways to standardize this process across the many development teams that make up the enterprise. You must efficiently reuse resources and code across teams, centrally manage user needs, and continuously test security across the enterprise.
In an organization with dozens or even hundreds of development teams, the process of unifying development and ensuring that product quality remains consistent is complex.
2. Continuous deployment
Continuous deployment is already part of the IT4IT architecture, but many organizations struggle because they have trouble understanding over the long run what they have released, and where and when they released it.
Putting a product into production is easy, but maintaining that product three years down the line can get complicated, especially if you are maintaining multiple versions on a global scale.
How do you patch each of those individual versions? What are the dependencies of each product with other products? Monitoring the entire application complex is easy on a small scale, but difficult on a large one, particularly as time goes on.
3. Predictive service management
Once you’re done with continuous deployment, you still must maintain the products. DevOps groups often have a developer who takes on an informal role of monitoring and patching applications. But that doesn’t work in the long run, and it doesn’t work at scale.
Yes, we know that ‘real DevOps’ requires dev to work with ops, but the reality is that most DevOps teams are really led by developers, and those dev teams often circumvent working with traditional operations.
To overcome that, and to streamline managing services in production, you need an efficient and consistent way to perform predictive service management. This needs to happen from a single, centralized console, where all products can be monitored according to the service level they have to deliver.
This centralized monitoring must be predictive in nature, and it must be able to perform risk assessment based on the business importance of the individual services that are monitored.
Predictive service management must provide complete organizational awareness of exactly what’s going on both in the cloud and in your data centers. You must also have automated the runbooks you use for investigation, escalation, and correction of issues. And your predictive service management system must be able to automatically select and run relevant runbooks.
4. Continuous feedback
Another key element of digital transformation is the ability to collect feedback and successfully deliver it to the appropriate people.
Rarely is this process consistently managed in the organization, but it’s critical to develop a system to efficiently and automatically collect feedback generated by your predictive service management operation (including operations and help desk groups). Then you need to feed it to the product team to incorporate into continuous development efforts.
Even better, consider conveying this feedback further back up the line to the planning organization, to aid it with prioritization and future product design efforts.
5. Continuous exploration
This complements continuous feedback, and has several starting points. It revolves primarily around the challenges inherent in any enterprise that has several thousand products or applications running at any given time.
Managing such a portfolio and understanding where it needs shoring up is complicated. As a result, a yearly planning cycle isn’t going to be successful here.
You need to put your business in the mode of continuous exploration, creating a back-and-forth between what’s being developed and what business is requesting. This will give you the ability to constantly revise the scope and budget being assigned to various development teams, all while taking into account user feedback.
In other words, you must constantly rebalance how you spend your money and react to new business requirements in the real world, then do it again.
True agile development should not be constrained by a waterfall-like planning process.
6. Service onboarding and consumption
When you deploy a product, you’re really deploying a system that allows for the consumption of services. Users aren’t really asking for a product; they’re asking for a way to do something, such as send an email or pay an invoice.
That’s why organizations need a centralized catalog of these services: so that users can easily find and consume those services.
When a customer or employee is consuming a service, the catalog lets you understand who owns that service and its current state, and allows you to monitor its use. Many organizations skip this step altogether; they just put services into production, and the services become available to everyone, with no oversight or accountability.
Another scenario is that each service has its own bespoke onboarding and lifecycle processes. That makes it impossible to manage and control the consumption of digital products in the enterprise.
Looking ahead: Help is on its way
Deploy these six value streams across your IT infrastructure, and you will have a truly efficient and standardized IT management system. But developing and creating a set of systems that can deliver all of the above isn’t something you have to do on your own.
The Open Group is developing a value stream-based structure that allows you to achieve these goals by scaling an agile organization to the enterprise level. That structure will help you transform IT in manageable steps and design your organization to leverage automation as much as possible, reducing risk and increasing security along the way.
This article first appeared in techbeacon.com
About the Author
Lars Rossen is a Chief Technologist for Micro Focus’ cross portfolio program. He created the first version of The Open Group’s IT4IT Reference Architecture, and he continues to be the lead architect for the IT4IT initiative. Lars joined the Micro Focus software portfolio architecture and strategy team in 2006 and has had many leading roles in defining and progressing the current solution portfolio.0