How to Approach IT Operations Management Tools Consolidation
Your organization 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.
If your organization 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 organization 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 rationalization and consolidation exercise.
SEE ALSO: PHP Tools of the Trade
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 organization 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 organization 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 centralizing access to larger data sets for everyone in the know can bring long-lasting benefits to both the organization 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 categorized 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 categorizing tools by functionality and teams, but providing even more detail that can help make a data-driven assessment. With better data, IT organizations will be able to rationalize 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/rationalization 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 minimizing 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 organization 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 organization 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 organization 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 rationalization, and make the IT organization more agile for future go-to-market strategies by reducing support and maintenance complexity.