In an earlier blog post we talked about the classical economic theories of Adam Smith and how they applied to DevOps (particularly the role of “generalists” and “specialists” with DevOps teams).
In this post we’re going to talk about the work of Ronald Coase on transactions costs and the “Nature of the Firm” and why this is relevant to how & why the DevOps approach works.
“In order to carry out a market transaction it is necessary to discover who it is that one wishes to deal with, to conduct negotiations leading up to a bargain, to draw up the contract, to undertake the inspection needed to make sure that the terms of the contract are being observed, and so on.”Ronald Coase
One of the key tenets of DevOps is to try and remove the “silos” that exist in “traditional” IT departments but in order to remove these “silos” we need to understand how&why they exist in the first place.
In 1937 Coase published the “Nature of the Firm” which examined some of these issues in the context of why certain activities were taking place within the boundaries of an organisation as opposed to by external suppliers (and also why certain activities need to be undertaken by governments in order for the market to work effectively).
Where do we “draw the line” between what’s economically viable to do “in-house” as opposed to “subcontracting out”? In IT terms this can be seen as analogous to the “buy vs build” decision when it comes to COTS software.
Coase postulated 6 “transaction costs” that influenced this decision, and where you drew the “boundary of the firm” depended on the your desire to minimise these supply costs for that particular service or product (and hence to maximise YOUR profits for the output of your value –added activity that was built on top of these base costs).
Search and information costs are costs such as those incurred in determining that the required good is available on the market, which has the lowest price, etc.
Bargaining costs are the costs required to come to an acceptable agreement with the other party to the transaction, drawing up an appropriate contract and so on.
Policing and enforcement costs are the costs of making sure the other party sticks to the terms of the contract, and taking appropriate action (often through the legal system) if this turns out not to be the case.Source – Wikipedia
If we examine many of the current trends in both business and IT it’s clear that these cost are (consciously or unconsciously) the target for many of the new products and services we see in the market.
- Googles entire business model is based on LOWERING search and information costs (even more so with services like Google Shopper that enable you to very quickly find information on products and prices). Lowering the “information asymmetry” between buyer and seller generally optimises the price.
- eBay and Etsy also directly attack these costs – they collect items into a market so that lowers search and information costs, they set very clear policies (“contracts”) regarding prices etc, offer policing and enforcement mechanism in the case of disputes and generally guarantee payment via the use of escrow systems etc.
- virtual workforce websites like elance.com or 99designs.com do the same for services – they create an efficient market where you can find the skills you require within a framework that lowers your risk and minimises these transaction costs.
So how does this apply to silos within at IT organisation and DevOps transformation?
Well, if we shrink our definition of the “firm” down to the IT department we can see how silos can form.
For example, if you want some DBA expertise it lowers search costs if you can just say “go see the DBA team over there” (silo). You can define clear processes to request and interact with that silo (lowers bargaining costs) and all the DBA’s report to a common line manager so when it comes to “policing and enforcement” you have a clear route to complain. It also makes life easier for the DBA’s in that they lower their internal “search costs” when it comes to sharing knowledge, information, workload etc.
So what is DevOps trying to change?
Well, DevOps postulates that creating silos based on expertise is ultimately inefficient when seen from the perspective of a building a customer product. It might be efficient for the DBA’s but these silos don’t scale very well.
In order to build a “product” I need DBA’s, systems administrators, business analysts, developers (of various flavours), testers etc etc. If all of these exist in silos, surrounded by processes, my transaction costs increase to a point where my “boundary of the firm” from the perspective of the product team has grown so high that it makes sense for me to redraw my boundary to have those skills “in-house”.
This is the essence of DevOps – we re-draw the boundaries to create cross-functional teams to reduce transaction costs within that (product) team.
Search and Information costs trend to zero because it’s not some remote person in another silo… the expertise I need is across the desk from me, interacting with me every day via our Scrum or Kanban processes.
Bargaining costs become personal, not abstract – as a team we are committing to our shared goals without the need for reams of formal processes.
Policing and enforcement likewise become social and transparent – if someone isn’t contributing or delivering on their promises then this rapidly becomes apparent to the rest of the DevOps team and social pressures start to come to bear to align their behaviour with the groups agreed goals.
Similarly from the “external” perspective to our “DevOps firm” if we have a problem with Product X its clear where the responsibility lies – with the DevOps team that owns that product – and not diffused across multiple silos (Dev, Ops, etc) who can “point the finger” at the other team as the “root cause”. For many organisations the time wasted in defining & executing “problem management” processes to solve this “enforcement cost problem” to find out who is responsible for fixing a problem are immense.
Viewing DevOps from economics perspective starts to give us a framework to understand why the empirical benefits we see in organisations that have adopted DevOps principles are created, which ultimately gives us clearer insight into how & why to implement DevOps.