1. Make sure you know how to get your data out again

Often people think about how they are going to put their data into the Cloud – if they are using Software as a Service, like Salesforce or Netsuite or Intacct or Clarizen, or Google Apps for that matter, they will be thinking about how to get their data into a shape that can go into the system. The documentation for these systems make clear reference to how to prepare and then import the customer’s data, and there are usually consultants who can assist with this process. Typically this process is well planned, but often little thought is given to how exactly you go about extracting the data out again in a way that is of value to you going forward. Often, lip service is paid to the issue by asking questions like “can I get a back up of my data?”, and a reassuring yes is provided to the now comforted prospective customer. It is one thing to be told it can be done, but you need to check that the data is actually in a format that is useful to you. And if the system is mission critical, it needs to not just be useful, it needs to be readily convertible for immediate use.

Some of the things I have done to ensure that my data is safe include writing programs that automatically read the data for updates every fifteen minutes and write them into a Relational Database hosted separately, and even replicated both in house and in the Cloud. All customisations are programmatically managed so that the relational database copy always reflects the structure in the live system. For example, I did this from Salesforce, where there were more than 300 custom objects created. Another example is to write a program that knows how to extract all the data from a system, such as an accounting system, using the API provided. Not until you have actually proven tangibly that you can get your data into a format you can actually use, it is meaningless to have access to a copy of it.

Even without programming, many systems provide some access to your data in a way you can extract it. For example Salesforce provide a once-per-week csv file you can download. If you don’t have an alternative means it is worth setting up a routine with someone responsible to take this data and copy it.

On line databases such as Amazon RDS or Simple DB can be accesed easily enough through OLEDB connections or similar, or copies of the backups can be stored locally in a format that can be opened by alternative data stores.

No matter how you do it, the principle is important here: you should have a fully tested means of accessing your data off line. The more mission critical the data, the more real-time the recoverability needs to be.

2. Think Differently

Steve Jobs’ passing reminded everyone of the Apple Think Different campaign, but seriously, you need to think Differently when it comes to the Cloud in order to leverage it successfully. It truly is different to anything we have seen, and if you are only seeing it as a cost mitigator or a means of outsourcing infrastructure, you are missing a lot of (pardon the pun) blue sky behind the Cloud. Social networking, crowdsourcing, ubiquity of device and location, Metcalfe’s law in general, scalability, the ability to fail fast and loosely coupled web services are all factors of the Cloud that lend itself to being different.

One example is the way that Salesforce enables you to leverage the power of Twitter and Facebook by recording people’s Twitter and Facebook details against their record and if they tweet or post something with a given hashtag, the system is watching and can automatically create a case for them, assign it to a support officer who can find a solution, link the solution and automatically have the system tweet them with a response and a link.

Another example is the way captchas are being used to get the masses to perform optical character recognition on historical documents that are too poor for a machine to read. The system uses a known control word to determine whether you are human or not and poses a second one that is not known. The results are compared against the results entered by others who have received the same word – a high correlation between results from different users indicates what the text is likely to be.

A third example comes from my own testing of the Amazon EC2 platform to test some ideas concerning a new database design that enabled end users to change the structure of the database without programming, kind of like the way Salesforce allows end users to do custom objects. The test was in two parts – the first, which was easy to test, was could it handle more than a billion records. The second, a little more difficult, was, can it handle one thousand simultaneous users on cheap virtual hardware. For this test I needed a simulation that ran across eleven machines. Traditionally I would need to acquire these eleven machines and set them up – an expensive and time consuming exercise. Using Amazon EC2, I was able to set up the machines from scratch in thirty minutes, run my tests in three hours, and then analyse the results. Total cost? Less than five dollars.

There are plenty of ways the Cloud can transform how you do business if you allow it. Get your sales team to focus on harder sells while the Cloud is engineered around a Marketing Automation experience that drives their behaviour for all the low hanging fruit. The Cloud itself, if you configure it correctly, will tell you where the low hanging fruit are.

3. Make sure your systems interactions are atomic

One of the issues with having Cloud-based systems is that you can build compelling processes out of tools from a number of vendors’ systems working together. Linking your CRM to your financials, or your website to marketing automation and analytics for example. While these may seem obvious examples, the point being made here is that we need to ensure when multiple systems are involved that we are thinking about how to prevent a situation where only part of a system succeeds. This is a much more common problem when different types of systems are talking together. So make sure you are not telling the customer that his request for information has been placed in a queue unless you know for sure that the request has been placed in a queue.

