In the early 2000s I had the opportunity to work on a truly greenfield project. This was a once or twice in a career chance to create a system from scratch, something I had always wanted to be a part of.
The project involved creating a system to help the client’s trademark licensing group manage their contract workflow and article tracking better. At the point the project was initiated they only had a simple document management system for contracts which was not dynamic enough to support the state of the business process at present or as planned for the future.
Luckily for the team, a forward thinking project manager was assigned to lead the effort. He put together a cross-functional technical team including business analysts, application architects, application developers, DBAs, infrastructure engineers and application testers. In addition to the technical resources the team enjoyed a full-time business resource and other part-time business resources assigned to the project. This group had the grand opportunity to create a new way to work and the system to support it together as one team.
The team in its entirety consisted of about 12 people. Most of the team sat and worked together daily in a team room. What made this work arrangement amazing was that everyone really understood the goals and would work together, bringing whatever their speciality area was to bear on the problem at hand.
An example of the collaboration was during changes to a particular use case that the business people and the analysts had beed discussing. They brought it up in the team room with the application architects, DBA and infrastructure architects present. Basically what they wanted was to store documents along with meta-data in the system to be tracked through the workflows. Of course the business people do not state problems that way. They say things like “it would be nice if I could get to the information I need about X on one screen”.
What happened after that was the architects, developers, DBA and infrastructure engineers got together to discuss ways to deal with the requirement. What emerged from the discussion and whiteboard drawings was a design and a plan for execution that included changes for the application code, the database and the server infrastructure. Changes were needed on all three areas in order to realize the functionality proposed to satisfy the modified use case.
We did all this with the business user in the room. She asked questions as she wanted to and was comfortable with the design even though the technical details may have been outside her domain of understanding.
The next day the infrastructure changes had been made. The DBA was able to make his changes later that same day and the programmers already had prototypes of the functionality working by the second day. This friends, is agile development. To us it was common sense development. At the time we lacked a catchy name for it.
Not only is this agile development, it also embodies some of the key tenants of DevOps. DevOps is more than just a different way to execute operations in cloud environments like Amazon Web Services (AWS) or Google Cloud. DevOps is a cultural change to how developers and infrastructure operations communicate and work together.
Aided by advances in resource virtualization, templating and automation, DevOps culture combined with modern application and infrastructure technology greatly accelerates the ability of teams to deliver change to software systems. This change can not only be delivered faster but also with less errors.
Taking all this into consideration we can now examine the concept of outsourcing DevOps. Since DevOps manifests in a convergence of culture, methodology and tools it seems that the idea of outsourcing DevOps is a bit misplaced. If, for example, an organization decides to utilize cloud services such as AWS and the same organization chooses to hire a service provider (outsourcer) to manage the AWS environment for them then this is not really outsourcing DevOps. This situation is really just outsourcing infrastructure operations.
To get the most benefit out of DevOps the approach needs to be holistically applied across culture, methods, tools and the organization as it is this convergence that delivers the value. It is the whole greater than the sum of its parts. Outsourcing operations functions can make sense in some scenarios however, it needs to be carefully considered as a tactic that could move the organization towards its strategic goals of delivering more software, more often with consistent quality.