Software as a Service

By Sam Sweet, Senior Manager, Strategic Client Services

Introduction

Having found its niche in the marketplace where your Software as a Service (SaaS) solution attracts customers, your management team now wants to increase revenue. As with any investment in a critical solution, obtaining a client/prospect’s commitment to increased expenditures hinges not just on the budgetary aspect but also on their understanding of the solution’s security and continuity strategy. Shifting to a SaaS solution makes entities dependent on the execution of their vendors to ensure uninterrupted, effective operations. Coupling a proven security and continuity (fail-over) strategy (Certitude) with your SaaS offering attracts prospects and ensures client loyalty as they look to outsource more than just non-core functions and processes. Organizations failing to address the Customer Satisfaction Concerns dynamic (Convenience, Criticality, Cost, Complexity, Conformance, and Certitude) may see their revenue streams adversely affected.

Evolution of the SaaS Offering from Convenient to Critical

SaaS solutions offer an excellent business model for the developer; one controllable customer-facing version with little to no effort required for customization while accessible to all prospects worldwide. As history has shown, the revenue model proved more difficult to harness but developers persevered and the market continues to grow. Once lauded only for their convenience and low cost of entry, SaaS solutions continue to increase their share of the software services market.

As more SaaS Solution Providers unveil increasingly feature-rich offerings, including the ability to integrate with legacy back-office IT investments, savvy customers begin to realize their “convenient” subscription-based software has become “critical” (and we all know critical solutions enjoy a much more diligent review of the previously mentioned “Customer Satisfaction Concerns”). Should a critical solution become comprised due to malicious attacks or unavailable due to unforeseen business interruptions, your customers may incur both direct and indirect expenses (to say nothing of potential direct revenue losses).

Security Example

Incidents of SaaS application attacks continue to rise as more solutions become available in the marketplace. Solutions range from simple CRMs to sophisticated multi-geographic, multi-data stream solutions with thousands of users from one client. Regardless of the complexity, SaaS solutions are vulnerable to attacks. Attacks on critical Enterprise Solutions prove challenging as nefarious elements attempt to overcome both the physical and digital “walls” companies employ (and directly control) for protection. With the SaaS model, two significant factors changed: companies no longer have a “physical” wall and they no longer control their “digital” wall; customers must rely on the vendor’s ability to implement safeguards to protect increasingly crucial business intelligence.

Imagine a swimming pool in your backyard where you control access, chlorination, and water level. You can enjoy the pool whenever you want; secure in the knowledge the chlorination and water levels are exactly where you want them. Now, change the model and join a “community” pool. While the maintenance fees are much lower than when the pool was in your backyard, you have now turned over control of who can swim, when they can swim, and the water quality. If you are the only person planning on using the “neighborhood” pool (and you are an okay swimmer), the low pool fees are attractive because you can pretty much control the risks while enjoying the low cost of operation.

But what happens if you decide to provide access for your entire family, including your twin seven year olds (in other words elevating the “criticality” of the pool?) Now your concerns include who else will be using the pool, the background of the lifeguard (training and criminal history), water quality, and when the pool is closed (if you have twins like I do – pool closure in the summer is as close to a disaster as you ever want to encounter!)

While the previous example over-simplifies technical aspects, customers do expect critical SaaS Solution Providers to proactively address various concerns (i.e., network security, web application penetration, or database security.) Should the SaaS application process payment card transactions, PCI DSS and PA-DSS compliance becomes important (if not required.) Regardless of the type of hosted solution, the more critical it becomes to your customer (meaning more revenue for you), the more intense scrutiny you should allow for your security considerations.

Continuity Example

Fail-over (known in some circles as continuity or disaster recovery) emerges as the matching set to security. When implementing an Enterprise Software Solution on their own infrastructure, companies address failover concerns by adhering to the IT Standards and Policies of the organization. Regular data backups, configuring servers for RAID levels, offsite storage – these are just a few of the various things the IT Director directly controls. With a SaaS solution, the IT Director has no direct control of how the Provider ensures a strategy for fail-over.

Returning to our imaginary backyard swimming pool, suppose you ran out of chlorine? Your fail-over plan might include going to the local pool supplier and purchasing more chlorine. Should the water level run low, you could run a hose from a nearby faucet and fill the pool to your heart’s content. If your family takes advantage of the “neighborhood” pool, fail-over is handled by the pool manager. They ensure chlorine and water levels are maintained while keeping the pool clean (at least that’s your expectation). Let’s go one step further with the “community” pool scenario. Suppose the community, while owning the pool, actually has a contract with a management company that maintains several dozen pools in the area. For a time, everything is fine; the pool remains clean, the water and chlorine levels are managed, and the pool is always open during business hours. Then the pool doesn’t open for a few days. You find out the community has not paid the required fees to the management company. Despite paying your pool dues on time, your family cannot access the service promised to you. What is the fail-over plan? How do you ensure your twin seven year olds can cool off while burning energy despite not having access to a pool?

This pool example is analogous to a SaaS Solution Provider utilizing a Hosting Vendor. Customers generally do not enjoy a direct relationship with the Hosting Vendor (similar to the pool management company), but they are directly affected by the actions (or inactions) of the Hosting Vendor. As companies review options to increase investment in your highly critical SaaS solution, they invariably apply the Customer Satisfaction Concerns dynamic. Despite not having direct control of these areas (as they would if their IT Director implemented the solution on their infrastructure), customer demands (for vendor solutions in these areas) are closely tied to the level of criticality and commitment. Expect to spend time and energy ensuring your solutions effectively address these concerns as your sales force will surely let you know if you have not.

Conclusion

If you have been around for awhile, you remember the days of the Betamax/VHS debate. Without a doubt, Betamax enjoyed better quality scores than VHS. Despite this, VHS emerged the victor in the Video Cassette Wars. VHS, as a standard, won the war because it addressed the Customer Satisfaction Concerns dynamic more effectively than Betamax—despite losing on quality metrics.

To drive your revenues and encourage your clients and prospects to see your solution as critical, ensure your security and fail-over (Certitude) strategy can bear the wrath of twin seven year olds. By proactively addressing the concerns of your SaaS offering (regardless if you outsource them to other organizations), your clients and prospects can have peace of mind that their increased commitment is both prudent and viable.

Ten tips to implement an effective Certitude Strategy:

  • Be proactive when identifying key risk areas—ensure vulnerabilities of the infrastructure and your delivery partners are known by both technical and business stakeholders.
  • Integrate your client-facing strategy with the approach for your own organization—convincing someone of the soundness of their Certitude approach is much easier if they know your own future is based on the same approach.
  • Address shared technology vulnerabilities—as you (or your delivery partners) implement and enjoy the benefits of scaled infrastructure, remain aware of how compartmentalization is enacted to prevent unauthorized access.
  • Understand transition impact—explore the impact of a full-scale integration versus an incremental implementation.
  • Scale fiscal impact to align with revenue expectations—ensure the expense cleanly integrates with the pricing model of your service offering.
  • Refine your strategy to incorporate all clients—make your life easier by providing the same level of Certitude for all your clients rather than attempting to replicate the standard good, better, best services.
  • Align the Certitude Strategy with your capabilities—ensure the strategy aligns with your functional abilities and contractual commitments.
  • Ensure Service fail-over—implement a neutral third-party escrow approach for Data, Infrastructure, and Intellectual Property.
  • Address both internal and external security concerns—demonstrate security vigilance by conducting periodical testing (i.e., penetration, database security, white/black box, etc.)
  • Validate your Certitude Strategy—Execute an Operational Recovery Exercise to determine how well your Certitude Strategy works.
Submit an RFP
Downloads
Email Us