devopsy.kinsta.cloud

Author: Michael Del Castillo

  • How to Consolidate Your IT Operations Management Tools

    How to Consolidate Your IT Operations Management Tools

    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 can be 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.

    Operations Management Tools: Cleaning House

    Avoiding this exercise can be 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, operations management tools overload contributes needlessly to data noise rather than focusing on the data sets that are most critical to maintaining healthy service levels for the business. In this article, I’ll discuss the major battles and offer some ideas to simplify and accelerate a tools rationalization and consolidation exercise.

    Battle 1: Politics

    I’ve worked in enterprise architecture and IT operations for more than 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 capabilities or are considered to be nearing the end-of-life road map by the vendor. I understand the reluctance that team members have in letting go of tools they are comfortable using, as well as the time and effort it takes to learn 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 that 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 in operations management 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 also 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 road map.
    • 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 defuse 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 difficult 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 difficult 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 road map 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.

    Modernizing Operations Management Tools

    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.

  • How Enterprise Architects Can Help IT Operations

    How Enterprise Architects Can Help IT Operations

    Traditionally, the role of IT operations has been to keep apps and systems running well for the business. But in the era of cloud, DevOps and disruptive technology, keeping the lights on isn’t enough. IT operations people need a broader view of business needs. They need to evolve the infrastructure stack in ways that will maintain stability yet also support business goals. This is no easy shift for people who’ve grown their careers by focusing squarely on the technology: procuring and configuring servers, storage devices and network components.

    Enter the enterprise architect. Enterprise architects live and breathe business requirements and are a liaison between business leaders and IT. They’re responsible for building a long-term plan for technology evolution aligned with digital business initiatives. Enterprise architects are stewards of enterprise data and thus have typically established many solid relationships across not only IT but business functions as well. Typically, they are advisers to C-level executives and traditionally report to either the CIO or the CTO. 

    The chief architect can also be a valuable partner to the director of IT operations and his staff. Here’s how:

    1. EAs bridge the gap with business units, helping define business services and their requirements which ITOps need to meet, and gathering end-user feedback which drives planning and staffing.
    2. EAs bring a deep understanding of enterprise data assets, data connectivity and business applications—perspectives that help ITOps define key business service management goals.
    3. Architects also assess the need for new infrastructure technologies and take a strong hand in evaluating vendor platforms. 

    The relationship between IT operations and enterprise architects may not be an easy one, since IT operations have been accustomed to working independently. They may not welcome other people/teams advising them on which monitoring systems to use, for instance, or how to prioritize incidents. Yet, better collaboration will ultimately help IT operations teams by improving their sometimes-contentious role with the business and providing a deeper understanding of the relationship between network and business outcomes. The following use cases illustrate how this can work.

    Driving the Roadmap Between Current and Future State

    One of the activities that enterprise architects conduct is creating a technology reference model: a list of all the technologies used in the business and notations as to which ones are approaching EOL and should be replaced. The EA’s job is to reduce organizational risk from outdated and misaligned tools and systems. On the other hand, IT operations managers have the viewpoint of managing risk; when a key infrastructure technology is suddenly jettisoned, that jeopardizes the health of business applications. EAs and ITOps teams have an opportunity to get on the same page, developing a transition plan together for moving to new technologies in a way that meets business needs and minimizes IT performance risk. 

    Improving the Stack for Business Value

    As part of creating a long-term technology strategy, EAs focus on ROI. When ITOps share performance data on applications and systems, the EAs have critical data points to determine whether an application is too problematic–causing too many issues for too little business value–to maintain. Examples include moving from custom-built CRM to a COTS CRM or moving from on-premises email to Office 365 to increase availability and reliability of email.

    Justifying and Evaluating New Systems

    IT operations regularly want to purchase point monitoring software. They like what they see in a couple of new startups focusing on cloud monitoring and optimization or something specific for monitoring databases. But they may not know that another group, say in the EU region, is using something that could be applied to solve the issue. EAs can supply an holistic picture of the problem and how to solve it. In some cases, it’s not about buying a new system but leveraging an existing one to reduce complexity and minimize spend. EAs can also bring a business/user lens to assess user experience, such as AIOps. What effects could an AI application have on improving service delivery, and showing customers that IT is there to make work easier?

    The EA and ITOps teams need to work together to support the business. Enterprise architects should bring to the table their understanding of business needs, existing technologies and their knowledge of technology investments that are being proposed outside of IT. Meanwhile, ITOps can bring granular information about device failures, common issues and preferred vendors, which helps guide the EA’s recommendations to business stakeholders.  Together, these two critical roles can develop enterprise IT strategies which help the business succeed.

    — Michael Del Castillo