Thursday, February 26, 2015

The Cure for What Ails Your Remedy

Information Technology Service Management (ITSM) is, in a nutshell, an approach to managing everything in the IT lifecycle as a service, as opposed to just assets and technology. Most enterprises end up with huge ITSM systems (think BMC Remedy, HP ServiceCenter, CA Intellicenter, or ServiceNow). There are a few ITSM suites out there that can deliver the framework and required core capabilities for your environment; but your enterprise also has a lot of unique requirements, and that means a lot of customization in your ITSM systems.  And, just like ERP systems, the ITSM customizations aren't only upfront, but are constantly ongoing. The necessary evil of customizations brings about immense pain that manifests itself in production outages due to insufficient test cycles; exorbitant project costs; and crumbling RTO and RPO.

I had the privilege and honor to spend many years with the fine folks at BMC and designed many architectures and integrations around their ITSM platform (Remedy) and their Cloud Lifecycle Management platform. I will share my POV from my experience with Remedy, but everything that I speak about also applies to the other Enterprise ITSM systems like HP ServiceCenter.

The ITSM teams are often plagued with data constraint issues that can be categorized as follows:
  • Insufficient Environments - Everybody shares one instance. Perhaps just one non-Prod instance total. (Again, I know this from direct experience). This results in everyone waiting in line to do their work and the release process is always dependent on the last person finishing their tasks before the next stage can commence. (It can't go to staging until the last QA engineer is finished). And when I say everyone, I mean Break/Fix, Dev, Training, etc. I can only personally name a few places where I have seen more than two non-production environments (total of three ITSM environments).
  • Inadequate Data - The data in the non-prod environment(s) is often synthetic and seldom contains real data (usually the Calbro Services data + some synthetic transactions). And, if it does contain real data, it is a subset and almost never refreshed. ITSM environments can be huge! Having to copy and move that much data becomes a very labor intensive task. On top of that, ITSM systems, by nature, contain the most sacred details of your enterprise: Product Serial Numbers, Asset locations, Fleet info, Vendor contracts, Service Level Agreements, Employee SSN's, Birthdays,  Dependent information, Salary Info, etc. No CIO/CSO I know wants multiple copies of that data around.
  • Inefficient Processes - How long does it take you to spin up a new ITSM environment? How long does it take you to back out of a failed patch? How long does it take you to restore or reset the environment? How long does it take you refresh your break/fix instance with production data when an issue arises?  What about Friday at 4:30 PM? For any of those questions, can you describe the process? My guess is that if you are a Remedy manager, developer, or tester, your answer (days, weeks, months) would be far different than the answer of your sysadmin, dba, or storage guy (minutes or hours). Why? Because your process likely starts with, "I file a ticket…" and includes statements like "I then have to wait for …. And then I have to wait for… (*n)…and then finally….." The sysadmins, dbas, and storage guys are awesome, but the process inherently is slow, even if the individual actions are fast.

I have known a lot of customers over the years that have struggled with the huge project costs and timelines associated with upgrading  Remedy  to a new version or migrating to a new datacenter. We're talking $MM services engagements here. What if we could turn that on its head and reduce the timelines and projects by half?

Over the next few weeks I am going to blog about how Delphix completely changes the process and economics off your enterprise applications. First, I will be chronicling my journey of virtualizing BMC Remedy with video and my blog. This won't be so much a tutorial on the best practices of Remedy development/testing or a "how to" guide of virtualizing Remedy with Delphix (full disclaimer: I am not a Remedy Guru). Consider this a documented exploration of a solution to the problems listed above. The ultimate goal of this series is for the follower to have an epiphany of what is now possible due to Delphix.