What is cloud?

A debate rages on Twitter as to what constitutes cloud computing.  It was inspired by my previous tweeted post and draws upon Public Strategist’s articulate post on the very subject.  I say “rages”.  It drew a few shy of 20 comments, retweets and points of discussion.  (It’s all relative.)

First things first.  I’ve decided that, like internet, cloud will hereafter be lowercase—in my world at least.  Its gratuitous capitalisation has done nothing but make a big deal out of something that was happening anyhow.  So if we lowercase the C [sic], we won’t attract eyeballs and will be able to get on with the job in hand.

To me, cloud means nothing more, nothing less, than shared.  I posted a year or so ago about my forays into cloud computing.  For the record, I regard myself as unusually bold in this area, having divorced the majority of my stuff from my desktop and moving it into a shared resource, a cloud, if you will.

But I was thinking that actually, in addition to my computing examples, my car usage is also cloud-based.  I am an avid fan of Streetcar.  Their cars are shared resources that can be called upon by anyone, subject to availability, much like the Boris Bikes that have become so famous.  I see these as no different to the computing resources that I call upon.

Any computing resource that is shared by more than one individual, department, organisation, should be regarded as cloud-based.  And the greater its level of sharing, both of code and resource, the more cloudy it should be regarded.

A shared drive is probably the lowest form of cloud computing.  Hotmail should be regarded as the pinnacle, with an estimated 360m active accounts.

For government, there are certain aspects of computing that just aren’t in the market for sharing beyond the confines of the users that use them.  Many of the DWP and HMRC systems, for example, are so bespoke and self-serving (in a non-pejorative sense) that they can’t be “cloudified”.  No one else would want to use them.

But so much of the stuff that government does on a day-to-day basis is consistent from one organisation to the next.  Email, collaboration, call centre screens, contact and content management systems, Office-esque applications, financial and HR systems.  They’re all used consistently from one organisation to the next.  And as such, they can be shared—or put in the cloud.

Whether this is a cloud built specifically for government or one that also serves individuals and the private sector will depend on the case.  Horses for courses.  But let us be clear: the former *must* play its part.  Otherwise, we’ve missed the point.

It’s also important that cloud should not be confined to the world of computing.  In these austere times, sharing, or cloud, should become the modus operandi.  There should be cloud offices that can be used by people from numerous government departments; cloud call centres; cloud procurement vehicles; cloud subject-matter experts (people that can be called upon by multiple departments).

G-Cloud vs. cloud

The fundamental question that needs to be asked in government embracing cloud computing is this: does the private sector offer something off the shelf that the government can use? Currently, it doesn’t seem to be a question being asked.

There is absolutely no point in government creating cloud-based infrastructure—either itself or through third parties—to replicate an existing private-sector offering that government can instead use. The only feasible argument for doing this would be if the private sector offering was so inordinately expensive to suggest that a government-built equivalent would be cheaper. Trust me: it won’t be.

But the word “can” above covers a multitude of sins. The offering must be sufficiently robust and scalable to support the needs. And, importantly, its security arrangements must be in line with the needs of its prospective customers. Security will be the biggest factor driving cloud strategy—or else the biggest excuse cited in ensuring that government fails in this area.

The trouble is, government often has an elevated view of its security needs. That may sound odd, given the stories we’ve all heard about people’s confidential data going missing. But hear me out. Currently, we have the Government Secure Intranet (GSi), which is accredited up to RESTRICTED and facilitates work within and between government bodies. The vast majority of infrastructure that hums away within GSi-accredited departments sits within the GSi, and as such it is accredited up to RESTRICTED. But in most departments, only a small proportion of the work it undertakes needs to be accredited up to this level. Yet the departments see the GSi accreditation as a comfort blanket, irrespective of the sensitivity of the content in which they deal.

Naturally, the comfort blanket comes with a significant price tag.

Departments need to take a strategic look at what they do, the extent to which the data with which they deal is (or should be) protectively marked, and the level of that protective marking. And they need to figure out ways in which they can align their requirements to lower protective markings to facilitate the adoption of cloud services. If, for example, less than 1% of a department’s email traffic carries a protective marking, this should drive the department to adopt a client-side encryption plug-in for such emails—as opposed to forcing their entire email infrastructure to be accredited to that level.

What government will quickly realise is that the majority of the commodity services—email, collaboration, room bookings, content management/delivery etc.—are already provided in the cloud and can be embraced tomorrow. This will leave the support of the more bespoke and/or secure applications to be solved by the G-Cloud.

Giving it 102.7%

Back in early October, one of my most loyal clients emailed me to confirm that they needed us to work on a proofreading assignment in mid-November.  It was to be quite a biggie—an estimated 100,000 words.

Although the timescales were to be tight, I was confident that between myself and my associate Steve, we could cope with the workload.

The deliverables arrived later than expected.  And the word count was 66% higher than expected.  Not the best combination of factors.

But deliver we did.  Last week was a long week.  For me, five solid days of other work together with six solid evenings of proofreading.  I enlisted the services of Paul to pick up the surplus word count that we simply couldn’t deal with.  And between the three of us, we rocked it.

