Shifting tectonic IT plates
This metaphor occurred to me on a recent trip to New Zealand, on the realisation that somebody made the mistake of positioning this otherwise admirable country right on top of a fault line. The Pacific plate is doing its best to push the Australian plate in a westerly direction but the latter is having nothing of it. The consequence is disruption, a word that, in comparison, we use frivolously in a business context. Nevertheless, I’m going to explore the theme in relationship to how the DevOps movement is accelerating the seemingly inevitable evolution of technology from valuable but unpredictable novelty to a state of dependable utility.
Disrupted by complacency
When people talk about disruption they often reference Clayton Christensen’s book The Innovator’s Dilemma. Christensen states that successful companies often put too much emphasis on their current customers’ needs, and fail to see the potential of new technologies or business models that, while often not attractive to their current customers, bring opportunities to develop new markets. He cites examples involving the emergence of personal computers, cheap Japanese cars, and steel minimills. In some cases (e.g. Kodak), enterprises are complacent in their success and are therefore surprised and disrupted when an emergent upstart has undermined the foundations on which the enterprise was built. Complacency is a topic that David Snowden addresses in his sense-making Cynefin model: suddenly you find yourself tumbling off the cliff between apparent stability and unpredictable chaos.
Christensen and Snowden have given me a better understanding of unexpected change and I also like Simon Wardley’s work on value maps. I first came across his thoughts in his presentation at OSCON 2010. He spoke about how technological development influences organizational strategy and development. After its initial genesis, technology evolves into a custom-built stage, followed by the emergence of standardized products and services, after which it enters its final stage of commodity and utility. The key point is being aware of where the various components of an enterprise are on this evolutionary spectrum, how fast and where they are moving, and how competitors and other parties in the ecosystem are positioned. With this knowledge, the enterprise can decide which components to develop themselves, which to buy as commercial products, and which to source as utility services.
When the DevOps dust settles
The DevOps movement places much value on automation, in particular in the technical practices of continuous integration, delivery and deployment. Many tools have emerged and are still emerging to fulfil the strong demand to support the fast flow of work from development through deployment while at the same time, delivering high quality operations. These tools are often used in combination with each other and are configured to the specific enterprise environment. In Wardley’s terms, this is a combination of products and custom built solutions, and is executed by the enterprise’s IT function rather than being outsourced to an external services provider. For the time being, with so much in DevOps still in development, this seems to be a justified choice. But when the dust settles and there are established industry practices for DevOps, it seems inevitable that these activities will be able to be provided by external providers in the form of standardized services.
Shifting tectonic IT plates
In terms of tectonics, the DevOps tooling plate will shift from the IT function to external service providers. The question arises where the future lies for the DevOps engineers in IT functions who, as a community, have developed a standardised way of working with standardised tooling. Many will ‘jump the fence’ and continue their careers at external service providers but neither will this prospect appeal to all of them, nor will all of them appeal to external services providers. In the IT function there will be a need for a sourcing capability that monitors the infrastructure services market, makes appropriate investments and fosters collaborative relationships between the IT function and the external service providers, and between the external service providers themselves. The substantive decision making will rely heavily on the IT function’s ability to assess the longer-term benefits, costs and risks of the various choices. This calls for an architect who oversees the major application components and infrastructure components and how they are interrelated. Some DevOps engineers will be suited to this role.
As a side note about the present rather than the future, there is already a strong need for architectural DevOps discipline. In the current dynamic climate with much experimentation with various tools and approaches, there is a risk of massive technical debt as a result of (in hindsight) wrong choices and the creation of artefacts that will be troublesome to maintain in the future – “containers and microservices seemed like such as good idea at the time…”
Mind the gap
Whereas the Pacific and Australian plates are colliding, the DevOps tooling plate is parting company from the application plate and joining forces with the infrastructure services plate. Many DevOps engineers will migrate to external service providers. Others will reinvent themselves within the IT function. Let’s hope that nobody ends up straddling two plates.
Further information (videos):