Why hacking and platforms are the future of NHS IT
Doctors and architects go white elephant hunting
Posted in Management, 16th April 2013 10:04 GMT
Free whitepaper – Hands on with Hyper-V 3.0 and virtual machine movement
Opinion Apart from those who have a commercial vested interest does anyone still believe in large top-down centrally architected IT solutions? Public sector IT in the UK is littered with expensive white elephants, and it sometimes seems as if the only beneficiaries are the large IT contractors, who can threaten significant job losses or other problems if the government fails to continue the cycle of dependency.
The National Programme for IT in the NHS (known as NPfIT) provides a notorious example of this. For readers of The Register, the story of gross cost escalation and repeated disappointment will be a familiar one. When the NHS set up the Programme in 2002, it was billed as the world's biggest civil IT programme, and was expected to cost £2.3bn over three years. It was largely dismantled in 2011, having cost over £12bn and delivered very little.
So is there an alternative to these large top-down solutions? Enter Dr Carl Reynolds, who is a hospital doctor and a self-styled geek. He organizes a series of one-day events called NHS HackDays, where hundreds of volunteers - including doctors, software developers and designers - work on disruptive digital health technologies.
Obviously there is a limit to what can be done in a day, but it is still possible to produce a wealth of interesting and useful apps to improve the NHS for patients and healthcare professionals. But clearly that's not enough; even the most generous pile of interesting and useful apps cannot possibly deliver everything the NHS needs. We can think of the software available to the NHS as if it were a fleet of ships. At one extreme, a slow and cumbersome supertanker. At the other extreme, a flotilla of tiny boats. But we need something in between.
Many experts believe the answer lies in the platform approach, which if properly designed and maintained would combine the benefits of diversity and interoperability. Some extremely successful platforms have emerged in recent years, notably Amazon and Apple, but the general approach is not just limited to glamorous high-tech end-consumer products and services.
There are three key characteristics of a platform.
- The platform provides a way for customers to access the specific capabilities and resources they need, and to link them together.
- The platform provides a way for third-party suppliers to offer additional specialized capabilities and resources.
- The platform makes capabilities and resources available to third parties. These are typically common or general purpose capabilities, which may be offered as utility services.
A platform approach was proposed by some smaller IT suppliers, but according to a submission to the House of Commons Public Accounts Committee, the approach was rejected as high risk and too cheap to be credible, despite claiming successful results in Canada and elsewhere. Clearly the large contractors are good at persuading government that any given solution must be sufficiently large that only the large contractors can deliver it.
Elsewhere, the success of companies like Amazon and Apple has come from understanding how platforms work. Back in 2005, some experts predicted that Steve Jobs was too much of a perfectionist to fully embrace the platform approach. They were wrong – he turned himself into a master of platform.
In this emerging world, the job of the architect is not to plan and control everything top-down, but to make the platform work, and to manage the ecosystem so that there is a good mix of small, medium and larger applications, and a good balance between differentiation and integration.
The idea that a healthy system architecture requires a range of different size systems (scales) comes from the architect Christopher Alexander, who has had a wide-ranging influence over IT architecture over many decades including his work on structured methods and patterns. According to Alexander and his colleagues, including the mathematician Nikos Salingaros, we need to allow things of different sizes to coexist and interrelate: this can be thought of as a "fractal" approach.
Salingaros has introduced the concept of "fractal loading" which means that a given exchange may be simultaneously meaningful at different levels. He argues that a system that cannot respond to change on any one of its multiple levels, is inherently unstable.
So for example, a single exchange between a doctor and a patient forms part of a longer process involving that patient with other health professionals, and also part of longer processes such as commissioning. The core task of the architect is to build patterns and frameworks that guarantee the interoperability of these different processes at different scales.
The architect is also managing different development tempos. There are large legacy systems and packages, developed many years ago, where even relatively small enhancements may take months (and large sums of money) to carry out, alongside tiny apps that might be developed over a weekend. So an intermediate development tempo is needed, sometimes called the Alignment Tempo, for aligning the fast-moving with the slow-moving, and allowing agile development and innovation to proceed apace without waiting for the slowest-moving subsystems. A good architecture framework is essential. Healthcare system provider Maracis has used the same framework for six years, with which it claims to be able to deliver small application increments extremely rapidly. A similar approach was adopted by the Canadian Health Service, which achieved better results than the NP4IT for a fraction of the cost.
Thus Alexander's architectural approach to large complex requirements, provides a promising alternative to the traditional one-size-fits-all top-down approach, which has cost so much and delivered so little, and gives architects a new way of working intelligently with agile developers and users to deliver real value.
This article is a shortened extract from Richard Veryard's new book on Next Practice Enterprise Architecture, published by LeanPub. He will be presenting and running workshops at the IASA Conference in London, April 22-26. The next NHS Hackday will be in London on May 25-26.
Free whitepaper – Hands on with Hyper-V 3.0 and virtual machine movement
COMMENTS
Do it in house
The NHS is one of the largest employers in the world. It could easily employ a relatively large number of developers and write pretty much all of the software in needs in-house. They would never be idle as there's a huge amount that always needs writing.
I'm a hospital governor, and I've worked within the private sector on a large number of NHS projects and proposals. The amount of money scammed out of the NHS by large SIs is sickening. The tendering process takes a huge amount of time and effort on everyone's part, and the cost to the UK economy as a whole must be huge. What's more, once the project is delivered the NHS doesn't have that institutional knowledge and the suppliers have them over a barrel for support. At the moment, if a clinician finds a problem with software then it's bad luck if the spec wasn't quite right - the supplier might change it for a huge fee. Maybe.
Think of the money saved not having to put everything out to tender, but having a large permanent staff on hand to develop anything that needs doing. What's more, the knowledge wouldn't be lost every three years and there would be people around to work on problems in any system.
Of course, this would never happen under a government that is in thrall to the 'free market'. This is sad, since the fact that it would be cheaper, quicker and more efficient is without doubt.
high risk and too cheap to be credible,
Translation.
At that cost you wont be able to take any of us out to the Opera, Wimbledon final, British Grand Prix. (Delete as Appropriate)
Two options.
1. Get some people who know what they are doing . Pay them to do it. Come back when it's done.
2. Choose the people in charge at random and change them at irregular intervals. Get big players in a similar industry to tell them what them want. Throw in disruptive political party expediencies for good measure.
Method 1 has a patchy track record. Has had some notable successes. Has little career enhancing pay back for the politicos of the day.
Method 2 has consistently and spectacularly failed. Gives politicians regular opportunities for claiming money saving 'new initiatives' and 'it was all the other guys fault.
Which would you choose? That's why you are not currently on an all-expenses-you-can-get-away-with all-power-no-responsibility gravy-train and have to work for your money instead.
Hands firmly down here
Well, quite. I've got quite a lot of NPfIT scars on my CV, having started work on it back in 2004.
The most astounding part about the National Programme was the enforced adoption of vapourware and flaky customised American software across the board. That's not a swipe at the US by the way, but the healthcare sector in the UK is very different from that across the pond.
What they should have done was to mandate the use of HL7 as an interoperability standard and allocate the budget to individual NHS trusts to implement it as they saw fit. That would have given them the option to buy new software or develop a dedicated integration facility and amend their existing systems to communicate with it.
That's how the electricity market deregulation worked. A central set of interoperability standards was produced and each 'leccy company put their own solution in. A popular choice involved a dedicated integration hub that sent and received all messages across the national network and handled all the internal distribution, including reformatting messages for communicating with mainframes. What the companies did behind those hubs was up to them.
Some companies bought new software, while others amended their existing systems to handle the new messages. By and large, it worked pretty well. The scale of the cock-ups - and there were a few - pale into insignificance when compared with NPfIT.
So yep, NPfIT failed to make proper use of all that HL7 had to offer. I've often thought that if they had done it properly, they might have encountered less resistance from the clinicians. BUt you know how it goes - in the users vs consultants war, the users lose.
Re: high risk and too cheap to be credible,
Indeed. And less chance of a directorship when you decide to cash in your 'public service' chips.
The new Office Garage series:
