This is a guest post for the Computer Weekly Developer Network blog written by Simon Poulton of CA Technologies — Poulton is ebulliently vocal about his passions for virtualisation, cloud, mobility and the wilder more exciting realms of the total DevOps arena.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Poulton writes as follows…
In my previous blog I talked about the two choices that face businesses when tackling DevOps and the two options that face us:
- Create new innovative front ends and integrate that with all the legacy stuff, or
- Rewrite the whole system on modern architecture and platform (e.g. microservices)
Given the complexity of Option 1 and the number of silos we need to consider for Option 2, how do you create something like this for the enterprise?
You would struggle to design something that satisfies everyone in the organisation for hundreds or thousands of apps. That would be totally UN-Agile and waterfall in approach, so here’s the tip of the week – DON’T do that.
Segmentation by value stream
What you want to do first is segmentation by value stream. You want to look at the point that your customers consume products, and work back along the delivery chain until you get to the very start where the business is making a decision to do something. It’s about taking a horizontal, rather than vertical approach.
There are many of these in an organisation (as you generally have many software products), so choose one which is important to the business and has goals around at least 2 or 3 of the four key drivers (TTM, Quality, Efficiency, Compliance). This value stream will become an “Exemplar”, allowing you to build some capability without hitting analysis paralysis trying to think of all the design parameters. An Exemplar will serve as a learning experience for DevOps methodologies as well as giving you some proofs to get more senior buy-in for transformation across the Enterprise.
Another important point – include dependencies. For example, if you choose your mobile application for customers, think of how dependant change will be managed on systems it consumes from. If you just solve for your mobile system, but you need to make changes at an underlying system which takes nine months to do, then you’ve got a major challenge.
Once you’ve chosen your value stream, you need to get all the constituent pieces together to assess this. You want business owners, business analysts, architects, dev managers, test managers, and ops teams who look after this system to come together to map the process.
Once you’ve understood that process end-to-end, and where there are delays and constraints, you can start to look at which delivery chain improvements serve the business goals of that value stream best, so you can prioritise work.
Having senior people from each silo will also help you identify manual handovers which are wasting time, and which problems exist in many value streams. This is how you get started quickly, but in a way that delivers scalable value. Eat, sleep, rave, repeat onto your next value stream and you will start to build a library of capabilities for your Continuous Delivery transformation, as well as get better at the analysis process.
Ultimately if you have 500 applications you won’t need to assess 500 value streams to create 500 different Continuous Delivery toolchains. As you get through the first few, the Continuous Delivery methodologies and DevOps ways of working start to uncover tools and processes which solve problems for a huge array of different value streams.
Synthetic test data
For example, we just worked on building a “demonstrator” Continuous Delivery pipeline with a large telco. One of the problems we solved was generating synthetic test data for the application on each deployment so it can be fully validated. This applies to almost every app they have – the one in question was a web service, so we now have something to fix the hundreds of web service applications they build.
As you get good at these “capabilities” you expand them quickly to different projects and technologies and adoption rates increase. Especially if you can get some senior stakeholders to run the Continuous Delivery flag up high and visible so everyone knows this is where the organisation is headed. You will end up with a Continuous Delivery product which can be consumed by any team wanting to produce a software product.
The wider benefits of advanced DevOps adoption are clearly evidenced and organisations cannot afford to ignore the important role this plays within successful digital transformation plans. Taking a horizontal approach enables you to apply a start-up mentality to enterprise Continuous Delivery transformation. This becomes a catalyst for change towards an innovative technology platform and more effective integration.