In 1999 Ryan McCormack and I wrote a marketing piece on Globalization for Sapient Corporation. Aimed primarily at raising awareness of the issues involved in building global Internet systems it also touched on national market analysis and selection. I was reminded of this diagram showing income and connectivity for every country in the world from that piece while reading various articles on US Foreign Policy recently. These articles included this piece called the Pentagons new Map by Dr Thomas P.M. Barnett a US military Strategist on Globalization and US Foreign Policy and this more
>jaundiced view from the Washington Monthly.
Basically I think Dr Barnett is on to something when he claims that “disconnectedness defines danger”.
Show me where globalization is thick with network connectivity, financial transactions, liberal media flows, and collective security, and I will show you regions featuring stable governments, rising standards of living, and more deaths by suicide than murder. These parts of the world I call the Functioning Core, or Core. But show me where globalization is thinning or just plain absent, and I will show you regions plagued by politically repressive regimes, widespread poverty and disease, routine mass murder, and “most important” the chronic conflicts that incubate the next generation of global terrorists. These parts of the world I call the Non-Integrating Gap, or Gap.
Having said I think Dr Barnett is on to something I don’t think his conclusions are correct! He makes three mistakes;
L. Peter Deutsch first published the “8 Fallacies of Networking” internally while working at Sun Labs in 1991-92. This is a great list of the kind of wishful thinking that clouds so much system design.
Essentially everyone, when they first build a distributed application, makes the following eight assumptions. All prove to be false in the long run and all cause big trouble and painful learning experiences.
- The network is reliable
- Latency is zero
- Bandwidth is infinite
- The network is secure
- Topology doesn’t change
- There is one administrator
- Transport cost is zero
- The network is homogeneous
Most Software systems are developed by corporations to gain parity with, or advantage over, competitors. These systems are either intended for sale as products or to be used internally but in both cases they are supposed to produce positive business results for the corporation that uses them. As anyone who has ever been involved in the development of software systems will know they often fail to produce a return on investment and sometimes fail to produce any benefit at all. This failure to achieve business value stems partly from difficultly system designers have in tracking the changing relationships between Policy, Strategy, and the Architecture they are responsible for designing.
Recently, I have been traveling to Washington D.C. via Washington Dulles International Airport and have begun to appreciate the fine architecture of the airport. Built between 1958 and 1966 by the engineering firm of Amman and Whitney the terminal building, control tower, and service buildings were designed by Architect Eero Saarinen who claimed it was “the best thing I have ever done.”
5 Nines is a term used in the computer industry that refers to the 5 nines in 99.999%. This number is about the best odds manufacturers will give that one of their systems will be available at any given moment in time. Of course there are systems with higher availability but they tend to have very expensive multiple redundancy. 5 Nines is the best availability claimed for commercial system, and after all, 99.999% availability is pretty good. 5 Nines translates to a downtime of only 5 minutes a year.
Joel Rosi-Schwartz once advised me that if I ever found myself solving the same problem for a third time I should stop and take the opportunity to improve my efficiency by thinking of a better way to do it. Joel was very disciplined about this and over the years had developed a big bag of tricks for solving common problems encountered during systems design and development. In many ways Joel was an inspiration for me and this is one of his traits I have tried to emulate.
In my career I have designed more than a few systems and reviewed the designs for many more. There were times when I reviewed two or three in a week and others when I went 6 months between reviews, but they have never stopped coming. Following Joels advice I have tried to incrementally improving my approach to both designing systems and reviewing others designs by developing a set of aphorisms that remind me what should be present in a good system design.
The measurement and management of time is something most people give little thought to. But when designing Internet based systems time presentation, manipulation and management can rapidly become a major headache. Just when you think youve got it nailed some other unanticipated problem arises. The regular failure of systems designers to get this right is a classic example of the principle of inappropriate parsimony.
The world is a sphere that rotates on its axis once every 24 hours and takes 365 days to rotate around the sun, more or less. Its very simple. But, the more or less part is vitally important. The world is not actually a sphere it is an oblate spheroid. It does not rotate every 24 hours it takes a ever-so-slightly longer than that and its getting slower, it wobbles on its axis which by the way is inclined to the plane of its rotation around the Sun. And as we all know it takes about a 1/4 of a day longer than a year to rotate around the Sun, more or less, and this time period is also increasing. Add to this the vagaries of international politics, national pride and public safety and you have a pretty complex system. All these factors affect the measurement and management of time. Given this complexity its not difficult to see why system designers try to simplify the conceptual model of the real world on which they base their solutions. However, this is the wrong thing to simplify. The solution can and should be simplified but the conceptual model on which it is based must be high fidelity not an approximation.
There is a class of design problem that can mislead the unwary systems designer, myself included, although I am getting better at identifying the warning signs. These design problems require the designer to base the solution on a conceptual model of a real world system or process. It often appears that a simple conceptual model that approximates to the real world system will suffice. In practices solutions based on these simple, low fidelity, models fail to handle the problem completely and often causes a whole series of new problems. Redesigning the solution to handle these exceptions only produces more problems that require more redesign and so on. If the hapless designer persists s/he will often go through several complete redesigns before getting to a solution that finally solves the problem by modeling the real world system with a high degree of fidelity. This iterative redesign process is typical of this class of design problem. Some might say that only poor designers are ever trapped in this way, others will say these solutions are anti patterns. But I think there is more too it.