Bhaskar, Beautiful analogy. It fits marvelously well with my own understanding from developing VMACS all these years but it covers some aspects of the whole process much better than other analogies I have been using to describe how to successfully build and maintain a complex integrated long-lived system like a Hospital Information System.
We have re-engineered or renovated pretty much every part of our system many times over the last 20 or so years. We have managed to change foundational components and even to introduce new ones many times. As we have learned more about the way we build applications, we have abstracted common features into generalized functions and utilities and then we have gone back and rewritten applications to utilize the more abstract components so that over time the applications tend to shrink while gaining in functionality and uniformity of behavior. Most recently, we have been engaged in converting the lower levels of VMACS over from Datatree MUMPS on DOS (more recently known as DTM) to GT.M and Linux while avoiding any noticeable down time. (Thank you Bhaskar and Sanchez!) The last time we engaged in anything that major was 1989-1990 when we switched over to Datatree from Intersystems M11+. The analogy I used back then was that we were changing out the tires on a large bus that was full of passengers and traveling down the road at full speed. This time I don't yet have a good analogy for it. The system has grown immensely in every direction. There are PC's everywhere. VMACS touches nearly every facet of hospital function, patient care, student education, research,etc. Most of the system is web accessible. Our computer staff has increased in number from 3 to 12 (large for veterinary medicine, small for human). It feels like we are now late into the process of transforming the bus into an airliner - proceeding down the runway, just about ready to take off. :) >The discussion about the number of function points in large >applications reminds me of the parallels between software and cities. > >Why should a system that is working well need to be replaced? >Successful software systems are like cities. There are cities in >Europe that have been continuously inhabited for thousands of years. >London or Rome today would be unrecognizable to Julius Caesar, yet the >old cities were never abandoned and replaced - they were just >continuously re-developed over the centuries. Although we like to >discuss replacing major software systems because their quirks annoy us, >perhaps we should think of these as limitations that must be lived >with, just as in these days of the automobile, we still deal with >streets in Boston that were engineered for horses and wagons, and we >have no intention of razing and rebuilding downtown. > >The prospect of "big-bang" conversions of large mission critical >software systems gives CIOs ulcers just the way that the prospect of >razing and rebuilding downtowns gives city fathers ulcers. > >I suspect that in the not too distant future, a school of thought may >evolve to the effect that large software systems will not only not be >replaced, but also that we should not plan to replace them. Just as we >may tear down buildings and build highways, perhaps we should not think >in terms of replacing large software systems, but in terms of a process >of continuous modernization and renewal (with the software equivalent >of urban decay if money is not spent on maintenance when it is needed). > >Perhaps the first lesson is that instead of asking what the life >expectancy is of a mission critical software system like VistA, perhaps >it is more meaningful to ask what it takes to keep it healthy and >contemporary on an ongoing basis. > >Cities evolve. With a few notable exceptions of seats of Government, >cities are not greenfield creations. They start small, and grow, and >what they are good at changes over time. > >So the second lesson for software is probably that mega projects that >try to do everything are almost certainly doomed from the start. >Although I have no personal knowledge of the failed Kaiser Permanente >application, it would seem to be of this nature. The history of >attempts to replace VistA variants (e.g., CHCS at the Department of >Defense) are also not encouraging. > >Rome was not built in a day. > >A third lesson from the analogy is that, since large applications >evolve, they will always have aspects that are obsolete and awkward. >So, if we love them, we must love them warts and all. > >-- Bhaskar --------------------------------------- Jim Self Chief Systems Developer and Manager VMTH Computer Services, UC Davis (http://www.vmth.ucdavis.edu/us/jaself)
