Enterprise DevOps: An Introduction

This is the first in a series of blogs about various enterprise DevOps topics. 

Let us assume that if you are reading this blog you are either interested in, or in the process of, rolling out a DevOps initiative across an enterprise. Further, if that is the case, you wish to successfully embed DevOps into the DNA of your enterprise and leave a legacy. In our view, those companies who have made a success of DevOps have recognized it involves cultural change across the organization and not merely the latest in a line of initiatives driven from the Head Office.

That said, your management will have objectives and a reward structure in place and it is critical you understand this if you are to be successful in the short term. You could consider delivering any transformational program as being similar to sailing into the wind. You can't head straight to your destination but must tack. You need to know your ultimate destination, but you also need to know that which needs to be delivered for your key stakeholders - which may not strictly be strategic.

We should also state that we have a very simple personal definition of DevOps and it is focused on outcomes, not capabilities. Successful DevOps provides the ability to deliver discrete technical artifacts rapidly to production to drive value to your business.

Nigel will now wind the clock back over twenty years to his early days in the industry:

When I started work, there was a small team of us sitting together around a bank of desks. We had someone who represented the business, somebody who wrote the screens (albeit old 3270 green screens for branch staff), a developer, an individual who wrote the functional specifications, someone who wrote the technical design specifications, and a tester. The individual writing the screens would ask the business representative to wander round the desk and check if the green screen looked how they wanted it to look.

Before any of us knew the correct taxonomy, we exhibited several of the characteristics of Agile and DevOps, albeit with none of the automation. In addition, the assets we delivered were more monolithic and cadence was far lower than would be acceptable today.

So, what happened?

• Business engagement (or lack thereof): A colleague once said to me, "First the business moved us into the basement, then into another building, then another city, and finally another continent." In many companies, IT lost contact with our business and became a cost center that delivered solutions rather than being a close partner. It is critical that those of us in technology become better at communicating with our business and understand what the asset we are accountable for does in their eyes. I see far too many technologists with little business contextual awareness.
• Silo-ization: Within larger enterprises, there was a move to mono-skilled pools. A large pool of developers, a pool of testers, a pool of business analysts, a pool of DBA's and so forth. This moved us away from a product to a project approach, with a pool of labor brought together for a specific task. I lived through this process and know that it was driven by IT itself, or at least by CFOs within the IT part of the organization. The rationale came from the idea that product teams sometimes had downtime when demand for new features was not pressing. By creating pools of labor, the IT organization could react more rapidly to business priorities.

Why should you care about the history above?

"Those who don't know history are doomed to repeat it" - Edmund Burke

It is our belief that anybody commencing a DevOps initiative should be aware of why similar ways of working previously were abandoned and take steps to ensure those challenges are recognized and mitigated against as the DevOps program gears up. It is imperative that the business is fully engaged and committed as key stakeholders in the value that can be gained from DevOps. You need to avoid the view of IT being a cost and ensure that you can clearly articulate value. Ideally, your business should start to articulate the value they see from DevOps to others.

Additionally, if your company previously moved into silos, an awareness of the rationale behind this is crucial. For example, look to put a process in place to identify when business demand for product enhancements starts to increase or decrease to ensure you avoid the perception that resources are not being optimized.

In short, we would recommend before you start to transform your organization you must:

• Understand what outcomes you are trying to achieve.
• Understand what objectives your board has, and identify which short-term objectives add risk to the long-term strategy.
• Understand why your company looks like it does now, how you got here, and what motivators led to the current culture and environment.

We intend to look at some of the other challenges and learning points in future posts.