The Business of IT

Three Critical Pitfalls to the Success of Cloud Offerings

Whether you operate IaaS, PaaS, or a SaaS service, watch out for these three pitfalls to the success of cloud offerings:

  1. Encouraging the wrong thing. Measuring the success of the offering by looking only at utilization metrics damages sales. One cloud service provider measured the success of its IaaS service – and compensated its sales force – based on virtual machine usage. Little surprise that, for all the years that this practice continued, the provider could not land strategically important accounts. Like in any mature sales operation, your prospective cloud service clients should be evaluated based on several criteria, including:
    • strategic fit
    • urgency
    • reputation
    • visibility
    • cost of sale
    • short-term sales potential
    • long-term sales potential.

    Make sure you evaluate all these elements, and that you prioritize your sales and marketing efforts toward prospects with the right combinations of all these factors.

  2. Ignoring the relationship. On-demand and pay-as-you-go are not simply usage models; they are components of a new type of customer relationship based on transparency and immediacy. Make sure your customer relationships allow for:
    • Seeing usage and  billing easily, and up-to-the-minute.
    • Setting custom notifications and enforceable consumption limits based on both usage and cost.
    • Getting quick notice of service degradations and their ongoing status.
    • Being reassured after service disruptions that you have identified the cause and taken steps to prevent a reoccurrence.

    Your service may have other ways to build a customer relationship based on transparency and immediacy. Identify and exploit them.

  3. Focusing on infrastructure reliability. Selling a cloud IaaS service that differentiates with higher level of service reliability is not sustainable; instead high-SLA workloads must be built using cloud-appropriate designs. Any IaaS provider who tries to compete against the commodity non-reliable infrastructure clouds by offering a higher SLA engages in an unwinnable battle: the cost structure will make it impossible to compete against commodity offerings. As computing services become more commoditized, previously established patterns of infrastructure usage (aka “best practices”) that called for highly reliable hardware and “N+1” architectures are architecturally moot. Following those patterns in the cloud will not increase overall workload reliability. Instead, workloads that use cloud infrastructure need to be designed for scale-out and rapid recovery from infrastructure failure, providing overall workload reliability via software. The overall cost of reengineering workloads for cloud-appropriate architecture will, in the end, be less than the cost of building and operating a cloud that delivers a “classic” hardware-based HA.

Don’t make these mistakes. They could be killing your cloud business.


Cloud Developer Tips The Business of IT

Software Delivery Operations

Like companies producing any kind of offering, software companies require three elements in order to successfully deliver: knowing what to build, knowing how to build it, and knowing how to deliver it to the customer. When each of these three functions – research, engineering, and delivery – does its job independently, you get slow progress and uninspired, sub-par products. But when all three functions work together in a customer-centric fashion, you get excellence – in implementation, innovation – in concept, and world-class results – by delivering those two to the customer.

With the explosion of internet-based services in the past decade delivery has by necessity become an ongoing activity. And so in recent years much attention has been devoted to integrating development with technical operations – DevOps. DevOps integrates into a single team the skills of how to build the service and the skills of how to deliver it. But, as pointed out earlier, DevOps teams often lack the most critical element: the customer’s involvement. DevOps teams can build and deliver really fast, but don’t know what to build.

Integrating development with the customer-facing functions (marketing, sales, etc.) without technical operations results in an organization that knows what to build and how to build it, but doesn’t know how to deliver it to the customer. This organization is full of ideas – even innovative ideas – and implements them, but they don’t see the light of day. I call this a “feasibility practice” – it can show you what is feasible but it can’t deliver it to customers.

Teams that know what to build and how to deliver it to the customer, but not how to build it, also do not provide value to the customer. Such teams are close to the customer both on the inbound (understanding the customer’s needs) and the outbound (explaining the company’s offering) directions. Marketing sits squarely in this space: it knows what to build and how to deliver but can’t transform that knowledge into value for the customer.

As an executive leading a software delivery effort, make sure your organization occupies the very center so it can understand, build, and deliver the right value to the customer. The customer is here in the center as well: he participates in validating the ideas, critiquing the implementation, and accepting the delivery. It is only here that your organization can achieve excellence, innovation, and world-class results.