Over the years, I've probably given 50 unique lectures on various aspects of cloud computing. But one thing has always troubled some of my attendees: understanding which aspects of cloud computing fit with their unique IT strategies.
On the surface, there are all the "as-a-Service" models, ranging from the most common, software-as-a-service, to infrastructure-as-a-service, platform-as-a-service, security-as-a-service, and more. Cybercriminals are even offering cybercrime-as-a-service (which is keeping law enforcement agencies across the world very, very busy).
As I've talked to IT organizations and answered audience questions, it's become more and more apparent that most IT organizations share some attributes and have other attributes that are unique to their lines-of-business and competitive strategy.
Small businesses have also embraced the cloud. Cloud services have given startups the opportunity to grow without having to purchase the infrastructure that the earlier Web 1.0 companies had to do.
Back when I started ZATZ in 1997, we had to buy all our own hardware, lease a dedicated T-1 line (which ran through my bedroom, over my bathroom mirror, down through my walk-in closet, across the hall, and into a converted linen closet. I had a full rack of servers, feeding about a million pages a month, and the company had to buy and set up all that hardware.
Today, you'd just log into Amazon Web Services, fork over a credit card number, and have any infrastructure you want, in less time than it takes to read this article.
When I started ZATZ, WordPress and other blogging tools didn't exist. There were a few CMSs, but they were hundreds of thousands or millions of dollars to buy. I wanted to publish daily (very much like a modern blog), and so I wrote my own CMS.
The thing is, I didn't write it using a common platform language. I wrote it in something called UserLand Frontier. The software worked perfectly for me, but eventually became obsolete. When I wanted to port my entire ZENPRESS CMS (which by then had 70,000 articles), I had to rewrite most of it in PHP. That process took almost three years, using up the bulk of my spare, side-project time.
These two observations become important when trying to create a predictive model of cloud adoption. Some things can migrate quickly (moving half a million email messages to Office 365 took a week using an automated service), while other things (my custom CMS) took three years of dedicated custom coding so I could preserve the unique markup used in all our articles.
Picking a model
What I wanted to be able to provide IT managers with was the ability to quickly see whether their applications would best fit SaaS (software-as-a-service), PaaS (platform-as-a-service), or IaaS (infrastructure-as-a-service). With SaaS, you're using the application that's already built for you. Think Gmail and Salesforce. With PaaS, you're using tools to build your own applications. Think Amazon's S3 or Elastic Compute Cloud. With IaaS, you're running virtual machines, storage, and network in the cloud and maintaining them just like you would your own servers.
So, given an application you're running in your shop, would it better fit into the SaaS model, the PaaS model, or the IaaS model?
To find out, you need to think about two key factors: how complex and unique your application is and how dispersed and diverse your user base is.
Let's start with the Y-axis, which my model labels "Application uniqueness and complexity." It ranges from "custom" to "standard". My ZENPRESS CMS was very, very custom. Meanwhile, our use of email — as long-time Outlook users — was quite standard.
Back around the time I started ZATZ, I also used ACT! as our CRM system. We had a very effective saleswoman who prospected from the customer and lead list we maintained on our LAN. We also used that list to manage billing and support of those customers.
This was back in the days before cloud computing, and we had a problem. She was getting married and moving across the country. We wanted her to keep working for us, and she wanted to keep working as well, but she couldn't access the CRM system. It was tied to the LAN. Had Saleforce existed back then, we would have jumped on it.
That brings me to the X-axis of the model, which is "Geographic and organization diversity of user base." What this asks is what percentage of your users all work from the same facility and what percentage are scattered geographically? It also asks what percentage of your users are part of the same organization. If you're a production company, for example, there might be ten users, each of which belongs to a separate organization, but all working together for a common project.
In the case of my ACT! based saleswoman from the 1990s, she was about to push the geographic diversity slider all the way to the right, from local to across the country.
The Gewirtz ZDNet Predictive Model for Cloud Adoption
So, now let's take a look at what I've oh-so-humbly christened the "Gewirtz ZDNet Predictive Model for Cloud Adoption." The key for each application is to decide how customized and how dispersed your user base is, then plop your application down right at that point. If there's a range (in other words, it's kinda-this and kinda-that), draw an oval that represents the spectrum of use patterns.
Here's an example from my old ZATZ work, with a few more common applications added in for good measure.
Note that the model is designed for how your applications work in your business. A good example of this is the accounting bubble vs. the financial bubble. For us, back in the day, we didn't care how custom the accounting system got. We wanted to send invoices and deposit payments. In fact, we ran accounting on the LAN until we moved to Florida, and we wanted our accounts available during the month of the move, since we had an ongoing business to run.
So, in our model (for our business at the time), accounting was mostly local, but highly standard. On the other hand, look at the financial bubble. For other businesses, the finance engine might well be mostly local as well, but might need a lot of custom hooks to tie into other systems within the company. As you can see, that makes the financial application (again, unique to this example) mostly in SaaS, with a leg in PaaS.
In reality, that means it would be smart for the IT manager implementing the financial solution to find a good SaaS solution that also had a solid API or platform for customization.
My ZENPRESS CMS is down in the lower-left corner, smack in the middle of IaaS. That's because, while I wanted it to be a cloud application, the port was such a huge project that running it out of a VM became the initial mode of operation. Eventually, after three years of coding, it moved into a hosted WordPress site running a pile of custom plug-ins, so it today hovers between SaaS and PaaS.
Now, look at email and collaboration. They could well be bubbles sitting on top of each other, but for readability I moved them apart. They are all about outreach, and while you might want to customize your email, there are actually SaaS services that live on top of Gmail that let you do that, while still sitting firmly in the "off the shelf" camp.
The key takeaway for this model
The key takeaway for this model is you can apply it to your business. I've published a blank template below, and you're welcome to use it and draw your own bubbles and labels.
Make sure you think about how you use your ERP system, how you use your HR system, how you use your custom line-of-business applications. Remember, this model isn't generic. It's tied to the use mode of each application for each particular business.