No Business, No Cloud, Vice Versa!

Over the past few weeks, I’ve had a bunch of great conversations regarding how organizations should start to prepare for delivering cloud services.

One aspect which continually pops up as a blind spot is the relationship of the business on the cloud service. In this post, I’m going to use some of my own science to describe one of the key elements every cloud service provider needs to think about, and that’s business.

In the traditional software market, the product pipeline is pretty much serial. You can rearrange the blocks how you like, but for a majority of the companies I’ve worked with, things move in a linear sequence, that looks something like this:

This was fine when iterating between the steps to get the product right was part of the schedule, and releasing a product took 2-3 years. But as we’ll see with cloud, this is not the case anymore. Speed to market, and a very mobile customer segment means you may not get a second bit at the cherry, so you better ship a quality, meaningful service day 1, or go home.

The second issue is based on the perception many engineering teams have around features and requirements. In the glory days of software, when software was sufficiently far away from the customer and their business needs, designing features which were wholly value-add was very achievable. Let me use the early operating systems. When no one used computers, and very few knew what their value could be, creating software in a vacuum was the norm. When you released said product, the marketplace responded favorably. And they could use these new tools to help in back office functions or administrative functions, which were far more about utility and administrative efficiency than business function or value.

This has changed significantly though, and now, the distance between technology and the customer from a business perspective is far shorter, which means the infusion of business necessary features are as important, if not more, than standard plumbing style features no matter how value-add they may be.

This brings me to the feature lifecycle, as it relates to cloud based services. The initial product backlog needs to be derived from two different interactions with customers. The first is based on what they “want"”:

This is all about identifying the features that will entice the customer into selecting your technology over any one else’s, or motivate their buying decision over what they have today. These could be business level features or infrastructure features, but here comes the rub, these mean nothing without the table stakes of cloud computing, the “have” features.

In business, there are imperatives that in today’s software market, where technology is no longer a back office enabler but a critical success factor to most organizations, must be part of a cloud service. What do I mean by this? Take compliance for example. If you are about to deliver a cloud service that deals with peoples personal data, you better make sure somewhere in your service stack, is the ability to demonstrate compliance with the laws and regulations that involve peoples personally identifiable information. Ignorance as many of us know from watching Law and Order is not a defensible position. You either need to ensure your service complies, or your platform provider has compliance already baked in, or you push this requirement onto the customer. And while cloud services rock in terms of composability, it’s like buying a car with no seat belts. Sure, I could drill some holes in my new Ferrari and attach some rope, and probably be compliant, but I’m pretty sure me and every other customer would rather see this kind of “feature” added at the factory. New wheels on the other hand, could go either way. So if you get to the decision point of whether business imperative feature x is your responsibility or someone else’s, just ask yourself, how many of our customers are going to demand this as a min bar requirement, and is it easier for us to implement it once for everyone or not.

So where does all this hub bub leave us? A pretty simple model, we take the current serial approach, and like good little distributed cloud engineers, we parallelize it:

What we get is a far more rapid, business aligned, service release model. It means we can setup multiple instances of this for multiple features, so the longer and shorter ones don’t get tied up unless there are blocking dependencies. We also ensure the time to market is shorter. And those table stakes we spoke of before, are able to be shipped quickly to get the customers lining up, while still having a cadence for more enticing, value-add features, built on the solid service base.

Now I agree, it sounds kind of simple, and while I agree that there is much hard work required in the background, especially from the discipline and governance perspective, but the great thing is, with the right amount of planning up-front, getting this into you organization is completely achievable.

As always, I would love to hear your thoughts on this.