Over a million developers have joined DZone.

Why Develop-Operate-Transition Projects Need to Get the DevOps Treatment

DZone's Guide to

Why Develop-Operate-Transition Projects Need to Get the DevOps Treatment

Could the popular Develop-Operate-Transition construct use some updating? Maybe borrow a bit from DevOps? Read on to find out more.

· DevOps Zone ·
Free Resource

Best practices for getting to continuous deployment faster and with dramatic results in reduced outage minutes, development costs, and QA testing cycles. Brought to you by Rainforest QA.

The DevOps movement has focused the IT industry on breaking down silos and increase collaboration across the different IT functions. There are popular commercial constructs that did a great job in the past but which are not appropriate for DevOps aligned delivery models. A while ago I talked about the focus on Average Daily Rate, in this post I want to discuss how to change the popular Develop-Operate-Transition (DOT) construct.

Let’s look at the intent behind the DOT construct. The profile of work usually changes over time for a specific system and idealized looks like this:

  • During Development the team needs to be large and deal with complex requirements, new problems need to be solved as the solution evolves.
  • During Operate the changes are smaller, the application is relatively stable, and changes are not very complex.
  • At some stage the application stabilizes and changes are rare and of low complexity.
  • Then, the lifecycle finishes when applications are being decommissioned (and yes we are not really good at decommissioning applications, somehow we hang onto old systems for way too long. But for the sake of argument let’s assume we do decommission systems).

As an organization it is quite common to respond to this with a rather obvious answer:

  • During development we engage a team of highly skilled IT workers who can deal with the complexity of building a new system from scratch, and we will pay premium rates for this service.
  • During Operate we are looking for a ‘commodity’ partner as the work is less complex now and cost-effective labor can be leveraged to reduce the cost profile.
  • As the application further stabilizes or usage is reduced we prefer to take control of the system to use our in-house capabilities.

So far so obvious.

If we look at this construct from a DevOps perspective it becomes clear that this construct is sub-optimal as we have two handover points. In the worst case these are between different organizations with different skills and cultures. I have seen examples where applications stopped working once one vendor left the building because some intangible knowledge did not get transitioned to the new vendor. It is also understandable if the Development vendor focuses on aspects that are required to deliver the initial version and less focused on how to keep it running and how to change it after it goes live while the operate vendor cares a lot about those aspects and would rather compromise on scope.

Now we could try to write really detailed contracts to prevent this from happening. I doubt that we could cover it completely in a contract, or at least the contract would become way too extensive and complicated.

What is the alternative you ask? Let’s look at a slight variation:


Here the company is involved from the beginning and is building up some level of internal IP as the solution is being built out. In a time where IT is critical for business success I think it is important to build some level of internal IP about the systems you use to support your business. In this new type of arrangement, in the beginning the partner is providing significant additional capabilities, yet the early involvement of both the company itself and the application outsourcing partner makes sure all things are considered and everyone is on board with the trade-offs that are being made during delivery of the initial project.

Once the implementation is complete, a part of the team continues to operate the system in production and makes any necessary changes as required and any additional smaller enhancements. If and when the company chooses to take the application completely back in-house, it is possible to do so as the existing people can continue and capabilities can be augmented in-house as required. While there will still be some handover activities, the continuous involvement of people makes the process a lot less risky and provides continuity across the different transitions.

Of course, having a partner for both implementation and operation is a much better proposition as this will further reduce the fraction. I have now worked on a couple of deals like that and really like that model, as it allows for long-term planning and partnership between the two organizations.

Most people I spoke with found this quite an intuitive model, so hopefully we will see more of these engagements in the future.

Discover how to optimize your DevOps workflows with our on-demand QA solution, brought to you in partnership with Rainforest QA.

outsourcing ,devops ,model ,projects

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}