Government as a Platform

The UK government, under the auspices of Francis Maude and his Cabinet Office colleagues, have instigated a fundamental rethink of how government does IT following the arrival of the coalition in May 2010. You can find a brief summary here of what has happened since then (and why).

One of the approaches that the Cabinet Office favours is the idea of services built on a shared core, otherwise known as Government as a Platform (GaaP). In the governments own words:

A platform provides essential technology infrastructure, including core applications that demonstrate the potential of the platform. Other organisations and developers can use the platform to innovate and build upon. The core platform provider enforces “rules of the road” (such as the open technical standards and processes to be used) to ensure consistency, and that applications based on the platform will work well together.

The UK government sees the adoption of platform based services as a way of breaking down the silos that have existed in governments, pretty GaaPmuch since the dawn of computing, as well as loosening the stranglehold it thinks the large IT vendors have on its IT departments. This is a picture from the Government Digital Service (GDS), part of the Cabinet Office, that shows how providing a platform layer, above the existing legacy (and siloed) applications, can help move towards GaaP.

In a paper on GaaP, Tim O’Reilly sets out a number of lessons learnt from previous (successful) platforms which are worth summarising here:

  1. Platforms must be built on open standards. Open standards foster innovation as they let anyone play more easily on the platform. “When the barriers to entry to a market are low, entrepreneurs are free to invent the future. When barriers are high, innovation moves elsewhere.”
  2. Don’t abuse your power as the provider of the platform. Platform providers must not abuse their privileged position or market power otherwise the platform will decline (usually because the platform provider has begun to compete with its developer ecosystem).
  3. Build a simple system and let it evolve. As John Gall wrote: “A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true. A complex system designed from scratch never works and cannot be made to work. You have to start over beginning with a working simple system.”
  4. Design for participation. Participatory systems are often remarkably simple—they have to be, or they just don’t work. But when a system is designed from the ground up to consist of components developed by independent developers (in a government context, read countries, federal agencies, states, cities, private sector entities), magic happens.
  5. Learn from your hackers. Developers may use APIs in unexpected ways. This is a good thing. If you see signs of uses that you didn’t consider, respond quickly, adapting the APIs to those new uses rather than trying to block them.
  6. Harness implicit participation. On platforms like Facebook and Twitter people give away their information for free (or more precisely to use those platforms for free). They are implicitly involved therefore in the development (and funding) of those platforms. Mining and linking datasets is where the real value of platforms can be obtained. Governments should provide open government data to enable innovative private sector participants to improve their products and services.
  7. Lower the barriers to experimentation. Platforms must be designed from the outset not as a fixed set of specifications, but as being open-ended  to allow for extensibility and revision by the marketplace. Platform thinking is an antidote to the complete specifications that currently dominate the government approach not only to IT but to programs of all kinds.
  8. Lead by example. A great platform provider does things that are ahead of the curve and that take time for the market to catch up to. It’s essential to prime the pump by showing what can be done.

In IBM, and elsewhere, we have been talking for a while about so called disruptive business platforms (DBP). A DBP has four actors associated with it:

  • Provider – Develops and provides the core platform. Providers need to ensure the platform exposes interfaces (that Complementors can use) and also ensure standards are defined that allow the platform to grow in a controlled way.
  • Complementor – Supplement the platform with new features, services and products that increase the value of the platform to End Users (and draw more of them in to use the platform).
  • End User – As well as performing the obvious ‘using the platform’ role End Users will also drive demand that  Complementors help fulfill. Also there are likely to be more Users if there are more Complementors providing new features. A well architected platform also allows End Users to interact with each other.
  • Supplier – Usually enters into a contract with the core platform provider to provide a known product or service or technology. Probably not innovating in the same way as the complementor would.
Walled Garden at Chartwell - Winston Churchill's Home
Walled Garden at Chartwell – Winston Churchill’s Home

We can see platform architectures as being the the ideal balance between the two political extremes of those who want to see a fully stripped back government that privatises all of its services and those who want central government to provide and manage all of these services. Platforms, if managed properly, provide the ideal ‘walled garden’ approach which is often attributed to the Apple iTunes and App Store way of doing business. Apple did not build all of the apps out their on the App Store. Instead they provided the platform on which others could provide the apps and create a diverse and thriving “app economy”.

It’s early days to see if this could work in a government context. What’s key is applying some of the above principles suggested by Tim O’Reilly to enforce the rules that others must comply with. There also of course needs to be the right business models in place that encourage people to invest in the platform in the first place and that allow new start ups to grow and thrive.

What Have Architects Ever Done for Us?

I’ve been thinking about blogging on the topic of what value architects bring to the table in an age of open source software, commoditized hardware and agile development for a while. I’ve finally been spurred into action by re-discovering the famous Monty Python sketch What have the Romans ever done for us? (I often find that thinking of a name for a blog post helps me to formulate the content and structure what I want to say). Here’s the video in case you haven’t seen it.

So, picture the scene…

