How To Support Cloud Applications

Support organizations and Internal help desks have been supporting user applications for decades. But cloud apps make for some new twists, here are some best practices that are the cornerstones of cloud system support.

Cloud computing gives user organizations and IT alike the freedom of maneuvering and long-run flexibility that was never possible with traditional enterprise applications. However, that freedom makes for new levels of unpredictability when it comes to big deployments, and some new requirements for support.

As I've written endlessly, CRM applications are different from other enterprise applications, largely due to the needs and habits of its users. Generally speaking, sales and marketing folks put a much higher priority on success (both the appearance and the reality) than they do on process discipline or little details like data quality. Couple that with the shifting sands of marketplace competition and evolving sales models, and the result is a system that must frequently accommodate significant degrees of change.

So the combination of cloud and CRM can make for some stressful nights in the internal support organization. When there are sales territory splits or redefined partner overlays, there will urgent pushes to change lead routing, account ownership, and opportunity validation rules. These changes may seem to slide right in, but can sow the seeds of bugs in commissions or referral fees. Almost inevitably, these problems won't show up until you've incorrectly processed hundreds of orders.

The traditional help desk infrastructure (and, I have to say, attitude) really won't cut it for these high-profile problems. All too often, there are political overtones that lead to blame-games that you'll want to avoid. So let's look at some best practices that are the cornerstones of cloud system support:

It all starts with architecture and configuration control. The truly scary problems in cloud CRM don't occur within the narrow purview of the CRM system. The issues surface at the points of integration with accounting, order processing, e-commerce, portal, or other customer-facing applications. Even though it's easy to make changes — literally in hours — in your CRM system, that doesn't mean that you should do so...or that your CRM changes will correctly propagate to those other systems. There needs to be a configuration control process that looks at the consequences of any change made to the code, the data model, or even the semantics of picklist values. Really, this one can kill you, because there's no administrative "center" of a large cloud deployment. Each application has its own control panel and dashboard, but the consequences of changes across the interfaces and mashups can only be assessed by a panel of SMEs.

Your team will need instrumentation. Under the best of conditions, troubleshooting across applications is tricky precisely because of the loose coupling that provides the advantages of the cloud. Early in your development cycle, make sure to write error handling and logging classes that write diagnostic records during production use. As discussed here, the error log should itself be stored in a "centralized" cloud service, to supplement the logging available in each application.

1 2 Page 1
Page 1 of 2
NEW! Download the Fall 2018 digital issue of CIO