HOME | Articles | Blog | Interviews | Experts | Webinars | Events | About Us | Submissions | Contact Us | Newsletter

BSM
Review.com

Next Practices in Business Service Management

 

 

Mitigating Risk for End-of-Life Technology
by Bill Keyworth

EOL Technology

It’s hard to envision a normal, rational IT executive replacing their existing “end-of-life” technology without an examination of alternatives. Yet, too often we rely on the biased input of our legacy vendors in choosing replacement options. Based upon decades of exposure to the marketing prowess of IT service management vendors, the author submits recommendations for mitigating the risks associated with end-of-life technology. Specifically, we’ll outline a process to help turn the end-of-life problem into an opportunity to better serve the needs of your business constituents and IT staff …thereby moving to a desirable state of Business Service Management (BSM). We’ll also suggest how to analyze your options up front, prioritize and focus on critical evaluative criteria, validate findings and test conclusions.

End-of-Life Illusions

Having spent more than 25 years analyzing, advising, defining, developing, promoting, messaging and selling business service management technologies, I’m consistently impressed with the willingness of end users to accept technology end-of-life (EOL) options as painted by their vendors. In most cases, vendors will offer the loyal end user an alternative in the form of an “upgrade path” to a different, equivalent technology for the following reasons:

• Enable more responsive support to users of newer technology
• Deliver promised enhancements previously requested
• Resolve business, technology and process integrations more effectively
• Leverage state-of-the-art platform technologies to expedite delivery of future capabilities

Too frequently, that upgrade path is actually a “reimplementation” to the vendor’s newest product acquisition, or re-engineered architectural platform, or “integrated suite” of capabilities that require (…surprise, surprise) purchase of new software licenses ……all in the name of resolving the vendor’s pain in supporting a product for which they have been paid handsomely to maintain and update.

It’s heartwarming to witness the loyalty expressed by IT departments for IT service management tools that they’ve used for years. In some cases, such loyalty has been earned through superior customer service, on-time delivery of enhancement requests and reasonable pricing models. However, such models of good vendor behavior are the exception, not the rule, within our IT community. Typically, at least for service desk tools, the original tool vendor was acquired by a larger conglomerate …which has subsequently maximized profits from the installed (legacy) base with minimal investment. From my perspective, loyalty to these end-of-life IT management tools is often undeserved and begs the question, “why do end users accept the risk of EOL options as defined by the vendor that created the difficult scenario in the first place?”

Perhaps it is fear of the unknown or lack of resources, specifically time and money, within the IT organization that makes it easier to simply keep plugging away with the EOL technology. Business demands on the IT organization coupled with restrictive IT budgets do limit appropriate evaluation of replacement options for business service management tools. Yet a point is reached where the EOL vendor has discontinued product support, enhancements and simple bug fixes …and where the element of force is applied through substantial increases in license and support fees on the EOL product.

End-of-Life Pain

It is fascinating to me how the vendor audaciously packages this transition pain as “doing what’s right for the customer.” It reminds me of our banking industry that created the problem of inflationary housing prices through inadequate financial controls and then faults the borrower for their difficulties in paying inflated mortgage bills. Changes in business service management tools and processes will inevitably result in major disruption to the normal course of business as resources are directed away from those activities that actually drive the business forward (…essentially backtracking BSM objectives.) Examples of induced pain from end-of-life IT management software include:

• Larger than expected reimplementation project for little new functionality
• Expensive integration efforts break due to upgrades or system changes
• Lengthy (measured in months & years) implementation with continual delays
• Significant, unexpected costs of license transferal
• High-cost consultancy fees requiring specialized “vendor delivered” resources

