At the heart of IT operations in a Fortune-500 company was a document management system that accepted close to 70,000 order-related documents each day. Upon their reception, these documents triggered most company operations, driving multiple transactions within the company's various business departments. Transactions between internal departments were governed and routed through an elaborate workflow framework that was tightly integrated with the document management system. Though the current IT framework was able to accommodate the current business operations load, the projected, future business growth demanded a five-fold up-scaling in volume handling to support business expansion over the next decade of company operations.

Company management had instructed the IT department to implement a major overhaul of the IT infrastructure to allow up-scaling of needed capabilities within a year. However, when the reengineering phase of the upgrade began, the responsible manager found that very few people in the IT organization actually knew how the system is actually worked. When we investigated the situation we found out that during the 15 years of the system's operational lifetime, most of the people that designed, implemented, and maintained the system had either migrated to other positions within the company or left the company, altogether. In addition, over the course of its lifetime, the system underwent four major hardware upgrades and two major database changes that were necessary, just to to keep up with computer technology changes. With all of these changes, and with new people displacing department veterans, maintenance of the system became a nightmare. Due to the distributed structure of the system, it was next to impossible to try understanding how the system truly behaved merely by examining the source code.

Our assignment was to reverse engineer the system and document it to the best degree possible to allow the development team to model the system with a new, clean implementation that would allow the desired performance upscaling.

For several months we observed the system in action, collected data samples, carefully examined the source code, and interviewed dozens of people who were involved with development and/or maintenance of the system during the course of its lifetime. We documented our findings and periodically, reviewed those findings with members of the System Reengineering Development Team. To minimize possibility of misinterpretation or ambiguity in our documentation, we also verified our findings with some of the key team members that we interviewed. We made a special effort to summarize facts in tables and graphical form, since we knew from experience that complex information might be easier to comprehend in such form.

The net results of our work were bound into two Internal company manuals. The first one, was a 120-page overview document that provided an abstract view of the system and its operations. This document provided both an external (user view) of the system as well as a simplified functional view that allowed new developers to acquire good level of understanding about the system's capabilities. The second document was a 550-page reference document that descended to a lower level of detail and documented all system interfaces, the systems's internal structure, a description of major subsystems and modules, and provided references to other documents and other sources. This document eventually evolved into the main reference document for the reengineering effort and continued being updated throughout the development phase. Later on the documents that we produced were very successfully used through the testing and deployment phases. Our client was very happy.