4. Start with Upside, not Downside

When I first started looking at Cloud concepts about six years ago I was looking with the eyes of a sceptic and I was asking the question “What can’t I do if I adopt this approach?” By taking this kind of view I found there were plenty of things I didn’t think I could do, and this thinking led me to see restrictions and obstacles. Once I started to ask myself rather contrary question “What can I do if I adopt this approach?”, I started to see all sorts of opportunities emerge. I understand from Salesforce I was possibly the first person in the world to see their CRM product as a business platform rather than a CRM product. This led to building all sorts of systems within Salesforce including purchase requisitioning, customer software licensing, electronic production management systems with automated QA built in and tested on the finished manufactured products (with the results of the tests stored against each product and displayed to the end user when he or she finally purchased the product and plugged it into a computer). Other systems included Human Resources systems with annual leave management systems, individual development plans and hierarchical cost management for each line manager, who could also see things like who had the most leave accrued in the team.

Thinking of what is possible also leads to being able to try things experimentally with a “fail-fast” attitude. The example provided above about the eleven computers is an example of this. But being able to put ideas into practice quickly makes all sorts of innovative approaches viable that may be otherwise ignored or side stepped as pipe dreams.

In traditional approaches, a startup may need to think of architecting a business for the first generation of clients. As the numbers grow, a different architecture may be required, or investment may be required in infrastructure just in case growth may occur. One of the risks of any business that grows too quickly is one of running out of liquid cash. All this can be very limiting in an entrepreneurs thinking, with a real chance that the fear of succeeding too quickly may cause them to underperform. Often the Cloud allows an architecture to scale far further than using traditional approaches, with the ability to consume infrastructure and related services as required, scaling rapidly up, and then if necessary, scaling rapidly back down again. Traditional models require risky investments, Cloud models are far more flexible. And this allows for more optimistic thinking.

5. Check what API options are available

Most mainstream cloud vendors, whether they be offering Software as a Service, Infrastructure as a Service or a Platform as a Service, will have some sort of API that enables you to read and write data, change metadata, set permissions etc. This is important if you want to truly leverage the power that is available to you. For example, you can use Amazon’s Simple Notification Service and Simple Queueing Service to provide asynchronous connections between systems and plan to notify managers when a VIP customer representative has mentioned your company in a tweet. Having a rich API in your bag of tricks enables you to innovate with freedom, seeing the Cloud as one Cloud rather than a disparate products offered by a host of different people.

6. Seek to understand the inner workings of the vendors various risk mitigation strategies

This is something I was guilty of in the early days. I used to say “these guys know better so you can trust them to make sure your data is safe”. Recent events have made me a little more open eyed about the inner workings. If you are not sure how your data is being backed up, ask. Imagine you are having to satisfy your auditor about the safety of your data. Imagine you are having to satisfy your customer that their data is safe, secure and reliably stored. If you don’t know yourself what steps are being taken to guarantee the preservation of the data, you won’t be able to tell them, and you will come across poorly.

I have written an earlier post about an Australian ISP that collapsed after an attack that took out the server with all of their clients’ websites. They had no offsite backup. Recently, Salesforce, one of the most respected companies had two outages on Sandboxes that caused the loss of the customer data on those sandboxes and the data was down for several days. Amazon had a well publicised outage earlier in the year that brought into question the way their system handled mass failure. Separate zones, designed to remain up when others failed, went down simply due to the overload caused by the failure of one. These failures, or at least the Salesforce and Amazon ones cited, have resulted in those companies making some changes, but an astute customer robustly challenging the methods may well have picked them up before a major problem occurred.

7. Remember, it’s your data, and the buck still stops with you

I wrote a post at the time of the major Amazon outage that was picked up by the CIO Magazine. Several companies hosting their data on Amazon Web Services were posting during the outage as if they were innocent bystanders observing the fallout. The reality is that if your services are down it is your responsibility no matter how you host them. Imagine an airline losing an aircraft saying “oops, luckily we outsourced the maintenance on that plane or else it would have looked really bad for us LOL!”. I don’t think so.