Our immediate requirement should be to create a laser focus on resolving the IT end user’s risk and pain when the EOL vendor pulls the plug …doing the best we can with the limited resources available. End-of-Life Problem is the Opportunity Early in my career, I was mentored by one who viewed every problem as an “opportunity.” At the time I thought his consistency in such an approach to be far-fetched (…to put it politely.) Decades later, I have found wisdom in his admonition. Let’s examine the opportunity that presents itself when the vendor introduces EOL scenarios. Problem: It is safe to assume that existing software functions of our current tool are limited and outdated …or else there would be no need for the vendor to end-of-life a popular and lucrative revenue stream. For example, there’s a significant probability that existing IT service management tools are struggling with difficult and costly technology integration requirements. Opportunity: EOL action enables the IT group to take advantage of other tools, technologies and processes heretofore out of the question. Wouldn’t it be cost effective to take advantage of newer integration mechanisms that were not available 10-20 years ago when your EOL tool was originally architected and developed?

Newer Web-oriented technologies greatly simplify the time and cost of satisfying unique integration needs. Examples include Web services such as XML (Extensible Markup Language) and SOAP (Simple Object Access Protocol); security enhancements stemming from HTTPS (Hypertext Transfer Protocol Secure) and WSDL (Web Services Description Language); and FTP (FTP Secure) protocol for secure file transfers.

Problem: EOL software is less than conducive to the changes dictated by an IT organization’s unique process requirements. EOL vendors often highlight the complexity and high cost of customizing IT service management applications to their IT customers …and recommend not adapting the legacy tool to the customer’s unique processes. Opportunity: EOL action enables users to more easily tap process improvements such as those recommended by ITIL v3 guidelines.

Problem: EOL software is almost always confined to traditional software licensing and traditional computing infrastructure. When an enterprise is trapped into reliance on dated delivery mechanisms, the benefits of other delivery options are unavailable. Opportunity: Benefits from software-as-a-service (SaaS) include the speed of rapid implementation; immediacy of continuous application improvement; lower cost of subscription-based licensing; elimination of upgrade expenses; minimizing upfront investment; removal of version-lock; and available outsourcing options. Benefits of on-demand infrastructure (cloud computing) are more easily leveraged when on-premise applications are replaced with SaaS software solutions. Problem: EOL software will usually represent a sunk cost. Having invested heavily in tools, associated processes, personnel training and supporting infrastructure, most IT shops are reluctant to disregard that previous investment …trying to capture as much goodness as possible from their EOL implementation. Unfortunately, EOL technology requires extra funding to either maintain status quo or invest in newer tools. Opportunity: The EOL scenario forces the IT organization to examine alternatives that limit throwing good money after bad. The IT organization can now examine options that cap the immediate investment and improve IT service deliverables, thereby substituting greater control over the long term expense.

The primary conclusion is that you, as the IT management application user, do have desirable options available for consideration. You do not have to accept the EOL vendor’s recommendations for replacement of one highly complex, rigid IT service management application with a similar solution set. You should be prepared to calmly identify your competitive options to the EOL vendor and see how much that vendor is willing to bend and commit to new provisions in order to retain you as their customer. Timing can favor you …the buying customer. Best Practices for Mitigating EOL Risk It’s hard to envision a normal, rational person replacing their existing “end-of-life” automobile without examining available options. Common sense would dictate that you understand and evaluate comparative benefits and draw-backs of different vehicles. Questions of gas mileage, primary purpose of vehicle, type of driving forecasted, new versus used, demands on interior, type of garaging available, availability of public transportation and reputation of vendor brands are almost always weighed and balanced. End-of-life technology acquisitions should play the same game. When forced into an end-of-life replacement decision for IT technology, prudent behavior requires evaluation of choices other than the recommended migration path of the original vendor.

Best Practices in Evaluating End-of-Life Options for IT

What does it mean to evaluate end-of-life options for IT management tools? In responding to hundreds of evaluation inquiries during my sojourn as a Gartner Group analyst, I found buyers too frequently focused on a singular aspect of the purchase that was most familiar and most urgent to them. The actual user of the software would venture down the path where features and functions played too major of a role in the decision process. The procurement decision maker would focus too heavily on upfront costs, ignoring total cost of ownership considerations. The C-level executive too often would rely on the “relationship” and sense of trust established with the sales person. As an industry analyst, I encourage the following best practices in evaluating end-of-life options:

