Don’t let AIOps be CMDB All Over Again!

In February of 2009, Glenn O’Donnell (VP, Research Director) and I co-authored the CMDB Imperative when ITIL and ITSM were all the rage. Underpinning that rage was the Configuration Management DB (CMDB) which promised to deliver world peace like a pageant winner during the interview portion of the competition. Nearly thirteen years later, the CMDB is still a dream for most, and a nightmare for many. That pageant winner has left the stage, but the yearning for the tiara hasn’t.

The concept, desires, and principles associated with the CMDB are still very much on the technology operations main stage. The CMDB vision and capabilities we spoke about in our book are still only aspirational for most organizations over a decade later. People still desire and agree upon the vision and capabilities, however achieving, and delivering on them have been elusive.

Are we repeating the mistakes of the past?

The hopes people have for AIOps are reminiscent of what we saw for the CMDB starting nearly two decades ago. There is still great hope for a source of auto-magical truth. I flashback to those days and worry that our industry hasn’t learned from its mistakes. In 2035, will people once again be talking about yet another incarnation of the CMDB – mystical technology that delivers all truths but not in real-time as we seek today but maybe days in advance? Or, will our industry finally learn that the capabilities we all desire are not delivered by a singular technology that is simply installed and runs on its own?

What’s old is new

The CMDB capabilities and promises were refactored in ITIL v3 under Service Asset & Configuration Management (SACM) with the Configuration Management System (CMS) as its underpinning conceptual repository. We now see many of these same desires resurface under the mystical umbrella of AIOps. We’ve essentially taken an already challenging concept and now added a new demand that it be accomplished in near-real-time. The promises people are making for AIOps are magnitudes more difficult because of this time component requirement. A successful CMDB or CMS could accomplish its goals with periodic updates such as nightly or weekly refreshes. That’s not the case for an organization seeking to meet modern business demands.

Baggage, we have lots of it

Like the term CMDB, the term AIOps already appears to have lots of baggage or at minimum, lots of different views of what it is. In just my first few weeks of taking inquires and briefings as Forrester’s Principal Analyst covering AIOps, it’s obvious that the acronym means different things to different people and varies widely in scope. The common theme though is the aspirational perception of it being the end-all-be-all repository that will solve all operational problems.

Like the CMDB, AIOps is supposed to have every possible piece of data needed to make every possible decision encountered. Sounds like a high bar, doesn’t it? But wait, the data must also be perfect in every way so that everything happens automagically. Have we not learned anything in the last 20 years in trying to implement the all-knowing CMDB?

The CMDB was rebranded as the CMS to express the concept of a federated set of CMDBs to try and shed the image of a singular monolithic data repository. In our book, we dedicated a section of Chapter 2 to “Why the ‘CMDB’ must go away—and it is…Slowly!”. We still agree it must but, it hasn’t and continues to be part of why CMDB efforts fail. Does AIOps already need rebranding before it even really gets started? Are we talking about a technology or a technological-based solution? Should it be viewed as a management practice? Maybe automated technology operations management (ATOM) or something more futuristic like automation enhanced technology operations (AETOM)? What I do know is that my concern is not about the acronym, it’s about the confusion already swarming around what AIOps is and isn’t.

It’s time to grow up, AIOps is not a silver bullet

The CMDB was not a silver bullet, nor is AIOps. Aspirational goals of a centralized decision support mechanism are both highly desired and immensely necessary for IT operations to meet modern business demands. However, we must be more realistic. What is real and what is just smoke & mirror technological promises? Goals and aspirations are great but delivering on the real value on behalf of the organization is the objective. Sadly, it’s far too often not achieved.

What next?

Reframing the discussion around achieving success and what success looks like is vital. Not repeating the mistakes of the past is key to that success. Setting realistic expectations for what it will take to deliver value is a must. Ensuring everyone stops adopting the sure-to-fail silver bullet promise. A better understanding of what you have and what you need is fundamental to setting those realistic expectations. A framework to help you understand that is important for continuity and consistency.

Over the coming weeks and months, I and others will release many more blogs, reports, and webinars to help frame this discussion. I will be working with industry professionals from both the vendor and client community to better understand what they truly need to be successful. My goal is to ensure that the client community has what it needs and can navigate the technological landscape to deliver positive business outcomes. This won’t happen if we haven’t learned from previous mistakes.

 

Join the Conversation

I invite you to reach out to me through social media if you want to provide general feedback. If you prefer more formal or private discussions, email inquiry@forrester.com to set up a meeting! Click Carlos at Forrester.com to follow my research and continue the discussion.

Newsletter Signup

Subscribe to our weekly newsletter below and never miss the latest news.