I recently heard from an older computer user who was delighted that his hotel’s free WiFi simply worked with his notebook computer. Internet access on the road didn’t use to be so easy, either for hotels or their guests. Consider these three (hypothetical) hotels:
- In 1995, hotel #1 spent a lot of money to redo its digital phone system to make it compatible with computer modems.
- In 2000, hotels #1 and 2 spent even more money to run Cat 5 (Ethernet) cable to all of their rooms
- In 2005, hotels #1, 2, and 3 spent much less money to set up a few WiFi hotspots.
A quickie moral would be that hotel #3 came off better, since it ended up in the same place for a fraction of the cost, while the other two suffered from a first mover disadvantage. Reality, of course, is more complicated.: hotels #1 and 2 had five years to amortize each of their earlier investments. If those investments allowed them to steal guests from hotel #3, or to charge higher rates, then the investments may well have turned a net profit for the hotels.
The real moral is that the one that the extreme programming advocates push: build for today. As long as hotels #1 and 2 were investing in technology that their guests needed right away (rather than at some ill-defined point in the future), they probably came out OK. On the other hand, if a hotel were putting in technology just because, some day, it might be needed, it probably saw that technology superceded before it could bring in any return.
If this moral seems simple and obvious when applied to hotels, then why do architects ignore it sometimes when designing information systems for big enterprise and government? When we sell them on something like WS-* (or a REST-based data architecture), what criteria do we use to figure out whether we’re building for today, or for a tomorrow that may never come?