Brittle Systems

Lets face it, GIS systems are complicated. Typically there are multiple servers and applications that make up a “system”. Each of these represent a potential point of failure, thus creating a brittle system. Brittle systems break. The definition of the word brittle is:

Brittle: Solid, but liable to break or shatter

In other words, we can design solid systems that serve us well, but they can be brittle. We can push on them a bit and they perform well, but push too hard and the whole thing shatters.

Lets take a look at an example of a potentially brittle system. This system is designed to serve GIS data over the web and is fairly typical. The components of this system might be:

  • Database server
  • Database software
  • Web server
  • Web server software
  • GIS middleware
  • Application framework software
  • Map server software
  • WMS data sources from one or more Internet servers

This system should be fairly stable, so where are the potential failures? Ever had someone move, rename or worse yet delete a layer or data source? How about someone changing the password to your GIS data stored in your spatial database?

These are certainly things that contribute to brittle systems. Perhaps the biggest problem (especially in larger organizations) is the dreaded Dependency Dragon. Components are built to work together but they have version dependencies. You can’t run a modern word processor on your operating system from 1986. Likewise, you have to match your server and GIS software to the appropriate versions. This is overstating the obvious, however it is one of the major problems in maintaining a stable non-brittle system.

If we never had to upgrade anything, we would be in pretty good shape, assuming the power stays on and we can afford to pay the ISP. Then a critical security patch comes along for one of the system components and the dreaded upgrade cycle begins. This can be mitigated if we have complete control over all the servers and software that make up our system. If not, we may find that an operating system upgrade over the weekend has reduced our shiny mapping application to brittle pieces scattered over the digital landscape.

Much has been written about systems reliability and I don’t express even a hint of expertise in this area. What follows are observations that may help to reduce the “brittleness” of a GIS system. This applies to both web mapping and desktop/enterprise systems. To make a system more stable and less brittle, we must:

  1. Minimize the number of potential failure points

    This can be accomplished by consolidating services where possible and simplifying the ways in which data are generated, updated, and maintained.

  2. Manage change from a holistic perspective

    Systems are just that. They interoperate and therefore must be managed as a whole. This can help avoid disconnects and changes that contribute to failure. To do this, we must involve the system administrators, database administrators, application developers, and data administrators. Often changes that break a system are made by a person that has no clue about the consequences of a seemingly minor change.

  3. Plan for change

    Don’t let it just happen to you. Plan and coordinate changes to operating systems, databases, data, and applications. This of course requires communication with all involved.

  4. Document the Dependencies

    Creating dependency diagrams and/or documents and using them as a reference point for change can help you avoid the dragon and eliminate failures related to upgrades, enhancements, and security patches. By identifying the components in a system and documenting how they interact we can prevent mishaps.

No system can be 100% reliable, but brittle systems are like a millstone around your neck. They are time consuming, costly, and can have direct economic impact if not brought under control.