When putting together a cloud strategy for your company, it is easy to overlook some of the organizational challenges that must be overcome in order to be successful. Every company that has taken the plunge into the world of cloud computing has a war story or two to share. There is no user manual or instructional video to prepare you for some of the obstacles that must be overcome. The best you can do is talk to people who have travelled down this road and learn from their trials and tribulations. The following is a short list of war stories that either I have personally encountered or a client has shared with me over the years. I call these the cloud’s dirty little secrets because all of these were learned the hard way.
Becoming a SaaS company is radically different than selling software products
When software is shipped as product, the business processes, the operating model, and the application architecture is very different than in the always on, software as a service model. SaaS is a mindset change. We are no longer shipping products, instead we delivering a service.
A good analogy is comparing selling Starbucks coffee in a grocery store versus serving coffee from a Starbucks cafe. In the first scenario, a lot of time and energy is devoted to creating and shipping a product to a wholesaler or retailer. Once the product is shipped, you are done with that product. Creating and shipping new versions of that product takes a really long time because of the effort required to change packaging, make new flavors, perform all of the market research and so on.
Serving Starbucks coffee from a counter is very different. Customer interaction now becomes as important, if not more important, than the product itself. The products and service are on display in real time so the quality of service, the cleanness of the operation, and responsiveness to real time events are crucial.
Now let’s compare that to software. In the old shipped software as a product model, once we shipped the release we were done with the software and could move on to the next project. In the SaaS model we are delivering a service. We are never done with the software. The software must always be on and a lot of effort must be put in to creating software that has high availability.
Operating in the SaaS model is a very proactive practice. We now own running the software, updating and patching it, capacity planning, and all of the operational tasks that buyers of software products had to deal with themselves. Now the buyers are just renting a service that must always work and work better than our software ever worked before. This means that we must create a proactive culture that does everything in its power to head off problems before our customers are impacted where in the past we used to be in a reactive support model where we waited for tickets to be opened from our customers.
The sales and incentive process is very different too. The days of selling very expensive software and then sitting back and collecting 18-20% annual maintenance costs are long gone. Now we are selling a collection of services from a menu that buyers can turn on and off as they please. Buyers are not as hooked as they used to be when they were forced to make huge capital investments so customer satisfaction is more important than ever.
Secret 1: Companies moving to SaaS must become a services company which requires a transformational change across the organization.
Customers’ fear of cloud security demands much higher investments in technical requirements
Another dirty little secret is that product managers will have to make much larger investments in the areas of security, compliance, and auditability. Regardless if the service is handling sensitive data or not, enterprises buyers of SaaS are demanding SSAE-16 SOC2 audits, ISO and Cobit standards, documented and tested disaster recovery processes, high service level agreements (SLAs) and many other technical requirements that go far beyond what was expected in the software product model. When we shipped software to customers, they took on the responsibility of securing the infrastructure and software, they handled backups and disaster recovery and they dealt with the regulatory issues and auditors. In the SaaS model, that all falls on the cloud service provider.
Secret 2: Expect to make much larger investments in technical requirements and to deliver higher security and compliance than ever before.
Some of your engineering staff won’t have the chops to architect software for the cloud
In the products world, it was much easier to hide your warts. Just like with the Starbucks example, when shipping products, the performance of employees was hidden from the outside world. Customers only saw a shrink wrapped product. When selling Starbucks coffee over the counter as a service, the employee is front and center and performance is easy to see. The SaaS model is similar. Although the customer will not see the engineers personally, they will witness the results of their craft 24×7. The software most be more reliable than ever before. There is no longer an opportunity for developers to hand hold the programs and run little fixes in the background to keep the lights on. Building software in the SaaS model requires real engineering, not just drag and drop programming. Engineers must pay a lot of attention to the “ilities” (scalability, reliability, availability, etc.). High SLAs must be met. High levels of security must be built. Software must be able to be deployed with minimal or no downtime. Software must be self-aware and self-healing. This is where we separate the men from the boys and the women from the girls. Real engineering is required.
Secret 3: Building SaaS solutions that meet customer expectations requires very skilled engineers who can learn new ways of building software and are capable of building software that is always on. Not everyone on your staff will pass this sniff test.
Many of your current tools are not the well suited for the cloud
Datacenters are very different than clouds. The tools that we have used in our datacenters for years are often not well suited for cloud environments where infrastructure comes and goes. Many of these tools depend on fixed IPs, application state, and physical location of assets. In the cloud, IPs are dynamic, everything is stateless, and we don’t know or care where the physical assets are. A mistake a lot of companies make is that they take their old tools and processes with them to the cloud and try to put these square pegs in round holes.
Secret 4: When building SaaS solutions, take the time to reevaluate all of your legacy tools and processes. Expect to change many processes and replace many tools. Don’t let loyalty to a vendor solution hamper your cloud operations.
Releases must occur much more frequently and more flawlessly than ever before
Going back to the Starbucks example, when shipping product to retailers and wholesalers, you want to minimize the amount of times you change the product offering because of the complexity and high costs of distributing products. It makes sense to make big product releases only once or twice a year to minimize confusion in the marketplace. When serving coffee at Starbucks, it is necessary to introduce changes frequently in order to provide a better service experience to your customers.
The same applies to software. In traditional product based software, customers are responsible for installing the product in their environment. They also have the choice if they want to upgrade or not. Delivering new product upgrades frequently does not make sense in this model because the customer has a business to run and does not want to spend the time constantly updating software.
The exact opposite is true with SaaS. Since the customer is no longer responsible for upgrades, they want more features and fixes more frequently. They also don’t want to experience down time when these upgrades occur. That means that the software provider’s SDLC (software development life cycle) needs to be geared toward frequent releases, with automated builds and testing, and a deployment process that doesn’t demand down time. This is another example where the product manager needs to understand that he or she must make a much heavier investment in technical requirements.
Secret 5: Delivering software as a service requires a much more robust and automated SDLC. quality, availability, and automation requirements are higher than ever before.
These are just 5 of many dirty little secrets in the cloud that your cloud providers won’t tell you about. They will say how easy it is to build software in the cloud and they are right. What they won’t tell you is that it is hard to transform an organization from a software product mindset to a software service mindset. If you are leading an effort to build a cloud strategy within your company, don’t overlook the fact that becoming a service based company is transformational and every department, not just IT, will be impacted.