Stability in a dynamic world

Technology is not unlike fashion. What was once considered hip and trendy falls out of fashion, only to returned in a retro-improved way after a period of time. I never realized this until I hosted a group of Dutch Waterboards at the ESRI Headquarters in Redlands, CA…

Seeing some of my former clients after some 5 years was a pleasant distraction from the day-to-day business of projects and product development. It provided an opportunity to recollect some of the work we did on creating a common data model for water boards in the Netherlands ten years ago and look at how the goals of that project were doing: share application development to reduce redundant investment, less dependency on a particular application vendor, bridge the information gap between organizational units and business processes, and others.

Although the data model has changed name, its contents are still very much alive. Over the years, the Waterboards have developed several client-server applications that connect to a single data store, thus integrating the various business processes within a Waterboard. All organizational units have the same definition and information for the objects they manage, including but not limited to waterways, hydraulic structures, permits, and numerous other aspects of water management. This would lead you to think: mission accomplished!

But the group of visitors expressed new desires that have come up in this past period that have lead to their study trip to the United States: further separate the layers of the application architecture or the use of new features in supporting software components, to name a few. Over time the client-server pattern has been followed by thin-client and other application architectures. More recently service oriented architectures and the enterprise services bus (or is it services-buzz?) are in-vogue. The accepted styles for user interfaces have changed with those technologies as well. Not that the current application wasn’t meeting the initial needs, but the needs have changed with the advent of new technologies and capabilities: how did we ever do without AJAX?

People trade in their cellphones, not because the old one is broken, but because the new ones have more cool features, and the availability of those features creates the need for them. This is the old supply-demand principle of a market economy.

This principle also applies to software technologies as well. Where a couple years ago the use of HTTP GET/POST protocols for the Open Geospatial Consortium (OGC) services specifications was well accepted, there now is a growing need to add support for SOAP/WSDL to these specifications. Not because HTTP GET/POST doesn’t work, but because the context in which the OGC services are being used is changing to use Service Oriented Architectures (SOA) that require the use of specific standards such as SOAP. Note that the data or the data model that is made accessible through these changing protocols is not affected by the particular choice of protocol.

Well, ever noticed what happens if you use SOAP (most noticable in the shower)? It dissolves and you have to buy new soap! New technologies will come for messaging, information exchange, presentation, aggregation, central versus distributed data management, and what not. Acknowledging this is half the victory of the technology battle: do what makes sense for the foreseeable future, follow the general trends of IT, and assess what and when new technology fits your business needs.

For the Dutch Waterboards, the constact factor in this 10 year period has been the data model, confirming one of the assumptions that lead to the definition of the data model to begin with. The tremendous effort that was put in analysing entity-relationship-diagrams, class-diagrams, data dictionaries, and other exciting materials, proved its value in a world of ever changing technologies.

Appeared in GeoInformatics Magazine (www.geoinformatics.com) in October 2006

Traffic congestion

Part of our moving to Redlands is to get used to dollars, ounces, gallons, and miles. Just when we thought we missed out on the change to the Euro, we find ourselves in conversions of our own. Fortunately, one thing has not changed upon moving to the Los Angeles basin: driving a car often means: follow the red lights in front of you…

Another stable factor so far has been the use of Internet. We still use the same free e-mail provider as we did when we lived in the Netherlands. We only use it more often and with more people than before.

There is a kind of analogy between the road network and the Internet. First of all, the Internet and roads are collections of connected networks that allow transport between two locations. The networks may differ in type or size. Through agreed standards it has become possible to have objects pass from one computer network to another, thereby allowing the object to travel further than the limits of the originating network. And similarly, when traveling through Europe, I never had to change tires when crossing the border between two countries.

Just as is the case with the Internet, bandwidth is important on the road network. Bandwidth on a sandy forest road is much smaller than on a 4-lane interstate. And people using both types of networks share a preference for high bandwidth.

The increase in network traffic is the source of the third analogy between roads and Internet: traffic congestion. No matter the size of your driveway or the horsepower of the engine of your car, you will get into a traffic jam just as you turn on the highway. And similarly it doesn’t seem to help to have a cable modem installed to surf the web when everybody else does the same and uses it at the same moment you do.

So, now we have seen that the two types of networks are similar and share the same problems, can we benefit from this knowledge? Perhaps we can. Over the past years we have been building more roads, thereby increasing the bandwidth. This was not enough to meet the increasing demands due to the need or desire to travel.

With Internet traffic a different development can be observed. In the early nineties the Internet was accessed through a 9600 bps modem, the happy few having access to a 14.4 kbps one. Since then data volumes have increased exponentially, now allowing us to serve GIS data and functionality over the Internet.

Apparently we have found some solutions that help to minimize traffic congestion on the Internet. Whether it is data compression (car-pooling), or the use of high bandwidth backbones in addition to low-speed home phone lines (treating local traffic differently from long-distance traffic), there should be something we can learn from Internet developments when designing new road plans or addressing traffic problems in our GIS consulting work. Indeed we already apply some form of packaging (as is done with information sent over the Internet) with the introduction of traffic information systems that guide us along a route that has the least chance of jams!

I do not pretend to have the solution to traffic congestion problems. But we tend to keep following a familiar line of thought in solving geographic problems, and that has not always helped us find a more permanent solution. Sometimes the solution to a problem is found in an unexpected location or at an unexpected moment. So be sure to always bring your notepad and pencil, wherever you go, just to make sure you don’t miss that one leap of mind.

Appeared in GeoInformatics Magazine (www.geoinformatics.com) in April/May 2002