1. Clearly define your business service management requirements up front. Know what you are looking for (selection criteria) and what you want to do (primary objectives) for an end-of-life replacement prior to any discussion with any vendor. Identify basic versus nice-to-have capabilities desired for incident management, service level assurance, problem resolution, change management, configuration management, self service options, integration requirements, etc.

2. Prioritize those business-oriented activities that will enhance your relationship to your business units and focus on activities/metrics that are jeopardizing that customer relationship. The evaluation activity spawned by end-of-life decisions should not be about what IT needs for better control, or monitoring, or response time or mean-time-to-repair. Evaluation focus should be on ways to enhance profit, ease business operations, increase revenue, and reduce company operational costs ...or business service management.

3. Identify the “best” way, not the “same” way - Don’t limit your scope of options to maintenance of the status quo for the sake of simplicity and expediting the decision and implementation for your end-of-life replacement. Recognize that the question should be about doing it the “best” way and that requires seeking advice and recommendations from IT peers and industry influencers.

4. Focus on “right” processes for your operations and move beyond buying only generic, out-of-the-box service management processes in your end-of-life replacement. Exercise buying behavior that identifies those processes unique and necessary to your organization, but will probably not come in the pre-packaged solutions sets from the vendor. These become differentiations in vendor choices.

5. Leverage modern technology to accommodate the change that should happen in your organization. The objective in end-of-life replacement isn’t to simply invest in the latest gee-whiz software delivery model, or cloud computing infrastructure, or server virtualization, but to apply the benefits of the newer technology in ferreting out and resolving the most obvious pain points in your IT management organization. Evaluation Process for Mitigating EOL Risk There is no sure path or single recommended game plan that is going to get you to the nirvana of lowest risk in replacing your end-of-life service management tool set. However, decades of vendor review experience highlights five evaluation tactics that I believe consistently identify the best solution set. These five tactics include:

5 tactics

Leverage sources of truth

The modern and social Web has simplified and forever altered the way we evaluate any purchases, consumer or business oriented. Instinctively, we take to the Net to find technology options, relevant media articles, and industry gurus/analysts that can assist us in quickly narrowing our search process and reducing our reliance on vendor-developed collateral. Interactions and relationships made possible by advances in the social Web have empowered us to seek peers and existing users of potential business service management tools and processes. The trust factor in such sources has been enhanced when the community conversation is open to challenge, ridicule and agreement.

During this process of seeking trusted advice is the best time to identify, evaluate and test non-traditional software options such as outsourcing and software-as-a-service. It’s easy to identify the top four traditional software vendors for business service management options as IBM, Hewlett Packard, BMC, and Computer Associates ...who also happen to be the most frequent originator of end-of-life technology projects. It’s been more difficult to critique the potential outsourcing providers as they may be well known consulting houses, specialty service providers, and smaller boutique shops.

The phenomenal success of Salesforce.com in establishing SaaS for Customer Relationship Management (CRM) capabilities begs the question whether and how SaaS will impact other enterprise-oriented software applications. Within the confines of IT management, Service-now.com is building a case through trusted advisors where SaaS is more frequently being identified as a legitimate end-of-life alternative for multiple aspects of business service management. The bottom line is that we now have incredible sources of truth in determining our replacement options for end-of-life mandates from traditional software vendors. Prioritize 3-5 criteria for in-depth evaluation Without question, my most frequent inquiry regarding business service management relates to what selection criteria should take precedence. I would propose four as top of mind in the evaluative process for end-of-life replacement options.

First is the ability to support ITIL processes, specifically the newer guidance documented in ITIL v3. The primary purpose of tools is to automate repeatable processes in a cost efficient manner. ITIL has made enormous strides in documenting best practices for business service management in the last 10 years. Older IT service management technologies developed one or two decades ago (…most frequent end-of-life candidates) were forced to consider ITIL as an afterthought. Newer business service management technologies have been built based on commonly accepted and implemented ITIL processes.

