Monthly Archives: February 2014

An Open Letter to Software Suppliers – 13 Ways to Help the Public Sector to the Cloud

Dear Software Supplier,
The public sector is hemorrhaging money. Money
We all use the same systems, but instead of joining up and sharing we are each deploying identical solutions in isolation.
This is costing us a fortune at a time when (by the way) money’s too tight to mention.
A first step to joining things up is to get all this software out of our data centres and in to the cloud.
We’re trying to get to the cloud – we really are – but you’re not making it easy for us. Here are 13 steps you can take to facilitate our journey to the cloud whilst simultaneously making yourselves some money.
1. Be Cloud Ready
This may seem odd coming from a Head of ICT – but we don’t want to have our own IT departments.
We don’t want any tin on-premise. The public sector should not be in the IT business. An analogy – we consume electricity but we don’t run our own power station. We consume data – but we don’t want to run our own data centre – we want Software as a Service (SaaS).
At my local authority we’ve had a ‘cloud first’ policy since 2007. Every time we buy an application or renew a contract we try to get the vendor to host it for us. This is harder to do than you might think.
More often than not the question “Will you host it for us?” is greeted by the exchange of bemused/panicky looks between the vendor’s sales folk.
“Um, we could install some servers in your data centre and then look after it remotely?” Noooooooooo!
Vendors need to understand that, within a year or two, if you can’t deliver your application as SaaS then we are not buying it.
Vendors should be cloud ready – wshouldn’t have to start from scratch every time. I want you to spin up my instance of your application at the touch of a button. So you’ll need to…
servers
2. Invest Upfront in the Platform
You need to have your infrastructure built and ready to go before you enter pre-sales.
Regardless of whether the servers are in your own data centre or Rackspace’s – they should be humming away before we sign the contract.
The tin is not the customer’s problem.
3. Avoid Short-termism (understand our business case)
There are many reasons why cloud/SaaS is attractive to the public sector – perhaps the foremost being that SaaS should be cheaper than on-premise. I say ‘should’ because it usually isn’t.
We tried to move 2 of our largest, mission critical, systems to the cloud last year. These systems are sold by 2 of the largest software houses in the world. In each case the total cost of ownership over 5 years was TWICE as high under a cloud/SaaS model when compared with traditional on-premise hosting. So we bought the tin, put it in our data centre and it’ll now be at least 5 years before we have an opportunity to look again at the cloud for these systems. Frustrating.
The reason that these two vendors were unable to make their SaaS offering compete with on-premise is that they did not take the long view.

nepho

As with most services, the bulk of the cost of any IT department is in salaries. In theory IT departments should be able to reduce headcount as a direct result of moving systems in to the cloud. This, of course, is why many IT teams have nephophobia (fear of clouds). IT departments think clouds are evil. 
The problem is, though, we can’t reduce headcount as a result of just a couple of systems going SaaS. If we put some of our databases in the cloud we’re still going to need DBAs because we still have lots of databases. This is a major challenge to the SaaS business case.
What the vendors need to do is reduce profit margins for these early SaaS forays. By taking a hit now they will be paving the way for organisations to put more of their systems in the vendor’s cloud. You need to be at least matching, if not beating, the on-premise cost – otherwise, why would we do it?
Short-term pain for long-term gain.
4. Be Secure
It seems that there are a surprising number of software companies who don’t know much about IT security, PSN controls or the Data Protection Act (DPA).
You need to be PSN experts. You must understand this stuff inside out.
Golden Gate BridgeThe UK DPA states that our data must be stored within Europe. IF YOUR SERVERS ARE IN CALIFORNIA THEN WE CAN’T DO BUSINESS. 
We spend an inordinate amount of time verifying that the vendor’s cloud is secure – endless surveys and toing and froing – sometimes we even have to visit the vendor’s data centre. On one occasion we found that a very large supplier intended to host our sensitive, precious, data in a crumbling Victorian warehouse by a river. No thanks.
You need to get together with other vendors and with Cabinet Office and come up with an accreditation scheme. Some kind of SaaS ‘kite mark’. All we want to have to do, as the customer, is ask to see a copy of your certificate and be comforted that you know what you’re doing.
5. Build in Disaster Recover as Standard
One of the big attractions of the cloud is that it is immune to localised emergencies. Yet it is surprisingly common to find SaaS offerings that don’t include back-up to a second location as standard.
We shouldn’t have to ask whether you back-up our data to a geographically distant location – and we certainly don’t want it included as an optional (chargeable) extra. It should go without saying that you’ve thought about disaster recovery and this would be a condition of getting your SaaS ‘kite mark’.
 

