I attended a pre-proposal meeting last week, where a very large company was asking their vendors and other interested parties to comment on and ask questions about their software selection process. A group of five in-house managers had been assigned to create this process and the written specification. Now the five of them were present to attempt to explain and clarify the written document we all had in our hands. Just for a little context, the audience was composed primarily of high-level managers representing vendors or their supporting partners. Most of them seemed very strong in understanding the proposal from a financial and business implementation perspective.

Very early in the extended Question and Answer period, the issue of Cloud Computing came up. The preliminary spec was asking that the next generation of software be more “Cloud-like.” The audience was obviously looking for clarification. Remember this wasn’t a technical audience and even if it had been, the specification wasn’t really clear. The moderator of the panel asked if anyone else on the panel could explain Cloud Computing. No one volunteered. The audience laughed a bit. He smiled and then asked if anyone in the audience could give us a brief definition. Dead silence. He smiled a little wider and said, “does anyone here know anything about Cloud Computing?” That was it for me. I had to put my hand up.

I explained to the room that Cloud Computing is the idea of delivering common business applications like word processing, spreadsheets, contact management, and so forth online, accessed from a Web browser. The applications and the data are stored on servers that are somewhere on the Internet—hence the concept of the cloud. A person or a business should be able to see the computer world as a cloud, where they can pick and choose from the applications and services they need and want at the moment. I then went on to describe some of the current business models that were out there. I finished by talking about the current public offerings like Amazon, Google App Engine and Microsoft Azure. I was kind of proud of myself for trying to connect with them on a business level and from comments I later received, I think what I said was helpful. Unfortunately it didn’t really address the specification or a real need by this group. I didn’t realize that at first, but as I sat down, I started really wondering what the panel meant by making the software more Cloud-like.

The company already has a first generation version software product. How is that product delivered? As a Web application. Since one great example of providing software on-demand as a service is a Web application, the existing product is already on track as being “Cloud-like.” Even more strange, the ultimate users, a number of in-house business units, pay only for what they consume. This is very much according to the Cloud Computing “metered service” approach. Yet despite these two critical Cloud elements, they needed the next generation to be more Cloud-like?

So what was I missing? What part of the Cloud model were they talking about?

As the meeting continued on into the afternoon I kept getting little bits and pieces of information. I talked to 3 of the 5 panelists personally. I even took a 5-minute break to read the Wikipedia article on Cloud Computing and do a little Web research. I’ve been an active developer of Web Services and Web Applications for almost 6 years now, so I feel I’ve been a genuine contributor to the current Cloud infrastructure. Never-the-less, I left the meeting convinced that I hadn’t really understood what piece of the cloud they were missing.

A few days later, as I was reading my nth article on the Cloud, I stumbled across what part of the Cloud they were having a problem with.

At the meeting I had been told something by one of the panelists about what it takes for a business unit to adopt this software.

The company requires its business units to use software only from vendors who are on the “approved” list. This requires a time consuming evaluation period including things like face-to-face presentations and pre-scheduled software evaluations. Mind you, this is even for a Web application that is hosted off-site and uses a pay-as-you go model. When a business unit chooses a new vendor they need it to work with their own back-office accounting and their own business rules, so for each “roll-out,” the vendor, along with the business unit, have to customize for the business-unit’s back office. Just to be clear, every business unit has one or more of their own unique back office applications.

So here we have a metered, no-install Web application, but it can take over a year to adopt? It’s crazy really. I think the Cloud piece that they need next is the adoption piece.

Adoption is a key element of the Cloud. A Cloud offering needs to have the quickest and most efficient adoption possible. Any Cloud offering should aspire to little or no adoption time. This allows for the end user to turn on a dime and change to another software offering in the blink of an eye. If they can’t do that, then the software that they are using is bound to become stale.

To me, there are two problems to solve. First, the evaluation period needs to be cut down. Second, the back-office customization needs to be dragged into the Cloud age.

I would replace the current evaluation, with an iPhone App Store approach. When a vendor submits their software for review it goes through a set of automated tests to ensure compliance. If the software passes the tests, then after some small subjective evaluation (1 or 2 hours at the most) the software is placed into the hands of any and all business units.

Addressing the back-office seems pretty straight forward. Even though each business unit has its own back-office, there really is only so much information available from the vendor software, so to me, that’s where to start. Build a Web service into the vendor’s software that allows any and all back-offices to request and receive the information they need. To me, this would be a simple W3C compliant Web Service. This “channel” into the needed back-office information would be part of the specification, and to be considered compliant, each vendor would have to implement it.

The first migration would still be difficult, but a lot easier than it would have been. Just using a standard Web service makes things go smoother, speeding adoption and reducing errors. The real advantage though is that once this back-office connection has been written, the business unit can switch to another vendor in the blink of an eye.

With adoption effort, time and cost down to almost zero, a business unit could quickly change from one vendor’s software offering to another in the blink of an eye. This gives the business units a real advantage economically. It also is very helpful to the vendors as well. Vendors who give a good presentation and do good customization work aren’t always the ones with the best software offerings. With an inexpensive adoption model, vendors can focus their efforts on getting their software right and keeping it fresh into the future.

I was kind of skeptical of the Cloud model up until this experience. Not because it doesn’t make sense, just because it seems more of a buzzword than anything. Strangely enough though, when I was forced to look at this project from a Cloud perspective, I discovered something very useful. The Cloud means many things to many people, but when you look at something like software adoption, I think most would agree that zero-effort adoption is definitely the Cloud way.