As cloud evolves, there will need to be some fairly fundamental changes in how things are done.

If all that cloud manages to do is to shift the platform focus from the corporate data centre to an external one, then cloud will have failed.

If it moves towards the capacity for an organisation to create a description of a business process that is then broken down into a set of tasks that can be facilitated by discrete technical functions pulled together from multiple sources, then the cloud will have been the game changer that many hope it will be.

But, this brings in many problems.

Firstly, tools are needed that allow an organisation to describe its business processes in a suitable manner. Then, intelligence is needed to break these down into the discrete tasks. Both of these are not beyond the capabilities of some tools out there at the moment—CA’s purchase of 3Tera is leading towards something along these lines as part of its Cloud Connected Management Service (CCMS).

But then there is the problem of finding the technical functional components that can be brought together from the cloud to create the composite application that facilitates the tasks and therefore the overall process. This requires some serious thought—and some changes to how the cloud is building at the moment.

At the moment, the approach tends to be along one of three basic lines:

• Cloud is just a means of a multi-hosted environment, such as salesforce.com, KashFlow or Symantec MessageLabs. The organisation knows what it wants and goes and gets it from a single point provider—essentially as a software as a service (SaaS) model
• Cloud is a means of gaining access to functionality that adds to existing enterprise applications. Here, data from, for example, an existing CRM system can be plotted against an external mapping capability to graphically see where clusters of customers are in the form of a mash-up. Again, the user will generally need to know the source of the function they are seeking—such as Google or Bing.
• Cloud is a “hidden” function. Certain fundamental functions are provided via cloud-style approach, such as updates to anti-virus definitions, the provision of clipart to Microsoft Office and so on. These are completely hidden to the vast majority of users, and are part and parcel of a certain function within an application.

But let’s wind forwards a little. In however long a time it takes, the cloud has become a source of lots of different choices for the functionality you want. You want to have a function that deals with all calendaring across the whole of your business? Congratulations, there are 12,000 to choose from. You want to use a customer data capture form? Take your pick from the 115,000 that are available. You want to back up your data to the cloud? Already there are hundreds of available solutions for this—so we’re not looking that far out for the other examples to become a reality. But how do you choose the best function for your needs?

As with crowdsourcing, where the reach of social networks can provide insights that would not be available from just polling a small constrained group, the same issues will be there when cloudsourcing.

Just because Joe Bloggs says that something is the case doesn’t make it so—there has to be corroboration around the information, and there has to be trust between the requestor and the information supplier. Similarly, accepting that, for example, JB Data International, Inc is the right company to capture your customer information—including credit card details—may not be the best way forwards.

Firstly, there is a need for different types of functional directory—maybe one that is open for anyone to put their details into and one that is a value-add directory for functions that have been checked and validated in some manner. Then, there has to be the capability to negotiate a technical contract on the fly. Here, a request has to be made from somewhere that doesn’t just say “give me some mapping capability”. It has to say what level and style of mapping capability it needs.

For example, an XML metadata schema could be created that enables a request to be matched with a function. Here, metadata gives details on areas such as the number of requests the function can deal with over a period of time, the expected response time for the function to work within its own area (latency of the overall network would also have to be taken in to account), cost per transaction, per usage or subscription level pricing and so on.

Maybe even a protected field that provides some form of a score based on feedback from users as to how well the function has performed for them. On-the-fly service level management—or a cloud service level (CSL) mechanism, as it were.

Through this means, an organisation can use the cloud properly. It can make a “blind” request and gain responses only from the owners of functionality that meets the organisation’s immediate needs. This opens up the cloud to being a highly dynamic and workable model based around the provision of combinable functions, where the organisation that needs any function does not have to waste time in hunting down providers in the first place—and in then figuring out whether the functions identified will meet their real needs or not.

The cloud promises to put technology back where it should be—in a position that supports the business and does not constrain how things should be done. It would be sad to see a lack of flexibility in the cloud just move the corporate focus from large (often badly engineered and constraining) applications in their own data centre to large (often badly engineered and constraining) applications in someone else’s.