Defining the Enterprise Cloud Service – Part 2: Development for the Enterprise

Last Tuesday I released part 1 of a series of blog posts that discuss what it takes to have an enterprise-ready cloud service. (As a quick refresher, the idea of defining the enterprise cloud was spurred after the media fall-out from the identity hack of Wired’s Mat Honan.)

In the post, I identified the three broad characteristics that differentiate an enterprise-grade cloud service from your typical consumer cloud service: Security, Reliability, and Trustworthiness.

While seemingly simple, these three enterprise attributes can actually be fairly nebulous to attain. That’s why even though hundreds of cloud companies claim to be “enterprise-ready,” the number of true enterprise cloud services is actually much smaller. Only a handful of services – take, for example, Box, Salesforce, Workday, and ServiceNow – have best-of-breed enterprise applications supported by transparent security, reliability, and trustworthiness litmus tests.

So, what makes the true enterprise-ready cloud services different? When evaluating a cloud service at the enterprise level, the broad security, reliability, and trustworthiness categories break down into five different components:

• Development for the enterprise
• Endless 9s reliability
• Benchmarked and audited service
• Strong encryption throughout
• Singular focus on the customer

I want to use this blog post to discuss the first of these components – “development for the enterprise.” Because of their size and complexity, enterprise environments require services that are built specifically for their needs, right down to the level of code development. An enterprise-ready cloud service must incorporate the core principles of security, reliability, and trust into the most basic application levels. The programmatic name for this is Security Development Lifecycle (SDL).

At a high level, an SDL program is a means of including security at the beginning of the development cycle. What this does is provide baseline mechanisms for developers to adhere to – helping them secure coding practices and allowing for feedback on production run-time incidents to be built into the next development cycle. Ultimately, a good SDL program will greatly reduce bug counts, increase code quality, and extend developer skill sets. When initially implemented, these will have the net effect of making an application more robust, stable, and reliable.

The challenge with SDL, however, is that it can be hard to implement. One size certainly does not fit all and every developer – and every development team – is unique. And the impact to development velocity can be devastating if you are trying to shoehorn an SDL into place. Successful SDL programs take commitment and early investment.

As a CIO or CSO investing money into an enterprise cloud, look for services that not only have an SDL, but are also transparent about it. A documented SDL shows that an enterprise cloud service is committed to customer security and reliability. It also shows that the service provider has made a significant investment in their service infrastructure, code architecture, and the people who build it.

The best way to measure SDL transparency is to make sure an independent 3rd party assessor has audited the service on their program. The SOC 2 Type II report is a great audit to look for. This report is the benchmark determination in how a service provider delivers an enterprise cloud service. Achieving a SOC 2 Type II report is not easy (less than 1 percent of SaaS providers are compliant against all Trust Principles), but nothing worth doing ever is. In the next installment of this series, I’ll explore what the SOC 2 Type II audit measures, why it’s so difficult to meet and why compliance is a critical piece of the enterprise cloud.