Learning from the “worst fiasco ever”

_69899119_recordsI’m not surprised to see a story today citing the failed NHS electronic patient record system as one of the worst fiascos ever and a £10bn write-off.

A few years ago I had the pleasure and pain to work on an NHS IT project. It was a pleasure to be working on a project that had the potential to have a real positive impact on the lives of millions of people.  The pain was enduring the endless overbearing bureaucracy and complexity forced on us by the NHS.

My team wanted to pull some data from the electronic patient record to assist GPs during prescribing.  We just wanted a few simple pieces of demographic data, such as age, gender and so on. Having looked at the specs we estimated it would take 2-3 months of effort to develop that capability.  The complexity of the design was astounding.

What’s wrong with government IT?

In an attempt to get good value for money for taxpayers, politicians and civil servants push for ever-bigger projects with the aim of removing duplication of effort across many different projects. After all, you don’t want lots of different projects all solving the same problem in different ways, right?

On the face of it, the argument makes sense. But here’s what happens in the real world:

  • Projects with similar goals but competing requirements are merged together
  • Because it’s hard or impossible to get small projects signed-off (remember, you don’t want to duplicate effort!) scope creep ensues
  • A huge amount of effort is spent figuring out how to fit all the requirements into a single deliverable
  • Projects become bloated and impossibly complex
  • And so… projects fail

      An alternative approach

      What if the government took a leaf from the start-up world where entrepreneurs set out to solve a problem in the simplest way possible and deliver quickly so they can gauge success. Because solutions are built around a common set of open standards the various online services all inter-operate.

      Perhaps instead of trying to build a single IT system to conquer them all, government should instead focus on the results they want, and a set of (simple!) common data formats, then leave the private sector to get on with developing elegant solutions to common problems that can move healthcare forward more quickly.

    2012 meet 2002… I think you’ll like each other

    imageI read today that Facebook is criticising Apple and Google for failing to adopt HTML 5 quickly enough on iOS and Android. I guess Apple and Google know which side their bread is buttered. They both know that the key to having a successful platform is having great apps.

    Enabling developers to target all mobile OSs with a single code base is great for developers but terrible for platform owners. First off you lose any competitive advantage from having the best apps, and even more importantly in the mobile world, Apple and Google forfeit the 30% tax they charge on App Store / Google Play sales.

    Of course we have been here before. Back around 2002 Microsoft was using anti-competitive practices to kill off competing browsers with the aim of ensuring all the best apps remained only on the Windows platform. Ultimately that didn’t work of course. The regulators got involved and developers built for the browser and W3C standards anyway.

    Ultimately the same will happen on the mobile platforms I’m sure. Interesting now though is that the tables have been turned. Microsoft is the minnow with lots to gain by disrupting the established players. It’ll be fun watching this one play out.

    CubeSocial Selected for Seedcamp London

    Seedcamp logo

    We’ve just heard… CubeSocial is one of 20 tech start-ups selected for Seedcamp London! Smile The event takes place next Thursday 11 August.

    During the event, we get five minutes to showcase our business to a range of entrepreneurs, venture capitalists, lawyers, accountants and other experts, followed by an afternoon of expert mentoring and coaching.

    Becoming a Seedcamp London finalist is great recognition for everyone involved here at CubeSocial and follows on from last month’s listing as a Company to Watch in the Thames Valley 250. We hope the day itself brings us more good news.

    Wish us luck!

    Building for the Valley – Bootstrapping tips from Tweetmeme

    I posted this up on the CubeSocial blog yesterday, but thought readers here might be interested too…

    Nick HalsteadYesterday Linda and I were guests at an excellent Thames Valley Innovation and Growth (TVIG) event “Building for the Valley”.

    The session was delivered by Nick Halstead, CEO and founder of TweetMeme.

    As a TVIG-sponsored start-up ourselves, we were fascinated to hear the story of Tweetmeme’s growth from being one of the first TVIG start-ups “when it was just Nick and his heavily pregnant wife in a cupboard” (!!) to a globally known brand, with 15 staff, handling more web hits than the BBC.

    It was a story of rapid growth on a bootstrapping budget, and an inspiration for all budding entrepreneurs. Here are some of the takeaways:

    On Networking

    Don’t go to a networking event unless you can get a list of attendees beforehand. When you get the list, run it through LinkedIn and choose your ‘targets’ deliberately. Time is too valuable. Don’t leave networking to chance meetings. Have a maximum of one beer all evening: this is about business not partying.

    On Marketing and PR

    Become a reference point for your industry. Bootstrap your PR.

    When Nick started Tweetmeme he blogged every night, then nagged friends and other bloggers to read his posts: “we have never paid a PR agency”. Nick explained that it helps to have a consumer focussed element to your portfolio because these tend to get more press.

    Blogging means that you get to lead the conversation; the traffic you get translates into customers; you become a reference for news stories; and you get asked to speak at events.

    On Public Speaking

    Public speaking = free PR, but don’t be tempted you use it to advertise your product. Instead give useful information. (Don’t sell, educate). Build your reputation and integrity, and the (interested) attendees will become customers over time. A side benefit of public speaking is that you are more prepared and confident when you have to pitch to investors.

    On Recruitment

    Avoid recruitment agencies. Hire straight from university; only “bedroom coders”; pay them in options – “they must believe in the dream”.

    On Investment

    Getting investment has the biggest learning curve. It takes up 90% of your time. Keep the deal simple – complex terms tend to drive the wrong behaviours in leadership team: “with hindsight we would have given more away for simpler terms”.

    Choosing between SQL Azure and Windows Azure Storage

    I was having a chat with an Azure architect at Microsoft last week, and he pointed out that SQL Azure storage costs 66x (yes, sixty-six times) Table Storage.

    Not quite believing I went back to check pricing. And sure enough it’s true. In fact it is probably an even higher ratio as you have to buy SQL Azure in chunks of 1,5,10,20 GB etc.

    If you have 15Gb of data in SQL Azure you need a 20Gb database @ ~$200/month.

    15 Gb of data in Table Storage = 15 * $0.15 = $2.25 / month.

    That would make SQL Azure around 89x as expensive as Table Storage.


    That’s not quite the full story though. In Table Storage the idea is that you would often not normalise your data. Data is likely to be stored multiple times in the store. And additionally there are transactional costs associated with Table Storage ($0.01 per 10,000) transactions.  These both make estimating cost more tricky.

    As a guestimate starting point, let’s say I need to store each data item 3 times in Table Storage, meaning that 15Gb of normalised data gives me a requirement of 45Gb Table Storage. If my system has 1000 users each performing 10,000 transactions / month, then my total Table Storage costs would be:

    (45 * $0.15) + (1000 * $0.01) = $16.75 / month

    That’s about a 12x ratio (and is based on a lot of assumption too).

    There’s probably a need for a simple spreadsheet to help look at the trade-offs here, but as a rule of thumb the pricing model from Microsoft is giving us some strong guidance: Windows Azure architects should look to put data in Windows Azure Storage first and SQL Azure conservatively.

    The two scenarios I see when I would prefer SQL Azure over Table Storage are:

    • When I need SQL Transactions – ie. the ability to group together a bunch of database actions and commit them as a single atomic unit. There’s no concept of this type of transaction in Table Storage.
    • When I need reporting – especially enabling end-users to design their own queries and reports. In this case I don’t know how the user will want to query the data at design time and will need to rely on SQL Servers ability to query across tables to enable this.

    How Cloud Computing Changes the Economics of Software Architecture

    I’ve been thinking a lot about architecting software applications for the cloud lately – particularly for Windows Azure, as that’s the platform we have chosen to build CubeSocial’s SaaS solution on.

    Lots has been written about the impact of PaaS and IaaS services like Amazon Web Services and Windows Azure on software architecture.  I’ve seen plenty of commentary arguing that architects need to change the way they design systems to consider the platform billing model and on-going costs.

    But is that really a change? In my opinion, it’s no different to what we architects have always done – only in the past the cost considerations were different. It was about numbers of servers, software licences, software versions etc.

    I believe the cloud computing model changes our approach in a much more fundamental way.

    I see the shift that is happening right now as the modern equivalent of what happened when Windows went from 16-bit to 32-bit.

    Freed from the memory limitations of 16-bit computing we all stopped optimizing our Windows code, as there were simply so many system resources available to play with… it was effectively limitless.

    Cloud computing platforms bring the same philosophical shift to web applications.

    Yes, I could spend time architecting for the billing model. I could spend money getting programmers to performance tune their code to reduce billing charges. But that doesn’t mean I should.

    Let me ask you this: Why spend 50$ an hour on getting a programmer to tune their code, when instead I can pay Microsoft or Amazon another $50 a month and throw another web front end at the problem. Then, instead I can have my developers doing something much more useful to the business: adding new product features more quickly than the competition so that I can sell more and make more revenue.

    And that is the true economics of cloud computing.