Ever had the feeling that you are an Information Archaeologist?

How many times do you have to find out what the functionality of a systems is and what the data means? A lot of times you come to the conclusion that the documentation is not sufficient or (most of the times) not available, and that the people who've build the system are long gone. The only thing that remains is "The Code is the Documentation". Well then you end up in what used to be so neatly called 'reverse engineering'. Actually what we are doing then is the modern form of Archeology. Scraping layer by layer of code, data and applications in order to understand the true meaning of the application landscape. The Software Archeology excercise is mostly done when we being asked to rebuild an old application into a new landscape. Most of the times we put developers to work who are trained in new technologies, but have got no clue whatsoever about the old technology in which the application is build. The result is that these teams are recreating over and over again the 'Stone of Rosette', or the key to translating the functionality from the code. We tend to forget that the system is not only build based upon functionality but also about what the technology enables and what the strenths and weaknesses are. So for instance the reason why procedural languages are used in heavy batch applications (performance....) only comes to live when the application is rebuild into an Object Oriented application, resulting in bad performance. So the AS-IS situation of a landscape, and all the reasoning behind it, is almost as (or even more) important then 'the Future state to be'. The roadmap towards the Future state to be is the task of a (Software) Architect who knows not only knows the 'New technologies' but has a strong background in the 'Old stuff' and all the reasoning behind it. Only then can we move towards a Stability Based Architecture (SBA).