Second is the ability to accommodate integration. What out-of-the-box integrations to applications, technologies and data sources are offered? What Web-oriented technologies are leveraged for integration purposes? What does it take to change integrations, particularly those unique and critical to your own enterprise operations? Do upgrades break existing integrations? Is the vendor’s recommended integration approach consistent? These are particularly difficult questions for vendors that have cobbled together a string of business service management applications through acquisition versus organic growth.

Third is the ability to customize. Does the vendor provide tools that empower the end user to easily accomplish their own customization of user interfaces, data collection, reports, etc? Will an expensive “team” of vendor experts be required to implement customizations?

Fourth is the ability to accommodate reports and analytics. Paramount to creating a positive perception of IT within the business community is the information provided to the business units through analytics. How much do the reporting capabilities of the end-of-life replacement product move you closer to the goal of demonstrating value, measuring business results and assuring service levels? Reporting in most legacy (EOL) technologies is an afterthought and is often provided by OEM arrangements. This time around, we need to ensure end users are not left holding a bag of vendor shortcomings in regards to reporting, customization, integration and best practice support.. Evaluate in “apples to apples” model Basic to an end-of-life replacement evaluation is a vendor short list, with options narrowed to 3 or 4 serious candidates who then receive the request for proposal, based on the user’s definition of project scope. It is critical to create an “apples-to-apples” comparison process even if vendors resist the comparison in favor of an evaluation centered on some unique or obscure differentiation or on their ability to leverage an existing or legacy environment. Vendor assistance in the RFP development process, particularly by the vendor forcing the end-of-life scenario, will guarantee preferential treatment to the vendor providing such assistance.

To accurately compare total cost of ownership (TCO) for vendors with very different business models requires an examination of factors such as pricing model, type of licenses, training required, frequency of upgrades, annual maintenance, implementation timeframes, consulting services, hosting infrastructure, upgrade cycles, cost of money, and opportunity costs. Solicit users and references If there is one single activity in which the IT organization faced with end-of-life decisions should vigorously, enthusiastically, relentlessly engage …it would be that of soliciting input from existing users of the business service management tool under consideration. Such solicitation involves more than checking the references (…usually positive) provided by the vendor. It also involves soliciting those users on blogs and industry forums who are unhappy with the product or have had a less than desirable experience in the migration from end-of-life vendor recommended solution set. The benefits of seeking feedback and recommendations from IT peers can be enormous. Find out what their organization would have done differently, would do again given the chance, and would want to have known earlier before venturing into the end-of-life replacement project. Soliciting a minimum of five references for each vendor is healthy, with at least two from sources other than the vendor’s marketing and sales department. Nothing substitutes for speaking with those who have actually experienced the implementation process.

Require “proof of value” or prototype How do you understand what it will take to perform the implementation or measure the benefits of seeing the product in action prior to purchase commitment? My years within the vendor marketing community have left me biased in terms of believing what I see in a vendor-run product demonstration or Power Point integration. Of greater value is the IT organization’s actual use of a prototype, “proof of value” or “proof of concept” in the environment you select. This is a great opportunity to build consensus (…either yea or nay) within the user community, to create buy-in for the potential migration and change required, and to gain confirmation or push-back for the product’s claimed benefits. Of course this is easier for the SaaS vendor to accommodate than the traditional on-premise application vendor, but even they can develop a plan for the customer to engage in a hands-on prototype.

Summary Recommendations

I’ve never felt that vendor evaluations, particularly for end-of-life tools and processes that already exist, involve rocket science. Rather, what makes evaluations interesting, and not a mind-numbing process, is the creativity exercised in recognizing potential opportunities. Remember that it’s not always in the EOL vendor’s best interest for their end users to think creatively about their EOL situation. When confronted with an end-of-life mandate for your IT service management technology, calmly identify your competitive options to that EOL vendor. This should include traditional on-premise applications, outsourcers and software-as-a-service. Clearly identify the requirements you previously defined up front and subsequently apply common sense, logic and truth to your unique selection and evaluative process.

 

###

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

FREE NEWSLETTER

Register for our monthly newsletter

 

twitter
follow us!

 

Copyright © 2009-2012 BSMReview.com or individual contributors.
All Rights Reserved.

Site Design & Management Christian Sarkar