From Open Government: Collaboration, Transparency, and Participation in Practice edited by Daniel Lathrop and Laurel Ruma, ISBN 978-0-596-80435-0. Copyright © 2010 O’Reilly Media, Inc. All rights reserved. Used with permission.
Looking back over the history of the United States, it is not just remarkable to see how 13 former colonies of the British Empire could come together to form what became the longest continuously functioning government in recorded history, but it is also incredible that such a durable government was set up as a republic. Until the United States, history records few examples of even moderately successful republics, and even those moderate successes were aided by factors external to the specific system of government employed. How, then, did the framers of the U.S. Constitution succeed in creating a republican-style government where so many had failed?
Simply put, by good design.
When looking back through the Constitution and the Federalist Papers, we can observe that the founders took many novel approaches in crafting the structure of the United States. Indeed, Alexander Hamilton went so far as to describe these approaches as based on the new “science of politics.”* The Constitution was the embodiment of this new science and served as a lightweight framework, providing enough prescription to ensure basic stability in the republic, but little more, so as to enable the government to adapt over time and thus ensure the longevity of that stability.
In many ways, the framers of the Constitution were like the software designers of today. Modern software design deals with the complexities of creating systems composed of innumerable components that must be stable, reliable, efficient, and adaptable over time. A language has emerged over the past several years to capture and describe both practices to follow and practices to avoid when designing software. These are known as patterns and antipatterns. This chapter will explore known software design patterns and antipatterns in context of the U.S. Constitution and will hopefully encourage further application of software design principles as a metaphor for describing and modeling the complex dynamics of government in the future.
The Articles of Confederation and the Stovepipe Antipattern
Software design patterns and antipatterns can be classified by the general type of problem they describe or solve. Patterns in a category known as enterprise architecture make a good place to begin exploring the connection between the worlds of government and software, as they tend to be concerned more with the management of overall systems than with lines of code. What follows is an exploration into how the Articles of Confederation, the first constitution of the United States, represents a classic example of an antipattern known as the enterprise stovepipe. From that comparison, we will explore strategies for overcoming an enterprise stovepipe and will then see how the Constitution is in fact a historical illustration of those strategies.
NOTE
An antipattern is much like a regular pattern in that it describes observable phenomena that tend to occur with some frequency. However, antipatterns go further to define specific types of patterns which generally yield negative outcomes. Put another way, an antipattern describes a pattern that should be stopped.
The First Constitution
Drafted during the early part of the American Revolution, the Articles of Confederation became the first constitution for the new confederacy of 13 states. Though the original draft of the Articles provided for a strong federal government, the sentiments of the time resulting from the war for independence from Great Britain ultimately yielded a governmental structure that consisted of a loose confederation of independent states, bound together by a “firm league of friendship.”† While the Articles did provide provision for a federal government, the language used to define its goals was undermined by the language used to describe the constraints on its ability to achieve those goals. For example, in describing the role and ability of the federal government to assess and levy taxes on the states to provide for the cost of war, including the recently fought Revolutionary War, Article 7 establishes the following:
All charges of war, and all other expenses that shall be incurred for the common defense or general welfare, and allowed by the United States in Congress assembled, shall be defrayed out of a common treasury, which shall be supplied by the several states, in proportion to the value of all land within each state, granted to or surveyed for any Person, as such land and the buildings and improvements thereon shall be estimated according to such mode as the united states in congress assembled, shall from time to time direct and appoint. The taxes for paying that proportion shall be laid and levied by the authority and direction of the legislatures of the several states within the time agreed upon by the united states in congress assembled.‡
The problem in the preceding example is simply that while the federal government is charged with a responsibility, its ability to fulfill that responsibility is up to the sole discretion of the various state legislatures. This example is representative of a more general pattern that can be seen throughout the 12 Articles. Moreover, history shows that the federal government established under the Articles was simply ignored by the states, resulting in an embarrassingly long delay in accepting the Treaty of Paris and the inability of the federal Congress to pay back debts accumulated during the Revolutionary War, including payment to soldiers of the Continental Army.
The Stovepipe Antipattern
From a software architect’s perspective, the Articles of Confederation created a governmental system that is best represented by an antipattern known as a stovepipe enterprise.§ This term derives from the metaphor of the exhaust pipes that sit atop a potbellied, wood-burning stove. Because burning wood releases byproducts that corrode metal, these exhaust pipes would require constant patching, and this patching would generally use whatever material was on hand, ultimately resulting in a chaotic patchwork of fixes.
In software architecture, a stovepipe enterprise is formed as the result of multiple application development efforts that are conducted in isolation from one another. This development approach yields a patchwork of systems built using different development methods and different technologies, and many times having overlapping or competing functionality (see Figure 5-1).
As a result, any form of integration, whether it is integrating individual systems within an enterprise or integrating with systems external to an enterprise, is difficult or altogether impossible.
Internal integration is equivalent to navigating a minefield of systems with similar terms representing different concepts, or multiple terms for the same concept. Additionally, many such systems in a stovepipe enterprise provide many of the same business processes, but use completely different rules in accomplishing those processes. Therefore, integrating one system within a stovepipe enterprise to any other system requires, at the very minimum, finding the correct system with which to integrate, resolving differences in technology, resolving differences in terminology, and ensuring that both systems have a sufficient level of understanding about the internal processes of each other.
If you multiply these consequences by the total number of systems that must generally integrate in even the most trivial-sized enterprise, you can see that the net result of a stovepipe enterprise is at best an extremely high cost of maintenance. More realistically, however, the likely result is that automated integration will not be attempted at an enterprise level, and more costly manual integration tactics will prevail. Additionally, the lack of a single interface point for external integration may inadvertently lend itself to an environment where individual systems begin integrating outside the enterprise, effectively broadening the enterprise stovepipe to a multienterprise stovepipe. In this context, the stovepipe antipattern can bring with it the unintended consequence of tying the entire enterprise to expectations set by one of its parts.
Order from Chaos: The Standards Reference Model
The core problem behind a stovepipe enterprise is that there is effectively no underlying framework to provide basic guidance around integrating systems in an enterprise. Put another way, there is no architecture. Each system attached to the stovepipe is designed independently of, and evolves separately from, the other systems in the enterprise. The solution for reversing this antipattern is found in both laying down a common set of standards around how applications are to be constructed and integrated, and creating a set of core infrastructure components to provide determinism across systems in terms of management and integration, as well as to provide consistency for integrating with external enterprises. In software architecture terms, this solution is known as a standards reference model (see Table 5-1).
| TABLE 5-1. An example standards reference model | ||
| Document | Purpose | Scope |
| Open Systems Reference Model | Defines a list of target standards for any development project | Enterprise |
| Technology Profile | Defines a more concise list of standards for a specific development project | Enterprise |
| Operating Environment | Defines guidelines around system release and installation | Enterprise |
| Systems Requirements Profile | Defines a summary of key requirements for a family of related systems | System family |
| Enterprise Architecture | Provides a complete view over a system or family of systems | System family and system |
| Computational Facilities Architecture | Defines the abstract integration points for a system or family of systems | System family |
| Interoperability Specifications | Defines the technical details for a Computational Facilities Architecture | System |
| Development Profile | Records the implementation plans to ensure successful integration between systems | System family |
As should be evident, the standards reference model is composed of multiple levels of standards based on relevant organizational scope, and it proceeds from abstract to concrete. This is an important point to note, because in any sizable organization, failure to establish proper scope boundaries when attempting to solve a stovepipe antipattern can result in another antipattern known as the blob, whereby a single entity evolves to assume a large set of responsibilities outside of those to which it was originally purposed.
NOTE
A blob or god class is the result of a poorly maintained software system where a single unit of program code grows to assume responsibility—in part or in whole— for nearly every aspect of system behavior. The result is that this unit of code becomes large and brittle (a change to one section can have dire unintended consequences to other sections), and the system does not evolve.
Some of the various scopes commonly associated with a standards reference model include the enterprise scope, the system family scope, and the system scope. To prevent the creation of an inflexible architecture, each scope must balance flexibility with prescription. For example, it is generally unreasonable to assert a code or system-scope directive at the enterprise scope, since such an assertion would be dependent on far too many additional predicates relating to hardware, operating systems, and various other tools. Rather, many times at this scope, the appropriate standard is simply to identify the possible standards that are available for use by various system families, and define a process for augmenting that list. As one proceeds from the enterprise scope to the specific system scope, the various standards can become incrementally more concrete, since at those lower scopes, there is also much more known about the objects of those standards. This scoped approach enables the standards reference model, and the order that follows suit, to scale to very large enterprises.
The Constitution As a Standards Reference Model
By the time of the Philadelphia Convention in 1787, the delegates along with the majority of the leaders of the time were well aware of the consequences from the lack of strong union under the Articles of Confederation. However, there was a great deal of debate surrounding the available alternate forms of governance. The fundamental problem was one of how to create a stronger, more permanent union between the states and provide for the welfare of all citizens while not putting the fundamental principles of liberty and self-governance at risk. Many at the time argued that a move toward a stronger central government, which had initially been written into the Articles of Confederation and later removed, was seen as an inevitable path toward the form of despotism over which the war for independence from Great Britain was fought. On the other hand, structuring the government as a single republic was also seen by many, including Federalists such as Alexander Hamilton, as simply an alternate path toward despotism. In arguing for the government laid out in the Constitution, Hamilton acknowledged that throughout history, many famous republics “were continually agitated, and at the rapid succession of revolutions, by which they were kept in a state of perpetual vibration, between the extremes of tyranny and anarchy.”‖ Hamilton is referring here to the historical example referenced by many opponents of the proposed constitution of the ancient Greek and Roman republics. Such governments were ultimately unable to prosecute an effective government or control the rise and growth of internal factions. Additionally, a more general criticism of republican government in that day came from men such as Montesquieu, who argued that a traditional republican form of government could remain effective within only a small populace.
The framers argued ardently that such prior models could overcome their historical limitations thanks to significant improvements such as the “regular distribution of power into distinct departments—the introduction of legislative balances and checks—the institution of courts composed of judges, holding their offices during good behavior—the representation of the people in the legislature by deputies of their own election.”# These were the elements that greatly shaped the U.S. Constitution and created a framework for the establishment of a confederated republic with a federal government strong enough to carry out the duties for which it was established, but engineered in such a way as to prevent a majority or minority faction from subverting the general welfare.
The confederated republican government codified in the Constitution and argued for in the Federalist Papers is similar in nature to a standards reference model. Similarly, it proceeds from the abstract definition of goals to the establishment of the various components of the federal government as well as their relationship to one another and to the state legislatures. In reference model terms, it establishes itself as the core set of standards against which all concrete standards are evaluated. It then proceeds to define more concrete participants of the systems— specifically, the three branches of the federal government. Additionally, it defines in concrete terms the relationships that the branches are to have with one another and with the states (see Table 5-2).
Like a standards reference model, the Constitution provided a unifying vision and a common set of rules by which other acts of legislation could be evaluated. Additionally, it defined the fundamental interoperability points between the various principalities that had a role to play in government, but then deferred to those principalities to the determination, promulgation, and interpretation of those responsibilities. As a framework, these lightweight qualities are what enabled the United States to reach the geographic scale that it did and even survive near collapse in the face of secession nearly 100 years later.
Continued Maintenance: The Blob and Confederacy
While the stovepipe antipattern represents just one high-level example, you can hopefully see at this point that many of the patterns that have emerged in software design have applicability in the structuring and maintenance of government. Looking into the future, another antipattern worth investigating is known as the blob or the god class.
The Blob
One of the most widely used paradigms in designing software is known as object orientation. At a very high level, this approach describes the organization of source code into discrete units called classes whose purpose is to encapsulate related data and behaviors for a given abstraction.
For example, were one to model the U.S. governmental structure using an object-oriented approach, the resultant classes might look something like Figure 5-2.
One of the benefits of using the paradigm—and much of the reason for its popularity in designing modern systems—is that it naturally breaks up complexity into manageable units of code which can be verified and maintained independently without causing a ripple effect throughout the entire system. As we can observe, this was certainly an expected benefit that would result from the Constitution’s design of a confederated republican government, as Hamilton articulates by quoting Montesquieu:
Should a popular insurrection happen, in one of the confederate States, the others are able to quell it. Should abuses creep into one part, they are reformed by those that remain sound. The State may be destroyed on one side, and not on the other; the confederacy may be dissolved, and the confederates preserve their sovereignty.*
As with any endeavor, a great set of tools or paradigms does not by itself yield a well-designed system. In the world of object-oriented design, constant effort must be exerted to ensure that the classes defined most accurately represent the abstractions that they are meant to describe and that the system’s code is most appropriately divided among the classes in accordance with previously defined goals such as independent testing and maintainability. Should the software designer become lax in this effort, an antipattern known as the blob or the god class can emerge.
The blob antipattern is generally the result of a system designed using object-oriented tools, but without the discipline of object-oriented thinking. It reveals itself in a design “where one class monopolizes the processing….”† Looking at this antipattern in terms of responsibilities, the blob class assumes a significant majority of the responsibilities in the system, and generally relegates the other classes to dependent supporters.
The problems inherent in this type of system are many, and all stem from the fact that nearly every capability that the system supports is tightly associated at the code level—a term in software design known as coupling—with every other capability in the system. Therefore, any change to one capability requires modifying the blob class, which would then impact every other capability for which the blob has assumed responsibility. This creates a situation that is inefficient at best due to the amount of energy that must be exerted to manage changes or new capabilities. At worst, it dramatically increases the likelihood that changes to the blob will unintentionally break a seemingly unrelated part of the system.
The solution for keeping an object-oriented system from devolving into a blob antipattern is constant expenditure of effort to ensure that all system logic meets two basic criteria: high cohesion and low coupling. High cohesion describes ensuring that all code that is logically related is physically grouped together in the same class. This enables a discrete area of functionality in a system to be more comprehensible, and more importantly, testable. Low coupling describes the removal of as many dependencies as possible between the aforementioned cohesive units. This enables each unit to evolve independently while significantly reducing the risk that the evolution of one unit will unintentionally cause the failure of another. Additionally, it has the added benefit of enabling the designer to more confidently evaluate the efficiency of each unit without the distraction of the efficiency or inefficiency of related units.
The blob and government
The blob antipattern many times develops when a system is relatively small in size. The entire system can be known in whole, and so the necessity of solid design is less obvious than in large systems, where the sheer number of capabilities provided makes such principles a necessity. The framers of the Constitution also understood these principles in context of the size and scope of government. For example, in articulating how an extensive republic is more beneficial to guarding the public interest, James Madison argues that by extending the sphere:‡
…you take in a greater variety of parties and interests; you make it less probable that a majority of the whole will have a common motive to invade the rights of other citizens; or if such a common motive exists, it will be more difficult for all who feel it to discover their own strength, and to act in unison with each other. Besides other impediments, it may be remarked, that where there is a consciousness of unjust or dishonorable purposes, communication is always checked by distrust, in proportion to the number whose concurrence is necessary.
Madison argues here that the size of the union was one of the very things that would shield it from the rise of despotism at the hands of any group of citizens, whether they are in the majority or the minority. On this point, I believe that additional reflection is warranted. Madison seems to define size predominantly in terms of geography, and as such, the difficulty that he describes in specific groups being able to discover their own strength seems to be somewhat predicated on the geographic disbursement and isolation of the various members.
In the present age, we live in a society where access to any person or any piece of information is never more than a few button or mouse clicks away. Size, according to its utility as described by Madison, cannot be measured in square miles or even number of people, but in the speed with which individuals can connect with one another. And by this definition, the sphere has in effect grown smaller. This increases the risk of the blob antipattern developing in government by way of the blurring and sometimes outright dissolution of the scope boundaries established explicitly in the Constitution and implicitly as envisioned in the Federalist Papers. A governmental blob can take many forms; however, media and the press can serve as a good indicator for where the concerns of citizens are most closely placed. And this indicator is not encouraging as we are witnessing the continued decline of local news outlets due to either consolidation or outright closure. This places the responsibility of all news—and by association, all perceived concerns of government—to national news organizations, who as a product of seeing a high return on investment for each news story they pursue, will naturally focus their attentions at the federal scope. A shift in the focus of the citizenry from an inherently local to federal scope, coupled with a smaller society as a result of advances in technology, creates an environment where it becomes easier for political factions to mobilize and where their effects can be far more reaching and destructive.
Conclusion
While this chapter is not intended to provide comprehensive treatment of republican government and Constitutional history, nor a complete catalog of software design patterns, it has hopefully demonstrated that there is a strong correlation between the two, and has effectively put forth software design as a new metaphor for exploring the dynamics of government. Further, as we are currently in a period of widespread reform efforts, the lessons and mitigation paths described in antipatterns, such as the blob, can help to ensure that reform efforts continue to yield a sustainable and maintainable republic.
The next logical step, and the subject of future research, will include taking aspects of the U.S. governmental system and actually modeling them in software. Such an endeavor will more concretely demonstrate the patterns outlined in this chapter, along with many others. More importantly, however, it will create an executable model that can be modified and tested based on the application of new patterns. As the evolution of technology continues to change some of the fundamental dynamics of our society, it is likely that the very same technology will be necessary to enable our government to evolve as well.
===
* Federalist 9.
† Articles of Confederation, Article III.
‡ Articles of Confederation, Article VIII.
† AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis (Wiley, 1998).
‖ Federalist 9.
# Ibid.
* Ibid.
§ AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis (Wiley, 1998).
‡ Federalist 10.