DevOps Leadership 3: Think Strategic Advantage
DevOps as strategic capability and asset
In this post I will argue that to avoid being left behind and — actually better— to gain competitive advantage, organisations need to see DevOps services and capabilities such as the design, implementation and operation of a delivery pipeline or infrastructure as strategic assets.
Your pipeline is not what you think it is…
There was a time when infrastructure was a ‘box’ in your organisation’s basement or maybe a rack in someone else’s datacentre, and where the entire infrastructure ‘affair’ was best left to dorky guys in a stuffy room, seen as something that was a necessity but which ‘the business’ really didn’t need to concern themselves with.
If as a business you believe that “yes, tech has moved on but infrastructure is still a specialist necessity I can leave to the geeks” , then you have not only gotten it wrong, but you are also missing a trick.
What business are you in?
When I ask clients this question, the answer in most cases leads back to the immediate service or product: medical hardware, cars, investment banking, property management…
I leave it to you to decide whether your organisation has a good understanding of its value proposition, or — as has been been discussed to death — they should think more broadly: diagnostics>health, transportation>mobility, finance>wealth…
While thinking in this way about your value proposition is certainly necessary, we need to extend this thinking to the shape of an organisation’s supply chain.
While manufacturing due to the lean movement has long learned to optimise its supply chains, non manufacturing organisations haven’t really understood what their supply chain is, and instead only adopted
Three rues:
1It is very likely that you are in the software business. If your product has anything to do with software it is very likely that you are in the software business. The same — arguably more strongly applies to business offering ‘services’.
2 You need to own your delivery capabilities. Outsourcing of a key organisational activity such as software delivery and related assets is naive at best.
3 Your software delivery pipeline is your supply chain. Or at least a determining part. It is in any case a major part of your value chain.
Your pipeline shows (and constraints) what business you are in.
Business with short deployment cycles are user centric and product focused. They own the future. Those that rest on the laurels of the past and are stuck in infrastructure on tin and slow, infrequent and bureaucratic deployment procedures will go the dinosaur.
One Size does Not Fit All
I have outlined in another post that when designing and delivering DevOps capabilities such as a CI/CD pipeline we need to add product thinking and user-centric design to the mix to be successful. It follows that one-size does not fit all, but that such capabilities and assets are highly contextual.
DevOps and the resulting capabilities and assets are highly context specific. One-size does not fit all. Not all pipelines are created equal.
In another post I will discuss the various user needs and expectations that pipeline and infrastructure are expected to satisfy, but generally speaking we are looking at appropriate levels of performance, stability, security. Consequently, while the general idea of a CI/CD pipeline is quite standardised, every organisation, arguably every project will benefit from a different pipeline, be this the choice of tool that make up the pipeline, the various environments to be supported or the various capabilities, ranging from any conceivable test type to be automated and executed, compliance related traceability or auditing requirements or various automated or manual workflows to be supported.
Some organisations such as digital startups in highly competitive environments will favour short delivery cadence and flexibility, others in high demand markets may focus on reliability and scaling, while organisations in regulated industries such as medical or banking will make demands towards quality, traceability and repeatability.
The still nascent DevOps tooling landscape is extremely volatile and fast moving which creates an environment where one-size does certainly not fit all, but more so, prêt-à-porter or rather pêt-à-déployer does not exist.
Add to this organisational preference in regards to technology stack and the still nascent DevOps tooling landscape being extremely volatile and fast moving, and you are in an environment where one-size does certainly not fit all.
You need to think DevOps == Strategic Asset and Capability
If there is only the tiniest differentiator of your value proposition encapsulated in software, then you need to own this item. Wardley maps are a great tool to find out how to deal with assets, specifically whether to build, buy or rent, based on importance to your organisation and industry maturity of that asset.
My point is this: if you are a forward looking organisation, you will want to treat your software as a product and control it’s supply chain. Of course, that doesn’t mean you re-invent the wheel, but you have ownership of the parts, and more importantly the design and structure of the whole end to end.
DevOps are a strategic capability, your pipeline a strategic asset. Both enable you to provide more value faster.
So organisations that want to maintain or gain competitive advantage in the 21st century need to start owning their supply chain, and, if this includes software delivery, DevOps related capabilities and assets.
‘Owning’ in the sense of taking pro-active part in the design and operation of these capabilities and assets at strategic level. Organisations need to shift their thinking away from believing that DevOps is comparable to a screwdriver, while in fact it is your assembly line. Because only production and delivery infrastructure that is proactively ‘owned’ can be sufficiently contextual to support current and future needs an organisation faces when delivering value.
Think opportunity, not hygiene.