Remember, it is your data and you are entitled to it, and your are responsible for its availability and its security.

In the early days, almost every question was about security and privacy, data sovereignty. More recently the questions have been more technical in nature – how to implement, how to handle change management, legal issues around the service level agreements etc.

So it came as a bit of a surprise to speak last week to a room of 150 people almost completely new to cloud at an event held at Google’s Sydney offices. The questions were quite mixed, but they all had one thing in common: the audience hadn’t realised that Cloud computing is different from the way they currently do things.

After years of doing interesting things with the various technologies on offer, it is easy to become complacent about just how radical a difference Cloud computing can make to a business prepared to see it as an opportunity to make real change. So the opportunity to share some basics with this audience was exciting and fresh. They thought Google Apps would bring them a different mail-server. I showed them how it was fundamentally different from in-house approaches: not just an outsourced mail server but an opportunity collaborate and move around untethered.

The freedom to innovate, the freedom to explore, the freedom to dream.

I found it really exciting to see them starting out on this journey that has changed so much.

People see Cloud Computing in different ways. Some see it as a cost cutting vehicle, some see it as a strategy for Greener IT, some see it as just a means of managing virtualising or outsourcing of computer power and storage. Others, including myself, have seen it as a means of facilitating innovation in a world of opportunity without limits. Regardless of the perspective, most people talk “Cloud” but think “Clouds”. I have never subscribed to the view that there are multiple clouds – that is just not compelling enough, too limiting. And yet most implementations seem to end up as competitive islands bereft of capacity to really play a role in synergising for a better world.

Nevertheless, there is a lot of evidence to suggest this pluralised, fragmented and limited Cloud paradigm is being replaced inexorably by a single consolidated view, Evidence of this trend includes:

• Single Sign On technologies providing single points of entry;
• Increasingly convenient and powerful APIs facilitating interoperability and data exchange between systems
• User interface mash ups, initially limited to maps and embedded videos, are increasingly making their way into social networking and business applications, everything from Twitter and RSS feeds to camera based applications like QR and barcode  readers, from financial credit ratings on customers to public ratings on suppliers. For illustration, LinkedIn now provides Twitter feeds and WordPress blog entries without any programming. Facebook includes all manner of embedded games.
• New Social Media platforms take advantage of our need to contextualise our input and output: LinkedIn allows the creation of groups for private or open discussions, and Google+ takes a big step forward in this direction with its concept of circles, seemingly borrowed from the like of Covey’s Circles of Influences and Concern.

A central nervous system provides an efficient means by which the body ensures that the brain’s instructions are followed by the periphery to the letter. It also ensures that any information received anywhere by the body is fed back to the brain in a coordinated way. This can mean that the body can act in advance as an early warning system, or act suddenly to prevent additional trauma. When there is a problem in the central nervous system, instructions become lost or garbled, resulting in poorly followed or ignored  instructions as well as signals that are meaningless, irrelevant or obfuscating. The results of a poorly functioning central nervous system can be catastrophic for the body concerned.

In the enterprise, this is no different. A utopian perfectly functioning nervous system means that the head of the enterprise is able to quickly find out exactly what is happening without prejudice or favour, able to act predictively and astutely with confidence. When such a system exists any instructions issued are carried out faithfully as intended.

Of course, reality is never close to the utopian perfection. Nevertheless, it is the task of the CIO to provide systems that are capable of coming as close the ideal as possible.

In a well-functioning organisation, the Central Nervous System will ensure that relevant, timely and accurate information is accessible when and where the users require it. This will include reports, alarms and other notifications, access to historic records and explanatory memoranda with ease. It will include pre-emptive action based on predictions of future behaviour, for example warnings to account executives that past behaviour on an account suggests that likelihood of future cash receipts is poor. Or notification that the behaviour of a prospect indicates that they are ready for personal contact, or notification to a Support Manager that a Case identified as urgent by a strategic customer is not getting the required degree of attention.

Autonomic systems – i.e. systems that should just take care of themselves (in the human body this would include the heart beating, temperature regulation etc) – will report their successes in a non-intrusive way so that someone can easily see a record of what has happened in the past (say for audit purposes), but will report failures in a way that is compelling.  For example backup drives filling up or security system power outages. (When planes are about to stall the pilot receives feedback in the form of his joystick or steering column shaking violently – this is compelling feedback).

