DEVOPSdigest

In the coming weeks, I'll be working with EMA analyst Steve Hendrick, to gather data on what we believe is a unique research topic — approaching DevOps initiatives from the perspectives of all key constituents. We're doing this to try to break through some of the "false walls" created by more niche, market-defined insights, or some of our industry hyperbole (e.g. in the "No-Ops" vein).

Here are some of the directions we're pursuing. And I welcome your thoughts, questions, and reactions.

Who's Really Involved?

First of all, we'll be canvassing multiple types of respondents, all of whom different pieces of the total DevOps picture, and all of whom may well view it from different perspectives.

Naturally we'll be looking at development teams. But we'll also be looking at operations, IT service management (ITSM) teams, and IT executives. We may even be able to bore into unique roles such as "data scientist" or "architect" or of course "site reliability engineer," or more broadly "application support," or "network management."

Rather than seeking to reveal a ladder in which forward progress can be measured linearly, step-by-step, what we're hoping to discover is, to put it perhaps a bit romantically, is a landscape of possibilities. Possibilities for forward progress of course, but also, as we expect, a myriad of possibilities for disruption, confusion and failure.

What's Driving DevOps Initiatives?

What executives look for in DevOps initiatives versus hands-on development may well turn out to be very different here. Or we may be surprised to discover significant areas of overlap.

Is what's driving DevOps, for instance (just a few examples):

■ Speed in delivering new applications?

■ Speed in updating existing applications?

■ Business competitiveness?

■ Coping with/optimizing cloud?

■ All of the above?

Or, we may infer, is it actually more politically driven than value-driven with clear metrics in some IT organizations?

What Activities Are Most Pervasive/Most Critical/Most Promising?

Once again, we'll be looking at a carefully assembled list of key activities, and mapping them against areas such as role, success rates, company size, organizational model … fill in the blank.

These activities will range from:

■ early-on requirements assessments initial design

■ and CI/CD early in the application lifecycle

■ to end-user experience analysis prior to production

■ and in production, and service level management and performance management for application performance and security.

How About Best Practices?

As you can imagine, best practices will often depend on who you're talking to, often coming from very different best-practice traditions. But for an effective DevOps initiative, shouldn't there be a clear and guiding handshake?

We'll be testing our roles against a wide ranging list:

■ from Value Stream Management

■ to Scrum

■ to the Scaled Agile Framework (SAFe) on the one hand

■ to the IT Infrastructure Library (ITIL)

■ Kanban

■ ISO 27001/2 and

■ IT Balanced Scorecard on the other hand, just to name a few.

And How Are Technologies from Both Sides of the Fence Coming Together?

This is a question with many dimensions, partly because once you add Ops to Dev (with an eye to Security) the options for relevant toolsets become enormous. This, of course, is both a good and a bad thing, because the while the range of options optimizes choice, it does little in itself to promote common ground and common insights.

We want to know what technologies are in place, and which are among the most unifying — whether it's:

■ Dev/test environment creation & management

■ or release orchestration

■ or AIOps and advanced analytics

■ or IT project and portfolio management

Once again, just to cite a few examples.

What About Roadblocks and Disconnects?

Given the mosaic of roles, needs, accelerating expectations, and potentially fragile levels of collaboration, the list is long here as well. Moreover, we will be very eager to see if each constituency views the roadblocks to DevOps effectiveness with a common pair of eyes, or if the view of problems awaiting is as divergent as IT titles and histories might predict.

For instance, are the added volumes of application changes causing disruptions in operations?

Are ITSM teams cut off, or becoming more centered in the process?

Is senior IT management living in a "dream world" of expectations?

I'm sure you can go forward and fill in many more blanks.

And yes, we'll be looking at organizational models, success indicators and success rates, tracking these across this very much evolving, and increasingly hyped and politicized DevOps landscape.

I look forward to sharing some of our top-level findings in Q2 when all our data is in. But in the meantime, I welcome your thoughts and questions. What would you like to know? Or conversely, What do you believe to be the case in you own IT environment?

Feel free to contact me with your ideas and questions.