help desk software
+(800) 286-4232 info@ratchetsoft.com

Speaking with prospective customers every day, I’ve gotten quite good at handling the few objections people pose to implementing Ratchet-X. However, the one objection that continues to vex me is an issue over which we have little control. The issue is service support. When raised, the objection usually comes in two parts. The first part has to do with the reliability of the services that comprise a Ratchet-X plug-in. The second part has to do with application support staff’s ability to discern native application features from Ratchet-X enabled features.

Let’s start with the first part of the objection. Concerns over the reliability of underlying services comprising composite applications, mashups and “super-services” is nothing new. In fact, I wrote an article back in 2001 addressing this exact concern. Although six years have passed since I wrote that article, this concern is still alive and well, especially in organizations that have yet to implement proper SOA governance infrastructure and problem resolution procedures geared towards supporting spontaneous application generation. The bottom line is an organization’s SOA is not ready for prime time without the proper controls in place to monitor underlying services and provide immediate contingency in case of service failure.

The solution to the second part of the objection is not as clear cut. Although we tend to get the objection more from software vendors rather than enterprise customers, I believe it applies to any organization that takes application support seriously. Ratchet-X is all about creating user-centric software by allowing users to add new capabilities to existing applications. While that’s great for users, it presents special challenges for those responsible for supporting those applications. In other words, how do support personnel provide support for application features they’re not aware of? For the enterprise customer, we need to look much further the answer to the first part of the objection. The best way to solve this problem is to make sure these new features (plug-ins in Ratchet-X parlance), are incorporated into the organization’s SOA discovery and governance infrastructure. Since most plug-ins are comprised of, and in effect, function like web services, they should leverage the same infrastructure. Plug-ins should be registered, versioned, hosted and documented the same way all the organization’s services are handled.

In the case of software vendors, the issue is muddied by the fact they have to support multiple customer installations without access to and/or integration with such governance infrastructure. Nor do they really want that level of involvement with their customers. In the end, software vendors prefer their customers to look more alike than not. This being the case, it makes more sense for software vendors to direct their clients towards certified system integrators well-versed in both the vendor’s application and Ratchet-X. Since Ratchet-X opens up new revenue generation opportunities for systems integrators, they are both happier and more qualified to take on this kind of systems integration and support than the software vendors themselves.

If you have any other thoughts on this support issue, comment on this article or drop me a line. I’d like to hear your thoughts on the matter.