This post might more accurately refer to Totalitarianism instead of Socialism but what it lacks in precision, it makes up for with alliteration!
July 4th! Independence Day. In Seattle, we also refer to it as “the day before summer begins.” It always rains here on July 4th. It’s a tradition.
Beyond its meteorological implications, July 4th commemorates the signing of the Declaration of Independence. 232 years ago, representatives from the original 13 colonies formalized their desire to secede from the British Empire. What beef did they have with King George? Why all the fuss?
True, we know they were upset about “taxation without representation” and about the Stamp Act and import tariffs. Did you know, however, that Britain had ceded on all these points? Did you know that the 13 colonies had the highest standard of living in the world at the time and a very low tax rate?
Beyond any concrete economic or political issues, the colonies wanted to secede from Britain because they resented being told what to do by a remote sovereign that treated them as second-class citizens. If you read the Declaration of Independence and, even more so, the Constitution, you will easily detect a fundamental distrust of centralized Federal government. The forefathers went out of their way to delegate the least number of powers to the Federal government – the rest were reserved for the states. Arguably, the 2nd Amendment is all about the rights of the States to maintain militias so that they could fight the Federal government. Remember, the militias were formed to fight the British. The last thing the colonies wanted was to be powerless against another powerful central government that might turn out to be just as objectionable as the first.
This fundamental question of State vs. Federal rights is one that remains with us today. Battles over abortion, Medicaid payments, “No Child Left Behind” and other issues focus on what are state responsibilities and what are Federal responsibilities. The States rights proponents argue that local government is more efficient and more responsive to local needs than a centralized Federal government.
Centralized vs. distributed control is also a frequent topic of discussion in Socialist vs. Capitalist systems. In Socialist systems, the State owns all the capital and decides how to allocate it. In Capitalist systems, individuals own capital and they decide how to invest it. Again, the question is one of tight, centralized, control vs. a loose distributed system.
This same tension exists in large software architecture. To what degree should software be tightly controlled by some central program vs. loosely controlled and autonomous? Occasionally, I will review a design for a complex system and I will compain to the architect that the design is “too Communist.” What I mean by this is that it too heavily relies on central planning and control.
As with governments and economies, there is a strong argument that software architecture should avoid excessive dependence on centralized control. Centralized control can lead to very brittle software that breaks when an alternative design would simply bend. Centralization frequently translates to designs with single points of failure. A server goes offline or a process fails and the whole system collapses.
As one who dislikes both centralized designs and socialist governments, I like to see software architectures with:
- Redundant, clustered, storage (e.g. from Isilon)
- Compute and database clusters based on active/active designs to minimize failover time
- Pull-based models where automonous components ask for what they need instead of push-based models where an executive tells the others what to do
- Self-organizing systems rather than ones driven by rigid configuration
It is my premise that such systems are no harder to develop than centralized ones but they do require more creative architects to design them. Because we tend to design systems in a hierarchical fashion, it’s easiest to develop control systems that also flow from top-to-bottom. Developing loosely coupled systems takes a different mind-set. Once you’ve identified the components in your design, you need to treat each as an independent entity and you need to think about how they get the information they need and what they do with it when they’ve finished processing it. You also need to consider what each entity should do when it detects and error condition. If you design your components to be independent and robust, your design might be better able to heal itself if a component has an intermittent failure.
It is true that, in the physical world, there are economies of scale but it is also true that past a certain point, inefficiency and bureaucracy increase with organizational size. In the software world, there are few benefits to centralization and size and many clear deficiencies. As the computer and IT industry moves increasingly towards outsourcing and SaaS, we need to keep in mind to what degree delegating responsibilities to service providers is a move towards centralization and all of its flaws.