A healthy Central Nervous System will allow proper circulation and all areas of the body will get the nourishment they need. Any area that is not well exercised or fed properly will atrophy. The same is true in enterprise information systems. Areas of the business that are not often accessed, for example infrequently run reports or ad-hoc batch programs that are run occasionally, lists of serial numbers for programs or equipment acquired, warranty documents, or perhaps a system that checks the accuracy of current employee phone numbers may not get used very often and if there is no way to easily access them they will be forgotten.

In a modern business, the rise of social media has changed the way that a central nervous system works. The axons that connect various components and people together are much more likely to take the form of Twitter subscriptions or Chatter group membership.

The role of the CIO in this changing world does not change in the sense that he or she is still responsible for ensuring the flow of signals is unfettered. However, the CIO must become more of a town planner, facilitating means of connectivity, and less of a bus network that provides scheduled bus services that get people and information between predetermined connection points.

Build a strong central nervous system and the business can be agile, responsive, run efficiently and avoid pain points.

Let’s first of all recap what happened.

• DropBox had an incident they described as an “Authentication Bug” resulting from a code update released that allowed any user to log into any account using any password. The security hole was open for almost four hours.
• Distribute.IT, who provide web hosting services had what they described as a “deliberate, premeditated and targeted attack ” on their network. This impacted pretty much their entire business infrastructure and four major servers were irrecoverably lost including all “production data, key backups, snapshots and other information that would allow us to reconstruct these Servers from the remaining data.” The upshot: more than 4800 customer websites, data and email reservoirs eradicated.

In my post dealing with the Amazon outage, I wrote that CIOs need to take personal responsibility for their sites being down – the fact that their underlying infrastructure provider is down is irrelevant. And in the spirit of that, these customers should have personal backups, and certainly some of them do have according to the comments on the website. But the Amazon outage was about pushing the envelope, pushing cloud boundaries. This is different – this is a failure of fundamentals that have been known and understood for 20+ years. I mean, who doesn’t understand the need for offsite backups?

After a day like this it is much harder to be as sanguine about cloud computing in a broadbrush way: I feel today the Cloud lost its innocence. Something very ugly happened and nothing will be quite the same again. Like asking a builder for their insurance certificate of currency, like asking a potential supplier to provide references, like checking a new employee’s resume claims. Perhaps today is the day the Cloud comes of age, the day when we separate out the cowboys from the pros.

Cloud Computing is like the food industry – we go to a restaurant and we trust that the food has not been handled by people who have been to the toilet, that the produce is fresh, that the cooks haven’t entertained themselves at risk to our health. We have systems in Australia and I am sure elsewhere that enable health inspections and public reporting of those who fail them. We have common and statutory law that ensures food is handled appropriately from the farm to the table and that people are punished when things go wrong. We even have public registers that shame bad examples of food processing facilities and restaurants when things go wrong or inspections are failed badly.

I like the fact that DropBox publicised their problem – transparency is good, but you have to have the fundamentals right. And when food producers let rats grow, they should be banned. The same thing applies to businesses making money out of protecting or managing people’s data.

One thing we have learned from the emergence of social media tools is that building applications inside or around frameworks like Facebook, Chatter, Twitter etc have remarkable spin offs that are difficult to predict.

When software is arcane or cumbersome, the entry curve is difficult and typically a few people emerge as the system experts, and others go to them for assistance. These people enjoy their expert status as they are in a position of power – they are able to make excuses for poor response times, they are able to hold the company to ransom. End users are disempowered, heck most of the company is disempowered. Contrast this to the almost inexplicable uptake of tools like Salesforce Chatter, where company after company report 40% reduction in email, wide adoption from the grass roots and greater control over business exigencies at all levels of management. Observe how many business have arisen in the Facebook ecosystem to do all sorts of things. The value people now place on virtual flowers and seeds is nothing sort of astonishing.

If companies want to be truly successful in this new world, their systems need to be so open, so generic, so inviting, that all team members, partners and customers can access them in ways that allow them to explore how to eke benefits that the designers haven’t thought of.

