Application performance, that is. Over a year ago we brought in a new Content Management System (CMS). And even though we looked at more than six vendors, the decision was made to go with a Software as a Service (SaaS) provider. I’m just a user of the application so I have no idea how they negotiated the contract but I assume that the Service Level Agreements (SLAs) took into account performance, customer service, AND application performance. I’m happy to let IT deal with customer service issues because being told that I might have to wait a month for a new feature is completely acceptable. I understand and accept that we probably have a set number of hours a month for support services. But what about the actual performance/response time of the application? Shouldn’t that be something that a SaaS provider cares about and monitors?
I’m pretty sure it wasn’t part of our negotiations because after 2pm EST, our CMS reminds me of those three-toed sloths I love watching on the animal planet. We’ve been complaining about it since we launched, but our SaaS provider has never come up with a solution. It was initially blamed on our network - IT made some tweaks, but that didn’t help. At one point our SaaS provider gave us a little test to run when we were experiencing slowness, which we did, but the problem was that we’d then be asked to do something else… To be honest, we (the users) aren’t jumping at the chance to break away from our work to help our vendor with application/network performance tests. Just fix it and make our lives better. Isn’t that what the promise of SaaS is all about?
Well our constant complaining finally paid off. A meeting was scheduled to talk ONLY about system performance issues. We were asked to provide a list of all the things that we did in the CMS that were “time” intensive, i.e. waiting for screens to pop. One of my team members put together a very comprehensive list—it was great because it said everything I would have wanted to say. I (nicknamed “Pamela Pill” as a child) decided to record my desktop as I worked in the CMS for 18 minutes. I actually didn’t think anyone would watch it, but they did. And what’s more, they loved it! Even the vendor thought it was great. Just by watching this video, they could clearly see two actions that we were performing that were processing very slowly. This is what we call BUSINESS INSIGHT here at Progress.
I think it’s great that our vendor may be able to troubleshoot and fix our problems but it took over a year of complaining and a video for them to believe that we were really suffering. My point isn’t to bash our SaaS provider or SaaS solutions in general, my point is to remind service providers to talk about application performance during the contract negotiations, and for the buyers of the service to ASK about it. With SaaS you may lose much of your reliance on your internal IT department, but they probably still should be held accountable for pipe and power. If the pipe is open and the power is on (which we determined it was), the problem lies someplace else. I think all SLAs should cover those problems, especially if they affect the service being delivered.
Did you notice my use of “I think”? For those familiar with SLAs, am I asking too much? Do you have any best-practices for people negotiating SaaS contracts or specifically the SLAs associated with a SaaS contract? Am I expecting too much?
Progress can’t help you negotiate your SLAs but we do enable SaaS providers to build, deploy, and manage SaaS offerings and we have the leading enterprise service bus (ESB) in the marketplace (Sonic ESB), that is exploited as part of the OpenEdge SaaS platform to address the process integration issues surrounding SaaS deployments. However, the one area that I think our CMS vendor missed out on is what we provide to our Progress-based SaaS providers to better monitor and manage SLA’s – that is Actional. Progress Actional provides the business visibility needed for SaaS and business service providers to guarantee service level management. Having that visibility into the business transactions and ensuring that application performance is meeting the needs of the USER… that is what we call Business Assurance – and what I think was missing in our SaaS providers offering. Hopefully it's not missing in yours… Learn more about SaaS Enablement and Business Transaction Assurance.