You are in a meeting with the chief information office (CIO) of a public or private sector enterprise who has been tasked with aligning IT with the new business strategy to “deliver real business value”. The current hot technologies, namely social media, mobile, big data/analytics and cloud, are all being mooted as the thing the organisation needs to enable it to leapfrog the competition and deliver something new and innovative to its customers. The CIO however has been burnt before by an architecture team that seems to spend most of its time discussing new technology, drawing fine looking pictures that adorn their cubicle walls and attending conferences sponsored by vendors. She struggles to see the value these people bring and asks in a frustrated tone “what have architects ever done for us”? What’s your response? Here’s what I think architects should be doing to support the CIO and help her achieve the enterprise’s goals.

  1. Architects bring order from chaos. The world of IT continues to get ever more challenging. Each new architectural paradigm adds more layers of complexity onto an organisations already overstretched IT infrastructure. As more technologies get thrown into this mix, often to solve immediate and pressing business problems but without being a part of any overall strategic vision, IT systems begin to sink into more and more of a chaotic state. One of the roles of an architect is not only to attempt to prevent this happening in the first place (see number 2) but also to describe a future “to-be” state, together with a road map for how to get to this new world. Some will say that this form of enterprise level architecting is fundamentally flawed however I would argue it still has great value provided it is done at the right level of abstraction (not everything is enterprise level) and recognises change will be continuous and true nirvana will never be achieved.
  2. Architects don’t jump on the latest trend and forget what went before. When a new technology comes along it’s sometimes easy to forget that it’s just a new technology. Whilst the impact on end users may be different, the way enterprises go about integrating that technology into their business, still needs to follow tried and tested methods. Remember, don’t throw out the baby with the bath water.
  3. Architects focus on business value rather than latest technology. Technologies come and go, some change the world, some don’t. Unless technology can provide some tangible benefits to the way a business operates it is unlikely to gain a foothold. Architects know that identifying the business value of technology and realising that value through robust solutions built on the technology is what is key. Technology for the sake of technology no longer works (and probably never did).
  4. Architects know how to apply technology to bring innovation.This is subtlety different from 3. This is about not just using technology to provide incremental improvements in the way a business operates but in using technology to provide disruptive innovation that causes a major shift in the way a business operates. Such disruptions often cause some businesses to disappear but at the same time can cause others to be created.
  5. Architects know the importance of “shipping”. According to Steve Jobs “real artists ship”. Delivering something (anything) on time and within budget is one of the great challenges of software development. Time or money (or both) usually run out before anything is delivered.Good architects know the importance of working within the constraints of time and money and work with project managers to ensure shipping takes place on time and within budget.

So there you have it, my take on the value of architects and what you hopefully do for your organisation or clients. Now, if only we could do something about bringing world peace…

Architecting Disruptive Technology Platforms

Bob Metcalfe, the founder of 3Com and co-inventor of  Ethernet has said:

Be prepared to learn how the growth of exponential and disruptive technologies will impact your industry, your company, your career and your life.

The term disruptive technology has been widely used as a synonym of disruptive innovation, but the latter is now preferred, because market disruption has been found to be a function usually not of technology itself but rather of its changing application.Wikepedia defines a disruptive innovation (first coined by Clayton Christensen) as:

An innovation that helps create a new market and value network, and eventually goes on to disrupt an existing market and value network (over a few years or decades), displacing an earlier technology.

Examples of disruptive innovations (and what they have disrupted/displaced) are:

  • Digital media (CDs/DVDs)
  • Desktop publishing (traditional publishing)
  • Digital photography (chemical/film photography)
  • LCD televisions (CRT televisions)
  • Wikipedia (traditional encyclopedias)
  • Tablet computers (personal computers, maybe)

The above are all examples of technologies/innovations that have disrupted existing business models, or even whole industries. However there is another class or type of disruptive innovation which not only disrupts a market but creates a whole new ecosystem upon which a new industry can be created. Examples of these are the likes of Facebook, Twitter and iTunes. What these have provided, as well, are a platform upon which providers, complementors, users and suppliers co-exist to support, nurture and grow the ecosystem of the platform and create a disruptive technology platform (DTP). Here’s a system context diagram for such a platform.

The four actors in this system context play the following roles:

  • Provider – Develops and provides the core platform. Providers need to ensure the platform exposes interfaces (that Complementors can use) and also ensure standards are defined that allow the platform to grow in a controlled way.
  • Complementor – Supplement the platform with new features, services and products that increase the value of the platform to End Users (and draw mor of them in to use the platform).
  • End User – As well as performing the obvious ‘using the platform’ role Users will also drive demand that  Complementors help fulfill. Also there are likely to be more Users if there are more Complementors providing new features. A well architected platform also allows End Users to interact with each other.
  • Supplier – Usually enters into a contract with the core platform provider to provide a known product or service or technology. Probably not innovating in the same way as the complementor would.

If we use Facebook (the platform) as a real instance of the above then the provider is Facebook (the company) who have created a platform that is extensible through a well defined set of interfaces. Complementors are the many third party providers who have developed new features to extend the underlying platform (e.g. Airbnb and The Guardian). End uers are, of course, the 800 million or so people who have Facebook accounts. Suppliers would be the companies who, for example, provide the hardware and software infrastructure upon which Facebook runs.

Of course, just because you are providing a new technology platform does not mean it will automatically be a disruptive technology platform. Looking at some of the technology platforms that are currently out there and have, or are in the process of disrupting businesses or whole industries we can see some common themes however. Here are some of these (in no particular order of priority):

  • A DTP has a well defined set of open interfaces which complementors can use, possibly in ways not originally envisaged by the platform provider.
  • The DTP needs to build up a critical mass of both end users and complementors, each of which feeds off the other in a positive feedback loop so the platform grows.
  • The DTP must be both scaleable but extremely robust.
  • The DTP must provide an intrinsic value which cannot be obtained elsewhere, or if it can, must give additional benefits which make users come to the DTP rather than go elsewhere. Providing music on iTunes at a low enough cost and easy enough to obtain preventing users going to free file sharing sites is an example.
  • End users must be allowed to interact amongst themselves, again in ways that may not have been originally envisaged.
  • Complementors must be provided with the right level of contract that allows them to innovate, but without actually breaking the platform (Apple’s contract to App store developers is an example). The DTP provider needs to retain some level of control.

These are just some of the attributes I would expect a DTP to have, there must be more. Feel free to comment and provide some observations on what you think constitutes a DTP.