How to Deliver Business Value with DevOps in a Challenging, Multi-Vendor Landscape
DevOps affords enterprise organisations the opportunity to solve time, cost and quality conundrums by implementing change solutions that combine the essential benfoundations of people, process and technology. However, for many of the customers I am working with, whilst DevOps is very much a key area of focus on their transformational roadmaps, there are numerous blockers which prevent true spread and adoption of DevOps practices and behaviours across the software delivery lifecycle (SDLC). One of the most common challenges I have come across is the establishment of multi-vendor landscapes who are contracted on time and materials (T&M) engagements.
In essence, if 'Vendor A' is delivering a piece of work for a customer on a T&M contract basis, is it in their interest to deliver faster or cheaper? Some would argue that it isn't. Indeed, when we now consider that DevOps behaviours and Continuous Delivery practices optimise the cost, pace and quality of change there is an argument that DevOps cuts off the life blood of vendors who adopt a “stack them high, sell them cheap” mentality. As such, I felt compelled to share a couple of recommendations that might help customers drive their vendors to truly buy into their DevOps transformation journeys, so as to add business value.
Key Performance Indicators and Metrics: Quality First
KPIs and metrics are often cited as a critical component in laying the foundations for a DevOps transformation. Being able to articulate the business value that a DevOps approach has created to both internal and external stakeholders is a powerful mechanism for driving wider adoption. However, the KPIs and metrics captured as part of a DevOps transformation can also be used as a catalyst by which to drive the quality of work supplied by your vendors. The common mistake many enterprises make is measuring vendor-driven change first and foremost against cost and time. However, what they should be measuring most importantly is quality.
By introducing role-specific quality control metrics, enterprises should be able to avoid defect slippages in the later stages of the lifecycle, reduce coding re-work and alleviate test cycle re-runs. By implementing role-specific quality metrics across the SDLC, enterprise customers will have an improved capacity to identify constraints across their delivery pipeline, whether it be design, development or production systems. By understanding these constraints they can proactively manage blockages by introducing focused solutions and intervention strategies. Or, perhaps more brutally, remove the incumbent vendor who is causing the blockage!
Enterprise customers should also consider metrics that provide insight into commercial fluctuations with their vendors, service level-specific measurements whilst also considering business value reporting with a focus on the rate of change (which is a function of innovation).
Introduce Effective Service Integration and Management (SIAM) Functions
SIAM originated from the increasing need to effectively manage multiple vendors as a result of wide scale IT outsourcing agreements between enterprise organisations and their vendors. The key aim of SIAM was to enhance cost transparency, reduce risk to the business and take advantage of the competitive landscape to ensure the business was serviced with the best of breed for both solutions and services.
As such, for enterprises who operate in a multi-vendor service model there is a need to create a central capability which can measure, oversee and co-ordinate service management processes, exert governance in line with a true DevOps culture and effectively manage service provider performance. However, it is critical to ensure that this central capability has metrics and KPIs that are correctly aligned to Service Level Agreements (SLAs) which, again, focus on measuring quality across the SDLC. This service integration component must also ensure processes, tools and related structures are defined to a finite detail, so as to ensure clear ways of working which are in line with a structured DevOps framework and toolchain.
By converging DevOps and SIAM, enterprise businesses can target people and attitude to drive quality gains across the SDLC. SIAM empowers customers to address the challenge of spreading services across multiple vendors and, as such, can sufficiently improve the capacity for customers to drive DevOps practices across their change lifecycle.
Fixed Price, Milestone-Based Payment
Ask yourself this question: would you pay a constructor to turn up every day, sit on your driveway, speculate about how he could build your extension and then allow him to drive off in the sunset, only for them to return the next day and repeat the process? Simple answer: “No”. You wouldn’t. So why should enterprise organisations accept the same type of behaviour from their vendors when delivering change across their SDLC?
One way of driving DevOps adoption amongst your vendors could be realised by introducing more fixed price, milestone-based payment work packages. By the very nature of having to meet stringent timelines, vendors would need to be more receptive to adopting new methods of working, exploring ways in which to drive collaboration and most importantly, embracing approaches to delivering change that ensure time-to-market can be improved, without hindering the quality of service provided to customers. DevOps provides this capability in abundance. By structuring fixed price engagements with their vendors, enterprise customers can be empowered to convince their vendors that the delivery landscape is changing and requires new ways of working.
Indeed, this approach also adds further overheads by way of relationship and delivery management for both the vendor and the customer. However, with active control and stewardship both sides can manage risk effectively in order to maximise their mutual investments.
Incentivised Payment Structures
Time-to-market is a key driver for any enterprise organisation in today’s competitive digital marketplace. As such, vendors will always be challenged to deliver innovative solutions at speed. More so, for enterprise organisations that want to realise a return on their investment as soon as possible. This affords customers the opportunity to introduce incentivised payment structures with their vendors, in particular when aligned to fixed price work packages.
For example, a customer could be working on developing a new mobile application. By working with the business to understand potential revenue projections, they can then use this data to structure a palatable risk and reward payment structure which sees the vendor paid more, should the product be launched to market ahead of schedule. Conversely, the customer has the capability to reduce the payment terms with the vendor, should the delivery of the new mobile application not meet intended market release dates.
By enticing their vendors with the promise of a richer cash payment, customers are more empowered to advocate the use of DevOps behaviours and Continuous Delivery practices in order to deliver change at a faster cadence. Essentially, the structure of any such agreement must be 'win-win' and in-line with SLAs and contractually-defined ways of working.
In Closing
These are simply a couple of ideas, suggestions and recommendations to help enterprise customers navigate their multi-vendor landscapes in order to better drive DevOps-focused transformations. I hope it has created some thought provoking opinions, which I am more than happy to hear. I will be blogging in the coming weeks with a specific focus on role-specific KPIs, metrics and methodologies to increase quality across the SDLC in a truly DevOps fashion. Indeed, there is certainly a symbiosis between DevOps & SIAM which I am keen to write more about as well, so please stay tuned!
