In one of the early classics of software engineering, Systemantics, 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.”[14]
Again, the Internet is a case in point. In the 1980s, an international standards committee got together to define the future of computer networking. The Open Systems Interconnect (OSI) model was comprehensive and complete, and one of the industry pundits of the day wrote, in 1986:[15]
Over the long haul, most vendors are going to migrate from TCP/IP to support Layer 4, the transport layer of the OSI model. For the short term, however, TCP/IP provides organizations with enough functionality to protect their existing equipment investment and over the long term, TCP/IP promises to allow for easy migration to OSI.
Au contraire. It was the profoundly simple protocols of the Internet that grew richer and more complex, while the OSI protocol stack became relegated to the status of an academic reference model used to describe network architecture.
Meanwhile, over on the TCP/IP standardization side, there was this wonderful, naive, glorious statement by Jon Postel in RFC 761:[16] “TCP implementation should follow a general principle of robustness. Be conservative in what you do. Be liberal in what you accept from others.” It sounds like something out of the Bible, the Golden Rule as applied to computers. What a fabulous statement of philosophy! “We’re not going to specify all of the details of how you interoperate; we’re just going to say, ‘Please do it.’”
Twitter is another good example of a fundamentally simple system. Jack Dorsey’s original design sketch fit on a few lines of paper (see Figure 2-2). Much has grown from that sketch. There are now thousands of Twitter applications, precisely because the core Twitter service does so little. By thinking simple, Twitter allowed its users and an ecosystem of application developers to evolve new features and functionality. This is the essence of generativity.
Of course, in a government context when you say “build a simple system; let it evolve,” that sounds like a real challenge. But let’s remember that TCP/IP was a government-funded project. It can be done. The first step is getting a philosophy of simplicity into your work, understanding that designing foundations that others can build on is an important part of platform thinking. It’s about creating the starting point, something that others can reuse and extend.
Designing simple systems is one of the great challenges of Government 2.0. It means the end of grand, feature-filled programs, and their replacement by minimal services extensible by others.
This quest for simplicity is one of the drivers behind Federal CIO Vivek Kundra’s emphasis on Data.gov, a collection of APIs to government data. Kundra realizes that rather than having the government itself build out all of the websites and applications that use that data, providing application programming interfaces to the private sector will allow independent developers to come up with new uses for government data.
The rationale for Data.gov was laid out convincingly by David G. Robinson et al. in “Government Data and the Invisible Hand” (see Chapter 6 for an updated take on this), and the emphasis below is mine:[17]
In the current Presidential cycle, all three candidates have indicated that they think the federal government could make better use of the Internet…. But the situation to which these candidates are responding—the wide gap between the exciting uses of Internet technology by private parties, on the one hand, and the government’s lagging technical infrastructure on the other—is not new. The federal government has shown itself consistently unable to keep pace with the fast-evolving power of the Internet.
In order for public data to benefit from the same innovation and dynamism that characterize private parties’ use of the Internet, the federal government must reimagine its role as an information provider. Rather than struggling, as it currently does, to design sites that meet each end-user need, it should focus on creating a simple, reliable and publicly accessible infrastructure that “exposes” the underlying data. Private actors, either nonprofit or commercial, are better suited to deliver government information to citizens and can constantly create and reshape the tools individuals use to find and leverage public data. The best way to ensure that the government allows private parties to compete on equal terms in the provision of government data is to require that federal websites themselves use the same open systems for accessing the underlying data as they make available to the public at large.
Our approach follows the engineering principle of separating data from interaction, which is commonly used in constructing websites. Government must provide data, but we argue that websites that provide interactive access for the public can best be built by private parties. This approach is especially important given recent advances in interaction, which go far beyond merely offering data for viewing, to offer services such as advanced search, automated content analysis, cross-indexing with other data sources, and data visualization tools. These tools are promising but it is far from obvious how best to combine them to maximize the public value of government data. Given this uncertainty, the best policy is not to hope government will choose the one best way, but to rely on private parties with their vibrant marketplace of engineering ideas to discover what works.
Data.gov reflects another key Gov 2.0 and Web 2.0 principle, namely that data is at the heart of Internet applications. But even here, the goal is not just to provide greater access to government data, but to establish a simple framework that makes it possible for the nation—the citizens, not just the government—to create and share useful data.
[14] Systemantics: How Systems Work and Especially How They Fail, John Gall, Quadrangle, 1977.
[15] “TCP/IP: Stairway to OSI,” Robert A. Moskowitz, Computer Decisions, April 22, 1986.