Contracting for multi-supplier DevOps
- William Hooper
- On July 27, 2016
Just when multi-supplier (also known as SIAM) contracting is starting to get under control, DevOps emerges. This article looks at the interaction of the two for the design of retained and sourced IT operations. The implications for service contracts are profound and largely un-tested.
The pages of management journals have been liberally sprinkled with fads for many decades. Some react with naive credulity; instantly tacking from one to another as each article appears in the press. Others ignore all trends and emerging thought, dismissing all as fluff and yesterday’s news. The smart look for the essence of new tools, seeking to understand which are applicable where to deliver what. If these match their strategies and visions, they are pursued. If not, they are passed over. In this spirit, this article regards multi-supplier operations and DevOps as approaches that are serious, fundamental and useful for some but not all organisations.
In the period between the 1970s and 2010 contracts may generally be characterised as “monolithic”. A customer would have few, large, long-duration (10-15 year) contracts. Each would address a large element of their service requirement or even contract a whole class. There may be one IT supplier, a second buildings facility manager, a third processing Finance & Accounting with HR. The interactions between these were light and few. The mode that the supplier chose to operate their service was its own internal affair, minimally disclosed to the customer and jealously guarded. The retained organisation withered and was ruthlessly cut to permit little beyond the approval of change and periodic performance review, which senior managers delegated wherever possible.
Multi-Supplier So Far
The growth of the cloud and the arrival of new service providers contributed to the emergence of a new model that engaged multiple suppliers and fragmented services between them. There needs to be a unifying function for services to operate effectively end-to-end and across suppliers, so the “Service Integration and Management” function (SIAM) was defined and implemented. This replaced the integrative function that had previously been supplied by the monolith. Sometimes elements of service integration are sourced, sometimes provided in-house: part of the skill is in drawing the boundary in a manner that is appropriate to the strategy and circumstance. The demands on the retained organisation were inevitably heavier than under monolithic contracting.
Whilst the high-level model has many attractions, contractual and operational difficulties quickly emerged. Multiple modes of collaboration agreement, incentives and cross-supplier obligations were tested. Customers found it difficult to staff their functions and differentiate between dispensable overhead and essential oversight. The result has too often been a dog with rubber teeth. The CIO ordered a highly-trained Alsatian; the organisation delivered a Chihuahua with a high-pitched yap and nasty suck. Impotence flows not from a weakness of the model, but from neglect of critical factors. These include robust and attentive governance; clear and enforced architectural standards; consistent and applied operating processes and roles; attentive financial, service and contractual management. These are a part of the price for making SIAM work. If you are not prepared to attend to these, you may do better with a monolithic contract. Do not even think of in-sourcing if the ability to divert management attention is your driver.
It has long been known that multi-supplier operation is heavily dependent upon effective collaboration between suppliers. In years gone by, the UK trades unions practiced “work to rule” as a superbly effective way of inflicting destructive effect. Customers did not have to mediate in the days of monolithic contracts, or were trained over years of glacial performance to expect months and multiple revisions to effect the simplest of changes across organisational boundaries. In these times of digital clock-speed and fickle customers, such practice is incompatible with market success. There are well-established service providers who have grown wizened and ugly in protected markets. Some such providers cannot be trusted to cooperate. This is so central to effective performance that it has to be weighted heavily in supplier selection, including assessment of incumbent performance. Get this wrong and marketing will simply continue to ignore IT in buying shadow services without any control or economy.
The leading customers and suppliers are just now getting to grips with multi-supplier operations and service integration. Some of the contracts formed appear to be sensible and if the operational difficulties and critical factors are not yet performing, there is some hope that eventually they will. Attempts to define what should be done to support integration have diminished, sometimes being no more than obligations to exchange data, work to common process and sign up to non-contractual Operating Level Agreements. What then is this DevOps fad?
What is DevOps?
“DevOps (a clipped compound of ‘development’ and ‘operations’) is a culture, movement or practice that emphasises the collaboration and communication of both software developers and other information technology (IT) professionals while automating the process of software delivery and infrastructure changes. It aims at establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably.” (Source: https://en.wikipedia.org/wiki/DevOps)
DevOps is a perspective, an approach. You cannot buy it, but you can do things in a DevOps way. Some describe it as the application of lean and quality techniques to IT. DevOps proponents hold that IT suffers from many of the failings that bedevilled engineering and manufacturing; ineffective hand-overs between design and production; repeated re-work; testing in unrepresentative environments; bottlenecks that are overloaded whilst other resources lie idle; inconsistent manual operations where automation could be applied. Many similar techniques can be brought to IT that were first developed for manufacturing/engineering.
DevOps seeks to accelerate the capture of value across the end-to-end delivery lifecycle. As such, it roots-out delay, ineffectiveness and waste. A strong feature is unceasing and energetic focus on operational analytics and the application of automation. There are few that would object to such a proposition. What has changed to make it possible is the widespread availability of tools and environments that allow the dream to be realised in action. The warning that all readers should heed is that practice is evolving at such a pace that everything should be regarded as unstable. If you seek to draft reliable contracts in such an environment, this is a nightmare. As in any emerging market, there is real insight and progress, there is also re-branding the old with a dusting of creative terminology. Beware the charlatan.
Contracting for DevOps Delivery
There has been little written on this subject that has come to my attention. If you have examples, please share.
At the time of the emergence of the SIAM model, it was notable that the leading outsource suppliers studiously avoided the role of Service Integrator. The fear was that as the SIAM had to hold tower suppliers to account, demanding independence, this left the SIAM supplier with the integration risk (and associated penalty) without the juicy revenues that come from the much larger towers. With DevOps the picture moves on. Several large integrators have developed cloud brokerage services and have packaged associated tooling as a service. They will host the marketplace for your infrastructure, allowing you to fulfil from multiple cloud providers. You can also engage multiple applications development and maintenance suppliers, all of whom use the same cloud brokerage services. The contracts for services are simple, being pass-through of associated infrastructure charges with a defined mark-up and a fairly short minimal engagement. The real prize for the supplier is often capturing Applications Development & Maintenance work.
For some customers, engaging such a supplier is an answer to prayer. Having looked at the tooling required, stitching it together rapidly emerges as a very difficult, time-consuming and expensive activity. Those who have got as far as exploring the ability to resource the delivery project find it desperately difficult. Tool developers with relevant experience, let alone the architects and service developers are rare and expensive. It would seem to make sense to use a portion of a tried and tested platform under a SaaS contract, rather than build one. Where is the catch? For some, particularly seeking to avoid vendor lock-in, the role of cloud broker and DevOps integrator is so strategic that they would never outsource it. The early and famous proponents of DevOps (Google, Facebook, Amazon) regard their systems development capability as a source of competitive advantage to be controlled and owned in its entirety. They may consider a build-operate-transfer contract whereby a service provider is engaged to construct a captive (in-sourced) operation faster than it could be built.
The effective application of DevOps demands the tight integration of many elements over multiple organisations, spanning the service lifecycle and every party involved in delivery. Such tight integration is hard to achieve, harder to maintain, and immensely disruptive to replace. Integration is hard to do, harder to measure and difficult to contract for. It requires an effective working environment and set of relationships. Trust is essential. DevOps is currently changing so rapidly that if you have contractual certainty on the day of signature, you have an inoperable straight-jacket a week later. Think Agile without a well-developed Scrum approach. Getting the governance and coordination model right will be challenging and will require a contractual annex defining the current architectural, tooling, data interchange and operational methods. This will change frequently and sometimes fundamentally. This can only ever be done under revision control, accepting that there will be costs of change. The salvation is that if you have multiple suppliers, the costs of change should be broadly similar for all within a category. Those seeking to exploit change will therefore be quickly identifiable.
The implementation of DevOps requires an extensive range of skills and disciplines all at once. Such transformation is challenging to achieve in any environment. Some start with tooling, only to discover that whilst necessary, this is far from sufficient and can lead to some dangerous weaknesses. You should be led by your strategy and business requirements, assembling services to support them and deliver these through tooling, contracts, processes, skills and staff. Get a good guide!
The prizes that make the application of DevOps worth pursuing include:
- The ability to accelerate the introduction of new functionality (combined with Agile, expect release schedules to go from months to days or even hours)
- Reduced operation support costs from automation (NoOps is an emerging line of practice)
- Increased application availability resulting from higher quality automated service testing and migration
- Increased commercial effectiveness from the ability to switch suppliers.
Of these, the key element is that of competing on time. The greatest take-up is seen in digital-driven strategies where there is the requirement to make frequent and rapid releases to test and exploit consumer preference. Some CIOs pursue it to exploit the cost advantages of automating work that requires highly paid systems administrators to do repetitive tasks.
DevOps is not the one source of all IT truth. It does have much to offer. Building it is difficult, costly, time-consuming. It does however offer radical improvement in the time to deliver new functionality that is valuable for anyone who competes in a time-critical market. It may not immediately be cheaper, but ultimately the elimination of delay and rework should pay dividends on the cost and revenue side too.