It was no mean feat.  Twenty-one documents averaging 7,750 words apiece.  Together, they’d make up a document about 325 pages in length.  But we didn’t have to read it—we had to proofread it.  The two are very, very different.  Proofreading is a necessarily slow business.  Rush it and you’ll miss stuff, no question.

All in all, we made 24,661 changes—an average of one change every six or seven words.  And when I submitted the last deliverable at 2130 last night, the client emailed back within five minutes with a final, 22nd document weighing in at 4,459 words (an extra 2.7%) to add to the pile.  Naturally, I obliged.

So three proofreaders polished off 170,471 words in a week, making 24,661 changes between us.  I’m proud of my colleagues and equally proud of the work we delivered.

The fabulous NHS—and my fabulous Dad

At 0725 on Thursday 26 August, my Mum called.  My Dad had been admitted to hospital the previous evening after complaining of  a tight chest to his doctor.  This after a heart attack in 2000, and two bouts of angioplasty in 2002 and 2005, if memory serves me.  This time, the doctor allowed him to go home to pick up some essentials before being admitted to Calderdale Royal Hospital that evening.  He was to await a bypass operation at Leeds General Infirmary.

He was waiting for some time.  First of all, the guy best placed to interpret the scans was away at a conference in Scandinavia.  By the time he got back, the surgeon that was lined up, Dr Ramanpillai Nair, was ready to set off on his holidays.  Each excuse understandable; each equally frustrating.

On 20 September, he was transferred to Leeds.  And at around 0800 on the morning of 22 September, he went under the knife for a triple bypass, in the hope that Dr. Nair was fully refreshed from his holiday.

I saw him the following day.  I couldn’t hug him because he was hooked up to all sorts of drugs, drips, drains and the like.  The upward handshake wasn’t enough for me, but it would have to do.  He was weak and groggy, but considering what he’d been through, he was in good form.  He was sitting up in a chair for God’s sake, not 24 hours after the five-hour operation during which his heart had been stopped.

The following Wednesday, he was released from hospital to stay with his sister for a week—I am extremely grateful to her for putting him up, and indeed putting up with him, during that time.  And the following Wednesday, he went home to carry on with his life, subject to certain constraints imposed by Dr. Nair.  (His not being allowed to drive was the most frustrating, by all accounts.)

On 8 November, Dr. Nair signed him off.  No conditions, no stipulations.  Just an order to carry on where he left off 74 days earlier.

All of this was done through the National Health Service, to whom I am eternally indebted.  His care at Calderdale Royal seemed to be good.  And his care during the critical time at Leeds General was exemplary.  I forget the name of the nurse who was on duty when I saw him the day after his op.  But she was fabulous—caring, professional, joking, diligent.  And although I never met him, Dr. Nair himself seems like he rocked a proverbial phat one on 22 September.

The National Health Service is a truly fabulous organisation.  My Dad is one of the most loving, caring and giving people I’ve ever known—bias notwithstanding.  And the NHS has kept him going.  For that, I am thankful more than you can imagine.

I love you, Dad. x

I don’t get my shoes re-heeled at Tesco

Back in the late 1990s and early 2000s, government made an active move to outsource its IT.  Huge requirements matrices were drawn up and each department invited the market to bid.  In the main, a single-source model was used, whereby a single supplier was accountable for the entirety of the IT estate, irrespective of whether they passed on the responsibility for delivery to a third party.  Suppliers lapped up the opportunity.

In the main, this model continues to this day.  Each Whitehall department can name their big IT provider.  And in the main, they’re still responsible for the entire suite of IT services.

But just as I don’t get my shoes re-heeled at Tesco, departments shouldn’t be buying their entire IT suite from a single provider.  The world of cloud has opened up significantly since the outsourcing heyday, and more and more services that might previously been provided by an outsourcing provider can now be offered off the shelf in a cloud environment.  There is little, if any, need for system integration, and all that’s required of the main outsource provider is a decent network connection and a relatively recent and standard browser.  (Unfortunately, neither of these requirements is a certainty.)  If Tesco told me that they’d stopped stocking South American wines, I’d take that part of my business elsewhere.  And I would be responsible for the service integration at my dining table.

Many service providers openly admit—or in some instances mistakenly admit—to certain technologies and platforms not being their area of expertise, their area of competence.  So instead of being forced into a using a substandard technology, or a bespoke offering where a generic one would suit just fine, go and buy one direct.

Government departments need to push the boundaries of their IT contracts, understand where their boundaries lie, and become much, much more comfortable in exploring these boundaries.  I’m not suggesting that things should become a free-for-all.  There needs to be control in investigating and venturing into the multi-supplier landscape—service management will need to be carefully managed.  (That’s not to say that an “over my dead body” from Service Management should not be seen as a challenge.)  But if there are tools out there that can do a better job or can do the same job but cheaper, then they should be evaluated and explored as a viable option.

All too often, contracts are waved as a reason for something not to be done.  And all too often, the conversation ends there.  Instead, rational thought should be used in prescribing solutions, after which point everyone involved—commercials included—should figure out how on earth they can make it happen.

Let’s push the boundaries and see where that takes us.