Buy or Build
Throughout the history of IT, businesses have been purchasing application development. As we all know, the two basic models for such purchasing has been either to specify the required results or the required resources. Being just another way of stating the eternal question of “Buy or Build”, choosing between these two models will always involve a mixture of strategic, tactical and operational considerations.
Our ambition here is not to examine all these considerations. However, a couple of them should be mentioned.
Firstly, the question about uncertainty and risk: Every purchasing department with self-respect will include reducing the company’s uncertainty and risk as important effects of their work. Consequently, when they look at purchasing models, their lenses will automatically focus on how the various models distribute the responsibility for risks and uncertainties between the customer and the supplier. Seen from this perspective, specifying the result will always be more attractive than specifying the resources.
Secondly, the rate of change. When specifying the result, there is an implicit premise that the business situation will be the same when you start using the result as it was when you specified it. If changes have happened between those two points of time, making parts of the specifications obsolete, the result – the application – will also become more or less obsolete. A mixture of strategic importance and rate of change has thus been sound justifications for specifying resources instead of results, implying that having control of the total development process allows for easier adjustments to changing requirements.
Such is the situation; specifications might become obsolete. We have seen that this is true when specifying the result, but is it also a relevant consideration when specifying the resources?
Increasing the speed, blurring the boundaries between Dev and Ops
Back in 2009 Patrick Debois, an independent IT operations consultant, was working on a data centre migration project for the Belgian authorities. When cooperating with agile development teams he saw the difference in productivity between the way his colleagues worked with operational issues according to traditional project models and the way the developers worked when creating code in agile teams. This experience led him to arrange the first “DevOps days” where development and operations could come together to discuss common challenges. Through the way he named this conference, he also accidentally coined the term “DevOps”.
The rest is history. Moving from the original idea of using agile principles both for system development and operations, DevOps have developed into a new way of looking at the total landscape of development and operations. New tools and new practices have been created to ensure high quality while reducing the time between producing changed code to a system and placing the change into normal production.
DevOps has not just opened the communication between development and operations, it has blurred the traditional boundaries between the two subject areas and their corresponding competencies – just think of the slogan “You build it – you run it” versus the traditional formalities and division of responsibilities between development and operations.
These changes have of course affected the two initial models for purchasing application development, too. By integrating competencies in new ways and thus increasing the speed in software production, agile and DevOps has changed the traditional way of specifying the result. When earlier the requirement specification was supposed to contain an exhaustive list of all requirements to the application in question, agile-oriented system requirements are concentrating on the mission and the overriding effects of the system. Requirements regarding specific features are stated as high-level epics which are far from traditional, detailed and testable requirements.
One challenge, seen from the purchasing department’s point of view, is that this change has altered the balance of uncertainty and risk between the parties, moving a greater part of the risk from the supplier towards the customer.
To allow for a more even distribution of risk and uncertainty between customer and supplier, the focus has turned to the requirements for resources. Could these requirements be stated in a way more suitable for the new situation, and perhaps giving the supplier a more defined responsibility for the outcome?
Introducing DASA, clearing the boundaries between seniors and old-timers
Waterfall project methodologies is based on allowing resources from different subject areas to produce their part of the end-result without having to involve themselves with other subject areas more than absolutely necessary. Specifying resources for such projects can therefore be focused primarily on the subject area in question and the number of years being spent working there.
Thus, we get the traditional role requirements we all know so well: Junior: less than X years of experience, senior: X to Y years of experience, and expert: more than y years of experience within the subject area. Add some requirements regarding formal education as well as knowledge to specific tools and that’s it.
The world of DevOps is different. You are no longer awarded just for justs having stayed in your cell, studying your own holy scriptures. A narrow-minded “expert” without a broader perspective might actually become counter-productive in a cross-functional team. DevOps require working together with other people and meeting other subject areas’ perspectives. Requirements for DevOps resources should reflect that fact. But how should such requirements be stated and what are the general competency areas needed in a DevOps team?
Our answer is: Look to DASA!
DASA (DevOps Agile Skills Association) is an independent and open, members driven association supporting the development of DevOps training and certification to the global market, advocating the development of High-Performance IT Professionals and Teams through agile DevOps initiatives.
Among the resources developed by DASA is their maturity model introducing DASA’s twelve skills and knowledge areas as well as a general five-step maturity model defining requirements for the level of maturity for each of the twelve areas.
Through Infocom Group’s partnership with DASA as a DASA Forerunner and in cooperation with some of our clients, we have had the opportunity to use DASA’s maturity model to develop a tool-set for contractual requirements regarding DevOps specific resources.
One of the strategic strengths of the tool-set is that it applies for teams as well as for individuals. In addition to allow for stating DevOps specific requirements for traditional consulting roles, our tool-set based on DASA’s model for skills and knowledge areas also offer a possibility to define a competency profile for the total team, thus giving the customer the opportunity to set requirements for a full DevOps team and give the supplier the contractual responsibility to ensure that the team’s total competency at any time fulfils these requirements.
An additional effect is by combining the tool-set with suitable contractual provisions, the parties can periodically adjust the requirements for the team’s competency profile in order to align it with the tasks and challenges that they will be facing in the next delivery phase.
Remember, in days of rapid changes, it is possible to be an old-timer without being a senior as well as being a senior without being an old-timer.