Designers and Implementers in the past were like bus drivers: getting people on board and then taking them to a given destination, perhaps not even known to some passengers. Today they need to be come like traffic police, or perhaps guides or coaches that facilitate the movement down whatever roads the users want to follow. Who knows what they might find?

Think about it for a second: how many frameworks do you know of that enable you to modify the data schema and automatically set:

• Relationships between objects;
• Indexes;
• Cardinality rules, (definitions of how objects relate to each other in terms of how many of one can be related to how many of another);
• Business rules, (what fields are mandatory, what fields are dependent, default values, what fields are read only or even visible for certain users, which fields must be unique);
• Referential Integrity rules (which records will be deleted when a parent is deleted);
• A User Interface, even one that can be different for each user profile;
• Application context (which objects belong together to form a sub application;
• Access to reports; and
• A Notification engine that can share changes with subscribers or record owners, or handle task assignments.

And all with a point and click interface – no programming required (unless you want to), and all with defaults to allow you get the job done quickly. Very quickly.

For illustration, I once demonstrated an application I wrote for an HR subsystem to manage individuals’ development plans. Each plan represented the results of a bi-annual employee review. Each plan had multiple objectives, each objective had multiple Action Items and each Action Item had multiple Tasks. Each could be assigned to the employee, the manager, the HR representative, or someone else. There was a complete user interface, tThere was a full notification system, a well defined security set that prevented inappropriate access and a reporting system. There were two people witnessing the demonstration, one a CEO of a software house and a consultant. When asked to estimate how long it had taken me to write, the software house CEO estimated four months, the consultant laughed and said, “knowing you, you probably did it in a week or two”. The truth was it had taken me less than two hours.

But I digress.

While I think this is fantastic, exciting, liberating, I feel there is something missing, something that would increase the power of the Salesforce offering substantially: the ability to add multiple related lists to the same page layout for the same related object with different filters. “Huh?” I hear you say – allow me to illustrate:

The image following is an extract from an Account page layout within Salesforce using the standard off-the-shelf page layout for an account. This shows a list of the opportunities related to the selected account. You can see that there is another related list following related to Quotes, but I have only included the header for context – you can ignore that. So what follows is a list of all the opportunities for the account I am looking at.

A related list of Opportunities embedded in an Account

The trouble is that I am not interested in seeing all opportunities, in fact an opportunity that is closed is not really an opportunity when you think about it – it is what used to be an opportunity – but that is another digression. What I want to be able to do is have a list of all the current opportunities, another, separate list of all the recently closed opportunities, perhaps separating the recently closed won opportunities from those lost. You may wish to see  a separate list containing only large value opps, or high probability apps, or opps that are going to close next week.

What about a list of tasks that your team are responsible for? What about tasks that are associated with high value accounts, or that are overdue?

Perhaps you would like to create a custom object that stores, for each account, a list of demonstration loans: products you have sent to them as samples, and you only want to include those that have not been returned.

There are so many ways I could see this facility being used I can’t quite figure out why it isn’t available. Sure, you can do it with programming using an Apex controller and a Visual Force page, but that completely misses the point of the power of the platform.

Watch out for more Things I Want to See.

An increasing number of people are coming to understand intuitively the difference between traditional peer-to-peer document sharing modes where multiple instances of documents exist, at least once on each client machine. You know the drill, you attach a document to an email, the recipient opens the attachment, edits it, saves it and then attaches the saved new version to a new email and sends it back. Before long, there are multiple copies of the document and it can be difficult to know how the document evolved. In the case of several people, it can even be difficult to know which version of the document is the current one. There may not even be one single latest version, as two people may edit two different earlier versions at once. Stitching these all back into a master document is not easy.

A lot of tools have been developed to simplify the potentially incredibly complex task of managing all these document versions. But the cloud provides a simpler way, by fundamentally only having one document location. So instead of linking people to people, you link people to documents and the problem elegantly goes away:

Diagram 1 – Handling shared documents

Traditional Document Sharing	Cloud-based Document Sharing

In the case if email, we have failed to really make this transition. Yes, we have managed to cloudify our email repositories so that they are ubiquitously available to us – any place, any time, any device. But email still acts on the basis of person to person: we send an email and now the email is in our outbox (wherever that may be) and it is in the recipients’ inboxes (wherever those inboxes may be). To be clear: we still maintain separate repositories for emails – they may be in the cloud, but they are no different conceptually from being on our desktop or on a corporate server.

But it would make so much more sense to me if emails could be stored in one central location – just like documents – and accessed by those who have entitlement. I sense there would be a lot of real benefits from this approach, including:

• The ability to recall an email prior to it being opened by the recipient – in a way where they are none the wiser;
• The ability to prevent them from sending the email to a third party;
• The ability to know whether they have opened the email (unless they actively prevent you – I think that privacy aspect should be maintained);
• The ability to modify an email after sending it, but showing very clearly that it is a second version, with the ability to see the earlier versions.
• Perhaps the ability to use it as a real-time communication tool.
• The ability to define relationships (eg followers/friends à la twitter, chatter, yammer, facebook, linked in etc) – these relationships could ensure that a sophisticated sharing/action platform could ensue, as well as actions that may happen in their absence (anyone heard of spam?) – also think Google Priority Inbox – a nice concept.

The host for this data could be a public cloud environment, or it could housed on premise, but that would limit the scope of the functionality – in some cases a good thing.

I know this is starting to sound a lot like  Google Wave in places, but this is not about productisation, or complication or adding lots of features – it is about simplifying and facilitating the fundamental ways we communicate.

There are a few notable properties about emails that differ from regular documents and these would need to be maintained, including:

• Access granted to a recipient, once opened, could never be revoked;
• The email could never be deleted, once opened by the recipient;
• The recipient could not change a sender’s communique, but they could reply – this could be done in a way where there were edits suggested, and the original sender could click to approve those edits, perhaps converting to a document in a process.

Increasingly people are voting with their feet to move away from email, but perhaps we need to re-examine the way we think about email and perhaps the problem is fixable by examining the foundations and making some fundamental adjustments.

When we don’t really understand something, we see division, we see dichotomy. We see the things that differentiate and we hone in on them, creating opportunities by exploiting these differences and in so doing we limit our thinking, our judgement, our potential. We become experts and protect that expertise by making it difficult for others to gain the knowledge we have. Knowledge is power, having more knowledge than others gives us an advantage.

It usually takes one visionary person to challenge the basic assumptions that lead to these differences, and when that happens, entirely new vistas open to us, empowering those who were shut out by providing access to the knowledge or exposing the differences as being false divisions, false barriers to entry.

Computers are like this. In the very early days, only people trained in the arcane would be able to (or want to) access a computer. A computer operator had to be able to read ticker tape, write in binary, then assembler, then Fortran. Screens and keyboards made computers more accessible, and then graphical user interfaces hid much of the complexity.

Programmers have been able to work with increasingly high abstractions, but still we haven’t really been able to get away from the need to be able to program, or to purchase tools that hide this from us – tools that automatically do backups, convert file formats, transfer data, dial the phone, send communiqués or whatever.

This seems to be changing very quickly – increasingly it is becoming possible for people to choose to configure existing systems rather than being forced to find a programmatic solution.

What is interesting here is the trap this represents for some people on both sides of the fence – those that understand how to program and those that don’t.  Clearly the people who focus on the end objective, rather than the means of getting there, will adapt as technology becomes increasingly available to non-programmers. These outcome-oriented people have a distinct advantage.

Those who only see the barriers will continue to use old methods. End users will remain in fear of the unknown, while programmers will continue to look for programmatic solutions, even when both are presented with tools that can get the job done without code.

Cloud Computing makes it easier to facilitate the kind of advances described here, advances that empower end users to achieve change without programmers. This is because Platforms and Software delivered as a Service typically mean there is only one version of the platform or software in use by everyone – it is literally impossible for anyone to get left behind. Vendors can work to cover a lower common denominator because it is worth their while. Salesforce.com is a great example of this.

The bottom line: Those that focus on the technology will be left behind in a world where we were slaves to technobabble. Those that focus on what they want to do will realise the rules have changed and will be astonished at just how far they can take their vision without breaking a sweat.

Telecommunications companies face a difficult decision as they see their traditional business eroded by new entrants using completely new approaches to linking people together, but how do they perceive their business? Is it:

1. provisioning infrastructure?
2. facilitating communications between people from afar?
3. enabling information to be shared remotely between people?
4. enabling information to be shared between business objects and people?