When DEV and OPS becomes DevOps

DevOps is a journey to agility. To understand where the challenges of DevOps come from it is worthwhile to review how and when both disciplines started. This is a short historical view with a spark of a way to minimize possible struggles.

where are we

If you today take a look from where Operations is coming there will be a mostly one “Framework” be mentioned along. ITIL¹…
And with that a number of reasons why we want to get to a better process.
It is important to understand, that ITIL in itself is not a framework but a conglomerate of best practices on how to organize IT Operations best.
Historically (what an awkward term in conjunction with IT) ITIL had been developed in the late 80’s. In its first iteration based on CCTA’s³ work it was a collection of 42 books – solely based on best practices on how to manage IT Infrastructure.
The late 80’s had also been the golden age of IT – At that time formal education in the IT domain was not existing, particularly in the operational space.
So, IT was a bit of pandoras box – someone opened it and now everything you wished for or not came out. IT was driven by will and wish, became a huge cost driver and was reducing its benefit as innovator massively.
The late 80’s to mid to end of the 90′ was also the time most of frameworks to steer IT had been born, like ITIL, six Sigma (for IT), CMMI and others.
Besides the wish to better structure and formalize IT Infrastructure Operations one driver was to better and rigidly control IT.
By this cost and uncontrolled growth had been one of the targets to be controlled and reduced.
Since then ITIL crystallised as the main Driver and Toolset to do IT Management. I hardly know any System Engineer without ITIL know how, nor any manager up to the COO³ Level.
Over time, the amount of underlying best practices has been reduced as well as the direction ITIL was pointing towards. Compared to v1 in the late 80′ the current most modern version v4 ITIL has evolved into a leaner, service-oriented collection that even recognises agile environments to a certain aspect.
Nevertheless, ITIL is still intact and rigidly used – especially in larger companies. From a global viewpoint it is fair to say that ITIL still is the thing in IT operations.

Amongst others ITIL is a collection of processes. One of them – and that forms the major difference to the DevOps world – the Change process. This process comes with structure, timelines and forms. So in ITIL based operations one is expected to produce things like a change description (as detailed as required to allow non Developers and System “Foreigners” to be able to understand), a detailed roll forward plan as well as a roll backward plan (detailed enough to identify all who, when and how’s). All this has to be presented to a CAB⁴ Meeting. Usually the CAB expects the input to come some time in advance. I have seen everything between four weeks and five workdays. The CAB will discuss all changes driven in to the respective time and will judge on impact, quality and sometimes necessity of the change.

All this sets a particular mindset operation is trapped in.

where does this agile come from

Over the years we did learn that our traditional waterfall model does not fit too well into some IT aspects. Most prominent here is Software Development. It took a long time and the birth of more and more complex systems to understand that a depicting all requirements for a software to be designed up front and push that into a rigid fall forward process is doomed to fail.
As ways out nowadays we do work in agile processes, which taught us to start with a vision only and develop along in smaller steps adhering to changes as well as enable appropriate and timely reactions to changing business requirements.

SCRUM for example – born out of manufacturing in 1986 – got its first formal footprint in 1996 as a new development process. It took until 2001 to get the Agile Manifesto being constructed as a base to the modern world of agile Software Development. It still took nearly nine more years until as the last step in this process the first Scrum Guide reached public.

Compared to the ITIL timeline it becomes obvious that ITIL had fully settled at that time.

Developers on the other hand did start to use agile development methods more and more to overcome the ancient issues brought by waterfall-ish process models. By this the development community did work more and more in small iterations but yet did not “deliver” in this agile style. The usual way in agile development was (and to a large extend still is) to use a dev internal SCRUM process. Iterate that on Development up to UAT⁵, but not into production.

This usually leads to a broken team – as one side is acting fully agile whereas the other side is imposing a standard Waterfall for project belongings and a fall forward ITIL driven Change Process. This is awkwardly enough a well settled scenario today.

culture clash

This segregated model leads to a couple of behaviors that counteract the idea of agility and DevOps in particular.

Development teams are still forced towards stiff development cycles. This usually leads to the inability of delivering changes timely or react on a changing world
Development teams with no understanding of operational necessities like SLA agreements, On Call and other duties.
Operation teams still feel the “over the fence” deployment style of the past. They are not part of the development process and usually don’t understand what has changed when, how and why.
Operation Teams who lack a view into changing requirements and two-year plan requirement.
The Business sits in either of the ends, either more as part of a shadow IT in direct relation with the Development or as part of a hierarchic culture at the end of the “IT food chain” as recipient of Operational Delivery.

