How to position DevOps in your value chain?
More and more clients are transforming their IT-organizations around DevOps. DevOps is nothing more than seaming together two worlds that are always in conflict with each other: development and operations. Speed and flexibility versus stability and continuity.
This is necessary to get things done faster in an automated and repeatable way. The graphic below gives a good overview of the interaction loop between the two sides.
Why is DevOps so popular?
Simply because it is more necessary and easier than ever to bring development and operations together;
- In the past, stability was of major importance in a development process (the waterfall method, for example, is supporting this). Nowadays the ability to follow the rapid market changes has the highest priority. Speed and flexibility are key in today’s business and IT has to meet these requirements.
- Increased automation resolved one major blockade for a better interaction between development and operations. In the past, updating and releasing new software resulted in high risks for a disturbance in production (operation) environments. Presently development-, test-, and deployment processes are automated, they are less prone to errors than before. This makes it easier to seamlessly develop in operations and meet the speed and flexibility demands of the business.
DevOps suits an agile development approach. The result of an Agile software development project is software in production. But software is never fully developed. Bugs and new requirements are asking for further development. Starting a new sprint is not always an option. The traditional mode, with up to 4 planned release updates a year, isn’t an option either. Then it is better to enter into a stage of continuous deployment (CD). Continuous deployment does, however, require frequent and close interaction between development and operations. DevOps is an answer here, specifically for IT organizations that are developing and operating in-house.
Continuous deployment and Microservices
To step into continuous deployment, there is a connection with building Microservices.
For large, complex monolithic application it is an obstacle introducing continuous deployment. Today, the state of the art for SaaS applications pushes changes into production many times a day. This is extremely difficult to do with a complex monolith since you must redeploy the entire application in order to update any one part of it. Microservices is a way of breaking large applications into smaller, independent, and loosely coupled modules. Individual modules are responsible for highly defined and discrete tasks and communicate with other modules through simple, universally accessible APIs. The Microservices Architecture pattern makes continuous deployment possible. An interesting set of articles by Chris Richardson on Microservices is here to read. The picture below helps to understand the way microservices differ from a monolithic application.
Microservices makes continuous deployment possible. Continuous deployment is enabled by implementing DevOps.
What makes DevOps work?
The ultimate goal of DevOps is to add value to the customer and enable organizations to react faster to change in the business, by means of automation and in a repeatable way.
DevOps tears down the traditional silos within organizations. Silos cause predictable issues; separate units communicating poorly with one another and causes clashes of opposing processes, cultures, and technologies.
This is not only the case for the IT silos Development and Operations, but also for functional business departments silos and business functions silos. Tearing down these business silos is important as we see that digitization is focusing on business services and the increasing consumerization of these services. This requires organizations to adapt to customer behavior and introduces the need to improve the speed and flexibility to deliver.
How to use DevOps in the business service value chain?
There is a lot of information available on basic rules for DevOps, on required habits for developers and operators and even on tools for the automation of tasks and analytics. DevOps can however only be a success if the DevOps team understands the business services they are developing and operating for. The Product Backlog is in the center of this understanding.
The Product Backlog lists all features, functions, requirements, enhancements, and fixes. These can be translated into user stories. There has to be a frequent alignment with business owners to discuss and evaluate all items in the Product Backlog and to prioritize them. The Product Owner is the key role.
However, the Product Backlog as to be filled. And here is service design thinking coming in. By applying the service design thinking, you can create consistent experiences that are designed around customer needs instead of the ‘inside out’ organization’s view of the world. It’s all about starting with your customer’s needs and their desired experiences and then designing the business process to deliver its services around those needs. The delivery of services spans all channels and touch points, with the one objective of having them work together to provide a seamless customer experience and a perfect value chain.
So, it is not only combining Development and Operations, you have to understand WHY both have to work together to reach the ultimate goal: Business functions that collaborate seamlessly to service the customer. This directly implies that each DevOps team has to understand its role in the value chain towards the delivered business service and that business understands the power and value of DevOps to create value.
If you have other perspectives and lessons do share them here!
For more information, contact us!