6. Make Updates/Patches/Releases Opaque to the Customer

When Google adds a new feature to Gmail, or whatever, they do it without any fuss. We generally don’t know that an upgrade has happened until after the fact.

The same should be true of SaaS releases. This work needs to happen behind the scenes without the need for any downtime.
Similarly, improvements and innovations that you’ve developed for one customer should be quickly shared with all your customers (at no extra cost).

gcloud

7. Get on a Framework
Make your product easy to procure by getting yourselves on a framework such as G-Cloud. Public Sector procurement rules are hugely restrictive and prescriptive – so a product that is easy to procure is very attractive to us.
8. Think About Our Capex vs Opex Problem
Many public sector ICT projects are funded using capital monies – often from prudential borrowing.
We can only spend capital money if we can demonstrate that the investment leads directly to the creation of an asset (tangible or intangible). This is fine for a traditional on-premise delivery model because it’s easy to demonstrate that a tangible asset has been created.
But we can’t use capital money to fund the creation of a SaaS solution because there is no asset being created. At the end of the contract there is nothing that the public sector organisation ‘owns’. Sometimes this isn’t a problem as some organisations will find it easier to lay their hands on revenue (opex) monies, but sometimes it can be a deal breaker.
You can help us here by thinking of ways in which the Saas deal can lead to the creation of an asset that the customer owns. Could you, perhaps, nominate a piece of your cloud infrastructure as belonging to us, the customer, and write this in to the contract? In reality, should the relationship come to an end, we probably wouldn’t want to go to the trouble of availing ourselves of this clause – we don’t want the tin – but the clause’s existence may be enough to convince our accountants that this SaaS project is a genuine candidate for capital investment.
9. Make Short Contracts More Attractive
The days of 5 and 7 year contacts are over. New disruptive technologies mean that we need to be able to react faster than ever before. Look at the way the iPhone has changed the

bohrlandscape – we have contracts that are still running that were signed before anyone had ever heard of an ‘app’.

Predicting technology futures is harder than ever – we don’t know what we’ll need in 3 years time so we don’t want to sign 3 year contracts.

I appreciate that this is a commercial challenge – you’re losing a guaranteed revenue stream – but you need to find a way to make short contracts attractive to us.
10. Encourage Multi-Organisation Contracts
This is our responsibility as much as yours – but it’s important to construct contracts in such a way that other public sector organisations can get on board at a later date without going around the procurement rigmarole again.
When selling your wares you should encourage your customers to contact their partners/neighbours to see if they would like to be cited in the contract as part of a procurement consortium – they’ll thank you for it.
11. Be Device Independent
devices
Hopefully this goes without saying these days, but mobile is king, and whatever your SaaS product is for, it should work just as well on an iPad as it does on a laptop.
12. Be Open
Let us at our data! We’ve got big plans for big data so you need to build your cloud offering with openness in mind. We want APIs included as standard that allow us to easily extract data to work on elsewhere.
13. Allow for Online Ratings from Customers
I’ve never come across a SLA that, when push comes to shove, was fit for purpose. Most SLAs are carefully worded such that it’s very hard for them to be breached and that the criteria for triggering penalties is rarely met.

onlinerating

The purpose of contracts and SLAs is to drive a certain kind of behaviour – ie to increase quality, responsiveness and uptime. But a SLA is a crude tool for this. Much better is a system of open online reviews and ratings by your customers.
This is scary, I know – but your product will definitely get better when everyone is able to talk about it openly.

I appreciate that there’s a lot of pain involved in getting yourselves cloud-ready – but if you don’t do it soon some disruptive new SaaS player will come along and take your business. By the way, if you are that disruptive new player – please get in touch – we’ve got some money for you.

