6. BMC needs to get better messaging out about customizing Remedy and associated costs, and the issues-of-old related to the cost and pain of upgrading between product versions. Cost, ease of use, and upgrades are why customers are leaving what is a very, very functionally-rich ITSM offering.
This is less about Numara, and more about Remedy, and I wanted to expand on it a little bit. The devil’s always in the details – so let’s break it down. There are really 3 “Remedy” related points here:
- Customizing (and Associated Costs)
- Upgrading (and Associated Costs)
- Ease of Use
Customizing & Associated Costs
First, it’s important to remember that these days “Remedy” (the brand), means the Action Request System (ARS) platform, and the ITSM applications running upon it.
The AR System as a development platform has been around for 20 years and has always been geared towards quickly implementing business rules over other considerations (like upgrades, which I’ll talk about more in a minute).
However, the applications that are built on top of the AR System can be as simple or as complex as the architects or developers make them. And, in order to provide a, “…very, very functionally-rich ITSM offering”, the 7.6.x versions of ITSM applications are complex, no doubt about it.
Providing this much functionality means having to do a couple of things: First, you have to use what the AR System gives you, meaning a LOT of workflow objects, including a ton of supporting forms that are never seen on the front-end, huge quantities of Active Links, and Filters, and a complicated set of “foundation” data that must be configured for it to work properly.
Next, it means having to deal with the stuff you need, but doesn’t neatly fit into the core AR System. BMC in recent years has had to get very creative in order to deliver the applications to a web browser (RemedyWeb, anyone?), and a variety of back-end processing that hasn’t traditionally been thought of as “pure” ARS.
A lot of AR System capability in recent history has come as a result of BMC’s front-end application requirements (and it’s nice that these functions are made available for custom applications – there are still a lot of these in the world).
I expect this to get more complex as their “mobile-first” initiative proliferates.
Summary – The AR System as a platform provides easy customization to applications. However complex applications mean complex customizations. I don’t see this changing any time soon.
Upgrading & Associated Costs
Upgrading BMC Remedy applications is difficult for 2 reasons: handling customizations & data
Customizations is one of the biggest headaches BMC faces with their ITSM applications running on the AR System. How to upgrade your applications, when some well-intentioned developer (or one of your own BSM/ITSM consultants) has changed your workflow?
(To BMC’s immense credit, all of their application code is available to be customized using the standard AR System development tools – one hope this never changes.)
As I mentioned earlier, the ARS platform is, and always has, been geared towards applications quickly delivering business value. Sometimes this means incurring overhead in other areas like source code management. I’m fairly certain that this was a conscious decision in the early days, with an eye towards adding if/when needed. It’s needed now. 
Next, there are a variety of ways ITSM applications can be configured using data. This “configuration” data essentially controls how the applications behave, and can be set up using endless combinations. If BMC changes the way any of the foundation data is used, it’s almost impossible to automate the upgrade – the only way to ensure a smooth upgrade is by having human beings that know what needs to happen, and make sure it does happen. Not exactly cheap.
Summary – With the introduction of data import, delta load, and migration tools, and overlays, ARS applications are more capable than ever of being upgraded (I almost said “easily upgraded”, but it’s not there yet). Look for even more features in ARS v8.0, especially in the areas of source control (allowing large, distributed teams) and better versioning.
Ease of Use
I’m not sure if Mr. Mann is referring to the administration of the applications and platform, which I’ve covered above, or the experience of the support staff within the applications themselves. Since he contrasts “rich functionality” with ease of use, I’ll assume the latter.
In many respects, BMC is a victim of Remedy’s and AR System success. Evolution is always slower and harder than innovation, and there is an obvious and direct correlation to today’s ITSM applications and their early Help Desk applications.
Another factor that isn’t spoken about too much is the flurry of activity as Remedy Corporation passed from being a standalone company, to Peregrine (the dark years), and finally to BMC Software. This happened during the 2001/2002 time frame – the same time as Web 2.0 was evolving – and BMC has been racing to catch up ever since.
Finally, the current versions of ITSM are based (literally) on both ITIL, and BMC’s own Service Management Process Model (SMPM) and without knowing the methodologies and processes defined in these tools, using an application based on them, might not make the most sense.
No excuses, though. It can be better.
Summary – As the AR System gains capability to support modern clients like web (hardly modern) and mobile, the applications built on top of it will continue to get easier to use. In the mean time, the “best practice” view of the ITSM apps are a step in the right direction.
Most of these details (and associated costs) are well-understood, and expected, by those familiar with the platform and applications. BMC does a great job of ensuring detailed communications flow to AR System architects, developers, and administrators, including an increased participation in the various online discussions that are occurring.
Indeed, these folks are the biggest supporters of BSM, ITSM, and the AR System – often leading the charge within their internal IT organizations.
What’s missing is how decision makers and executives develop this same level of understanding, without having to dive as deeply as I’ve done with this post.
Not exactly a new problem, but not exactly easy, either.
 The AR System does not fit into the common software configuration management development models regarding source control. Concepts common in compiled languages like a having a main code branch, branching (early/late), merging, labels, and patches simply don’t (yet) apply to applications written on the AR System.
Until the introduction of “overlay’s” in 7.6.04 all code changes were essentially made to the “main” branch (even CVS integrations included in earlier versions of ARS didn’t get this deep into source code management – they simply kept multiple ARS developers honest by preventing concurrent development, and adding comments).