Building a predictive model for cloud IT adoption

Building a predictive model for cloud IT adoption

Summary: Our own David Gewirtz introduces a model that is able to provide IT organizations with the ability to quickly see which of their applications would best fit SaaS (software-as-a-service), PaaS (platform-as-a-service), or IaaS (infrastructure-as-a-service).


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.

Axis labels

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.



Topic: Cloud


David Gewirtz, Distinguished Lecturer at CBS Interactive, is an author, U.S. policy advisor, and computer scientist. He is featured in the History Channel special The President's Book of Secrets and is a member of the National Press Club.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Great article

    IT Managers often don't quite know what they want from cloud and they're understandably nervous about making a mistake or moving outside their comfort zone. Similarly some smaller cloud vendors often don't know how to sell their service; those that are successful know their target market well and how to sell to them. I blogged about this earlier today and then coincidentally found your article.
    Richard Bishop
  • I think there needs to be two more aspects

    privacy and security...

    If you need the data to be secure should it be local or remote...

    If you need the data to be private should it be local or remote...

    Which makes things a good bit more complicated.
  • Points to consider

    I do like this model as it is very simple to understand and follow. I am pleased with the thinking but also have some additional points that you could consider for the next version.

    1) Some venders large and small are moving to a 'SaaS only' model, infact the 'HR Employee Recruitment' market has almost 100% gone this way.

    2) What is also a major consideration in the choice of whether to I/P/S-aaS is complexity of data integration, not just Infrastructure. The traditional Enterprise Service Bus approach has taken a hit in the last few years with the rise of the API brought on by the utilisation of Mobile Apps. Companies are whole-sale reducing this complexity by employing the badly named 'API Virtualisation' technologies such as for example. Badly managed the data connectivity spaghetti moves to the cloud but another story. However, in my experience many Cloud providers will happily 'make this problem go away' for additional funds especially if they get to keep the IP, i.e. someone has just paid for the development of a feature that they can be resold to other customers.

    3) The next thought is protection. If something is sensitive such as customer/employee/financial data some companies will risk assess whether they ever want these services in the Cloud. If they do use a Cloud service then many will want to keep a 'local copy' as protection so can make change easier to handle. Some organisation do not even consider this so guidance on risk is a hole to be filled. Companies must protect themselves against 'Black Swans' and can be to trusting that a Cloud provider will make all eventualities go away and this landscape constantly changes.

    4) My last thought is old father time! The market place for Cloud is changing as quickly as mobile phones so there is no point in having a business case where the ROI pays breaks even in year 5 as to much would have changed by then. Companies must have a plan to review regularly and be prepared to changes just as frequently so 'tightly binding' to a Cloud provide makes no sense so therefore having a standards that are portable and abstracted have become extremely important, again something that is rarely considered in the race to save costs.

    I'm happy to discuss further as I have a fair amount of experience in this.