Yours sincerely,
The Public Sector

Digital = Automation (or how to keep your looms clog-free)

Pretty much every meeting I attend these days involves some discussion of ‘Digital by Default’ or ‘Channel Shift’.do-it-online

Often these meetings see me waxing lyrical about digital things and trying not to roll my eyes when someone says “But what about the people who are not online?” (someone ALWAYS says this – I’ve blogged on it here).

Recently, in one of these meetings, I had something of an epiphany. I was being challenged by a non-believer over digital’s business case when I realised that what I was failing to get across is simply this – doing things digitally means that a computer carries out tasks that would previously been done by a human. D’oh!

Digital = Automation

Pretty obvious huh? But once I’d stopped using the phrases digital by default and channel shift and started using ‘automation’ instead I found it much easier to get the message across. We automate processes to make them cheaper, faster and better.

4.1.2

Spot-welding robots on a car production line can get through many, many more cars per day than a human workforce – and they don’t need to sleep, it’s a 24/7 service.

Similarly, by automating a process and putting it online we make our services faster, better and cheaper (and 24/7). Why are online services cheaper? Largely because humans are expensive things to employ and online services don’t need as many humans.

As this graphic shows, an online transaction is MUCH cheaper for the council than a face-to-face equivalent (I believe that these figures are from some SOCITM research). channelshift

As well as helping me explain why digital is better, these thoughts of automation led to a further insight – the reason we’re finding it so hard to ‘do’ digital is that it is being resisted by our own employees. Let’s travel back in time 400 years or so to help me explain….

A ‘sabot’ was a type of wooden clog worn by poor people in 16th century Europe (bear with me, this does have something to do with digital).wooden-shoes

When automatic knitting machines and looms were invented the peasants feared for their jobs. The new looms could make better quality clothes and they could do it much faster than the old hand-looms.

In an effort to protect their jobs the disgruntled weavers threw their sabots in to the inner workings of the loom in order to smash the machinery. From this action we get the word ‘sabotage’. 

This is a lesson from history that we could do well to pay attention to today. Everyone apart from the saboteurs thought that the new weaving machines were a great innovation. The manufacturers could make more clothes and blankets, the consumers got better clothes at much reduced cost. The loom makers were prized for the technical prowess. Everyone was happy apart from the people who used to do things the old way.

turkeyNow, as then, the people who are most likely to block an innovation are the people whose livelihoods are threatened by it. Turkeys are unlikely to vote for Christmas.

It’s hard for a large public sector organisation to ‘do’ digital. But why should this be? Our customers want it – they prefer to do things online. The leaders of the organisation want digital – it saves them money and allows for headcount reduction through automation.

The only people who don’t view digital as self-evidently the right thing to do are the humans who will be displaced by the automation of these transactions.

There is a way to approach this problem that keeps everyone happy. It’s essential that we don’t attempt to hard-wire a link between digital/channel shift and financial savings. This seems counter-intuitive, I know, but if you start your digital transformation by saying “We’re going to channel shift and this will mean we can drop headcount by 10 people by the end of the year” you’re going to find that your looms fill up with clogs and the project is suddenly very much harder than you thought it was going to be. You can’t really ‘do’ digital to processes unless you take the process owners with you – hearts and minds.

Instead, the message should be “We’re going to do digital/channel shift because it will ease your paperworkloads and help you cope with recent headcount reductions – we know you’re buckling under the strain and this project will help with that. What’s more – our customers will get a better service.”

You back this up by not taking any departmental/service budgets to fund the digital projects. Instead you fund this transformation at the centre knowing that there is a self-evident invest-to-save business case. For a small investment you’ll reap big savings.

In a year’s time, when the project is up and running, the people on the ground can see that they now have much less work to do and you find that you can now accept all those voluntary severance applications that you had to turn down last year. Headcount shrinks – incrementally and without too much trauma.

In summary – don’t get hung up on trying to predict the savings you’ll make from digital. It’s impossible for you to accurately put a figure on what you’ll save and to try to do so will result in resistance from the process owners. Instead, be resolute in the belief that automation is self-evidently the right thing to do and know that, to paraphrase Field of Dreams..

If you build it, the savings will come.

FOD