IT operations management tools consolidation: The five key battles you need to win

Michael Del Castillo is solution delivery architect at OpsRamp.

If your organisation has more than 20 tools for IT operations management and DevOps, you’re not alone. According to one source, nearly 40% of IT teams are using more than 10 monitoring tools. There comes a time when you simply must clean house. This is a painful chore, akin to cleaning out the garage or basement after a few years of neglect. It requires deep analysis, an in-depth understanding of business requirements and political finesse.

Avoiding this exercise, however, is fraught with danger. Your organisation is likely wasting money and time maintaining and integrating legacy and/or disconnected tools that aren’t worth the effort. As well, tools overload contributes needlessly to data noise rather than focusing on the data sets which are most critical to maintaining healthy service levels for the business. In this article, I’ll provide some ideas to simplify and accelerate a tools rationalisation and consolidation exercise.

Battle #1: Politics

I’ve worked in enterprise architecture and IT operations for over 15 years, as an internal team member and directly with clients. I can say with confidence that in most cases, 75% of the tools deployed in an IT organisation have redundant capability or are considered to be nearing the end-of-life roadmap by the vendor. I understand the reluctance that team members have letting go of tools they are comfortable using, the time and effort it takes to learn a completely new technology and the feeling of a loss of control when the business owner of a tool changes hands. Yet a regular tools assessment and consolidation exercise is best for the organisation over time.

Typically, the unstated issue of teams not wanting to change tools relates to control. The teams which have the most data or the most important data tend to get more budget. It can be tough to relay the message that simplifying the tools ecosystem and centralising access to larger data sets for everyone in the know can bring long-lasting benefits to both the organisation and to individual careers.

This is why it’s imperative for the senior IT or engineering leader to lead the charge by communicating the goal of the tools consolidation initiative and benefits to individuals, teams and the business at large. Here are a few of those benefits:

· Eliminate unnecessary tools to reduce maintenance spend/time and complexity

· Develop a framework for evaluating future tool acquisitions

· Bring more control and visibility into bugs, issues and infrastructure/code status with the right set of tools.

Battle #2: Inventory

Maybe you already have your tools categorised and qualified in an asset management system such as a CMDB – but maybe you don’t or the information is outdated and incomplete. Doing an inventory is not just about categorising tools by functionality and teams, but providing even more detail that can help make a data-driven assessment. With better data, IT organisations will be able to rationalise tools without heavy politics. Here’s what to include:

  • Primary and secondary functionality
  • Product roadmap
  • EOL dates
  • Core user groups
  • Relationship to business service/applications
  • Customer support contracts
  • Required skills/internal staff for support and maintenance
  • Existing issues
  • Vendor relationship
  • TCO/ROI metrics

In enterprise architecture circles we call this application portfolio management/rationalisation and it can be quite a task if you’ve never embarked on it before. It’s fine to start the process using Excel but whatever tool you use, be sure to share the inventory document with all of your stakeholders for enrichment and feedback. Arriving at the TCO or ROI analysis may not be easy for legacy applications but do your best to collect as much data as possible for your calculations; information around previous support and maintenance contracts, hours to support issues, patch and maintain; and the hardware and software costs required to support will help provide an understanding of the TCO.

From there, determining the “R” in your ROI will be based upon many factors, both tangible and intangible. For example: Does the tool save significant manual time to do the same process and eliminate toil? Does the tool increase accuracy, thereby minimising rework? Does the tool improve the work-life balance or morale of employees?

Battle #3: Review board

A technical or architectural review board helps evaluate and approve requests for new tools and technologies. Typically, these boards have cross-functional employees from operations, application development, application management, EA and even security. The job of the board is to understand the business requirement for the request and mitigating factors such as cost, time to implement and security considerations. The board also ensures that a similar tool already in place in the organisation couldn’t satisfy the request. While boards with the right individuals can diffuse politics and ensure a balanced approach to evaluation, boards can also encourage politics if special favors are granted. Senior IT leaders should discourage that behavior (obviously).

Battle #4: Shadow IT

It is true that employees can easily find workarounds these days to processes that you put in place – no matter how objective and sensible they are. Technical folks love to experiment with new tools, and it’s hard to break the habit. One idea is to apply control by prohibiting the use of personal credit cards to make purchases and requiring review board assessments and security reviews prior to acquisition. Employees who choose to violate those requirements will face certain consequences. You may also want to reward those who follow the rules with bonuses or other perks.

Battle #5: Predicting the future

At the rate of change and unpredictability in business today, it can be hard to plan too far ahead. But some part of planning is necessary because business and overall IT requirements drive the tools strategy. Understanding the 12-month technology roadmap is reasonable, but if you can extend your vision further to 24 months or longer, it can provide important decision-making factors. For instance, if your organisation is planning to embark on a cloud migration effort in the future, but need to upgrade a legacy system now, delaying the expense of a pricey upgrade and expediting the cloud migration initiative would be an easy way to reduce IT risk and deliver more sustainable capabilities for the future.

In summary, everything revolves around the data. If you leverage concepts of enterprise architecture and application portfolio management, you’ll quickly be on your way to helping your organisation make better IT decisions. Through EA and APM disciplines, you’ll learn how to establish governance processes to reduce IT risks and vulnerabilities, cut operational spend through rationalisation, and make the IT organisation more agile for future go-to-market strategies by reducing support and maintenance complexity.

Photo by Jaime Spaniol on Unsplash

Interested in hearing industry leaders discuss subjects like this and sharing their experiences and use-cases? Attend the Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London and Amsterdam to learn more.

View Comments
Leave a comment

Leave a Reply

Your email address will not be published.