The combination of DevOps and agile application development is rapidly gaining in popularity. In the current market, most organizations cannot afford to deliver software that customers do not like, is buggy or is delivered late. DevOps is shaking things up by breaking through the traditional divide between development and operations teams. And agile development methods are used to develop and deliver new functionality in multiple short cycles (sprints) on new technical platforms, such as containers and hyper-converged infrastructure. This combination makes it possible to add more value to the business processes of organizations in terms of higher quality, short times-to-market and optimization of the total cost of ownership.
To benefit from these, managers must be prepared to challenge their current organizational form, even if this means that their ‘domain’ will shrink or drastically change. DevOps is a portmanteau of Development and IT Operations. The emphasis is on communication, collaboration (between customers, software developers and IT operations) and integration, drawing on the thinking of Agile and Lean IT. It will come as no surprise that the emergence of DevOps in combination with agile application development (for the sake of ease, jointly referred to as DevOps in this article) will also have an impact on outsourcing.
Executives would be wise to pause and take stock of the consequences that this will have on outsourcing. Strategic principles relating to the scoping process and contracting method of infrastructure services and application development, for instance, are different. And this has an impact on both outsourcers and vendors alike. This article takes a more in-depth look at the impact and offers some concrete guidelines.
DevOps has a major impact on the scoping process, which is determined during decision-making on the sourcing strategy. In qualitative and financial terms, this sourcing strategy will only be future-proof if IT services, applications and infrastructure are insourced and outsourced in accordance with a well thought-out scoping process, with enterprise architecture as a benchmark. Many large organizations and government bodies have traditionally chosen a stovepipe approach to scoping, in search, as it were, of benefits of scale and clearly defined delimitation of responsibilities. In this horizontal form of scoping, application development, application management and infrastructure services (hosting) are often split into three lots and awarded to different vendors, and ultimately the service desk, work station and security & connectivity form separate lots. Technical application management was often allotted to the infrastructure service provider in order to contract for end-to-end application availability with that vendor. The transfer of a new application release from the application provider to the infrastructure provider then had formal gateways added to it. This was necessary if the infrastructure provider wanted to be able to guarantee application availability and did not want their bonus to be affected. And this sometimes left the customer waiting for months for the latest release.
DevOps and Agile break through this traditional stovepipe demarcation between development and operations, applications and infrastructure. DevOps is primarily used in innovative environments where short-cycle change is desirable in the business to effectively deal with high levels of competition, a growth market, high visibility or high levels of business dynamics. In stable legacy environments, the waterfall approach is often used. A large organization will probably have traditional waterfall teams as well as DevOps teams. A modern catalog of products and services should facilitate deployment of both alongside each other. DevOps introduces a vertical form of scoping (‘value stream’) which has consequences for the deployment of DevOps teams, discussed in more detail below.
Business System teams
DevOps tackles application development and management, databases and middleware through an integrated approach per functionally oriented domain (‘value stream’). Outsourcing in these areas is delivered by self-organizing, multi-disciplinary teams working in ‘scrums’. The members of these teams share responsibility for delivery of the results. Each team has a product owner who holds lead responsibility for the functional result. The scrum master is responsible for the process, the speed of delivery, and for providing and maintaining oversight and reflection. The structure of the competencies of the team can be visually represented as a T, in other words the team is experienced and has team members with many competencies. Members are able to look beyond their own discipline. In this process, architects aim to pay down the technical debt. This often arises from organically occurring designs and construction under intense pressure (fix now, pay later), which caused deviations from architectural standards, interfaces, etc. Technical debt can have a crippling effect, so that the required speed of the sprints is not achieved.
You built it, you run it
Technical application management (database management, middleware), traditionally the responsibility of the infrastructure provider, ideally comes under the umbrella of the Business System team under a motto of ‘you built it, you run it’. While in practice, we also observe a variant in which this activity is still managed by the platform team, which then provides lifecycle management of the entire technical stack including the middleware, these days teams achieve this by deploying containers and hyper-converged infrastructure. Of course, the Business System team also uses highly standardized infrastructural platform services (the technical stack). These are selected based on their value for the team. Traditionally, most business applications are hosted within a private cloud service, while development and testing environments are more commonly hosted within a public cloud service. A shift is clearly visible: public cloud services are increasingly being used even for production environments.
Principles of DevOps teams
When DevOps teams, often comprised of internal and external employees, start working closely together with customers to continually deliver functionality through agile application development, this constitutes a completely different way of sourcing than, say, offshoring large waterfall projects. DevOps teams espouse the following principles.
The platform team offers a standardized environment. This is preferably comprised of PaaS containers, although IaaS is a viable alternative. This environment can be complemented by options for orchestration of the cloud management platform when public cloud services are used. Monitoring of standardization is an important task for this team. Exceptions lead to mistakes, require separate management and cost money. For the same reasons, ‘automation wherever possible’ is always on the agenda. Accurate cost allocation is indispensable because the Business System team works with infrastructure environments based on self-service. This promotes the cleanliness of the environment after use, so that the meter does not continue to run. To make good collaboration possible, the platform team has a representative in the Business System team, entirely in the spirit of DevOps. This also aims to guarantee accurate coordination with the sprint pace of the Business System team so that final delivery of the new functionality comes within reach without waiting times (single piece flow). With the adoption of DevOps, the service catalog needs some fresh ingredients, such as new tools to make the life of the DevOps team easier. This may include a self-service portal, tools for ongoing integration of systems, automated testing, automated implementation and automated delivery. This serves to enforce standards for DTAP streets in order to limit the technical debt from the platform team as far as possible. This includes patch management, for instance.
The impact on the scoping process and the team focus is clear. How will this affect the contracting? If organizations wish to do justice to DevOps and Agile, they will have to change the way contracting works. The most important aspect is the shift from closed-scope contracting to open-scope contracting, where innovation and operations have to find a space in the same partnership. DevOps teams cannot easily handle usual methods of contracting at all. DevOps in combination with agile application development does not come with a fixed scope, but uses a different approach to scoping aimed at value generation and moves in line with changing insights of the customer. Compare this to the traditional scope definitions and comprehensive descriptions of functional and technical designs, result-oriented service descriptions, responsibilities and tools. The working method is based on a more or less static situation and a controlled process, not on a continually changing market that the customer wishes to respond to today. If you want to be the world champion in Formula 1, it is impossible to plan your race in advance, and your car will need modification between races. This is a fundamental point. We offer some guidelines.
Business System teams
If you want to be successful in sourcing partnerships, you must define the relationship based on the cone of uncertainty (see Figure 1). Basically, the customer and the vendor ultimately adopt their own position when a service is contracted. This position is determined, among other things, by the degree of uncertainty that you perceive. The degree of uncertainty can be determined based on the answers to four questions.
If the perceived risk is too high, uncertainty means that the customer and vendor will not quickly agree on a contract price. If risk is high, a vendor will build in a high risk margin (contingency mark-up) from the outset in anticipation of the negotiations. From the customer’s perspective, this is an undesirable outcome. On the other hand, contracting based on time and materials often feels like a blank check, with the customer carrying all the risks. This dilemma could result in an unbalanced contract relationship and will lead to undesirable behavior in the intended cooperation between the customer and the vendor (negotiation instead of cooperation).
DevOps contracting is a form of contracting which the customer and vendor grow into together. What’s more, KPIs are directly related to future business as a direct translation of business value. Examples from practical experience include the shortening of the lead times of a business process, an increase in conversion ratio (from lead to customer) and an increase in the net promotor score.
In the infrastructure domain, there are not many changes in terms of contracting, apart from an expansion of the service catalog with all kinds of tooling and metering. This becomes a part of an integrated dashboard that is also fully visible for the Business System teams. For utility infrastructure, pricing is per unit, entirely dependent on use, the technology and the grade of the corresponding utility. This allows for maximum scalability (up or down) based on pricing per unit, without applying pricing bandwidths or guaranteed purchase volumes. For infrastructure projects, a tariff sheet per profile/man-hour is also contracted, making it possible to calculate fixed prices for infrastructure projects. Fees for tooling are separate, sometimes per corporate license, sometimes based on numbers of users. Sometimes these costs are already included in the utility being paid for. It goes without saying here that the financial drivers are in place to enforce the required standardization. In the transition and transformation phase, we still often see fixed prices per sub-project, for migrations, transformations, transfers of personnel, harmonization costs, etc.
How will this all affect the SLA? Well, it will certainly look a lot different. There will be a move towards Business System team SLAs, based on entirely different principles. DevOps is about creating enduring customer value based on an open, redefinable scope in contrast to the closed scope of traditional SLAs. The focus in DevOps is much more on minimizing the time-to-market of new features, the contribution to end-to-end business KPIs, minimizing the mean time to repair & recover, and the technical debt incurred. Monthly reporting is already outmoded, with real-time monitoring now the norm. Where reporting is still done, these reports are much lighter and more frequent than previous monthly reviews common in traditional SLAs. With a sprint cycle of two weeks, a monthly report is already two iterations behind. The SLA and corresponding KPIs are in line with the cone of uncertainty, but not merely with the aim of imposing restrictions or penalties. KPIs also contribute to the three basic goals: optimizing the result (quality, time-to-market, business value), optimizing the financial aspects (costs and added value) and reducing the risks.
Finally, the customer and vendor find themselves in the same boat. The strong combination of DevOps and agile development is concerned with managing the partnership, not about controlling a vendor. From this perspective, a KPI for the customer is indispensable: lead time to decide. The flow in the teams must be guaranteed: a dithering customer will immediately be a drag on the entire team.
DevOps and Agile have a considerable impact on the scoping process in outsourcing, how we approach contracting and the collaboration models. Underestimating this will result in a mismatch between the efforts made in outsourcing as well as the added value of DevOps and Agile. These teams cannot handle the way in which the world of sourcing traditionally approaches contracting. Organizations would do well to anticipate what DevOps and agile sourcing will need in order to prepare for the world of … today.
About the authors
Frank de Vries and Pamela Verkijk are both consultants at Quint Wellington Redwood.