Caused by this is a complete disconnect of understanding between – so far – both worlds. There are other side effects as well, like the typical financial controlling desire to plan and budget fixed prices for a fixed set of deliveries. All this also plays into the cultural clash, both company internally but also in the relationship between client companies and application development IT providers

Following the Gartner Hype cycle⁶ from mid 2018 we just entered the “trough of disillusionment”. It also rates DevOps as its plateau being reached in 2 to 5 years. This well nails where we are today.
Fun FactITIL is in the middle of the “slope of enlightenment” and also been envisioned as to be production ready in 2 to 5 years. Insofar reality, as ITIL v4 just sparks agile behaviour and by that todays (and more likely tomorrows) reality.

here we are

What we see more and more today is the first tryouts towards DevOps, which usually do extend Development Projects into Operations. Given what we have experienced historically this requires Development Teams to take on new behaviours and work styles. Most not liked usually is SLA responsibility and its derived duties.

Most often these DevOps “tryouts” come either with greenfield approaches or severe technology changes. But whatever the initiating factor is – they all interfere with existing structures and expected behaviours.

I personally see DevOps today reaching the valley of tears as the Development driven reach out into Operations comes with many misconceptions. What thrives me is the believe that this is all set already.

that’s the way

Following the above the by far largest work to do is going to be around Change Management⁷. Today we do have two major ways in approaching the wish to get DevOps off the ground.

have Development teams become DevOps teams and by that go the full mile into the operations space
Create a soft handover with a DevDevOps to DevOpsOps style. This is an operational style Google developed as SRE or [Site Reliability Engineering][8].

Which way to go heavily depends on criteria’s like company, project and team size as well as the willingness to become half operations and half development. For quite a lot developers I spoke with, the move into full operations has so many drawbacks that this is a “no-go, I quit” decision point. Not every developer can simply walk away, but this is creating unhappy employees, which creates difficulties to manage quality.
Another “no way” into full scale DevOps is the leverage of external developers, be it freelancer or small Dev Company.

I do come from a corporate background – where operations do serve dozens to hundreds of systems. Hence my natural drive would be towards SRE. But I would not want to limit myself towards this large scale only view.

Another often taken angle is to reduce DevOps down to tooling. An often-used way to depict DevOps is the laying eight with a gazillion tools surrounding it. I myself try to follow the idea behind the saying: A fool with a tool is still a fool. Tooling helps and is a valid way to enforce particular behaviours. But it still needs enablement for developers and operation folks to embrace the upcoming changes.
The second aspect on today’s DevOps toolchain is its derivement out of pure development. By no means this does support operational support at a maturity level we currently have in operations.
The good thing here is, that this is enabling the Change Management to join Dev and Ops to start not only merging tools and technologies, but also enable a vice versa view on expected requirements.

There is a small list of first steps I encourage to follow:

- setup a change management team with an equal representation of Dev, Ops and Business as well as a SCRUM Master (or an equivalent to the respective agile model used)
- to be clear on the overall going forward model and its implications / any hiding will bite at a time

This entails that given the way selected, may mean Developers to do on call duties and operate something on the long run, or to enable Operations People to switch into the development world to some extent, and so on.

to be clear on operational requirements as well as development requirements
allow sufficient time on tool selection and have Operations a play in this
define a way to integrate required ITIL (or similar) requirements into the selected Agile model
embrace nonfunctional requirements into the Development Process (e.g. SOX, FSAP, Security …)

This should form a first step into your successful DevOps future. This also shows, that we are still on our way into the future. It has yet to be seen how the move to DevOps will materialize in a standardised way – if at all.

notes

^{1. ITIL –> Information Technology Infrastructure Library, is a set of detailed practices for IT service management (ITSM) that focuses on aligning IT services with the needs of business.↩}
^{2. CCTA –> The Central Computer and Telecommunications Agency (CCTA) was a UK government agency providing computer and telecoms support to government departments. Founded 1957, during the late 1990s, its strategic role was eroded by the Cabinet Office’s Central IT Unit (CITU), and in 2000 CCTA was fully subsumed into the Office of Government Commerce (OGC).↩}
^{3. COO –> Chief Operating Officer↩}
^{4. CAB –> Change Advisory Board↩}
^{5. UAT –> User Acceptance Testing↩}
^{6. Gartner Hype Cycle ICT 2018 https://xebia.com/news/stackstate-recognized-as-a-key-aiops-vendor-in-gartners-hype-cycle-for-ict-2018 ↩}
^{7. Change Management in opposite to Management of Change (MOC) is to deal with the people side of changes. MOC serves only technical purposes.↩}
^{8. Google SRE https://landing.google.com/sre/ ↩}