website paiken:research

We have been reverse engineering a new commercial off the shelf (COTS) system - attempting to obtain specific technical information, metadata, that isn't in the documentation and that can aid system implementation and management. That the actual reverse engineering was straightforward was a pleasant surprise. The resulting metadata was successfully re-used by specific processes associated with what the vendor described as one of its largest public sector implementation to date. The ISRI project team has developed metadata describing complex relationships and interactions between file elements, screens, processes, and other system components - in a relational database management system that is accessed by system implementers.

The figure illustrates one key metadata use - managing and understanding the sources and uses of the system data. A user asks about the source of report element RE(36) - a part of report R(3). Conceptually, the metadata indicates that the source of RE(36) is screen element SE(223) that is part of screen S(337). From this same metadata subset, users can determine what screen elements are printed on what reports; what reports print what screen elements; what screen elements comprise each screen; and what report elements are part of each report. Other specific examples of metadata use include:

• Use of panels to verify system and user requirements - more than 1,400 system screens were cataloged according to their relationships to menu items, database table, and work flow process. This permits users to determine which database elements and tables are related to which work flow processes; which work flow processes are accessed from which menu items; and which database elements appear on which screens.
• Evaluation of proposed system changes, modifications, and enhancements - the metadata was used to answer questions such as: "How many screens & tables will have to be modified if we use SSN for a primary key instead of taking the default?" and "Which screens must be modified if we want an email address to appear every time we display a person's phone number?"
• Migrating data from legacy systems to the new COTS system - metadata linking entities and attributes from the two legacy systems being replaced by the new COTS system permitted data engineers to structure the data migration process. More than 2,000 individual legacy system data attributes were programmatically mapped and then migrated to the new system. Understanding of which legacy data attributes were associated with which legacy system files and which COTS data attributes were maintained using which COTS database tables permitted comprehensive mapping of existing data onto the new system data structures.
• Analysis of system and business practices - specific combinations of the work flow hierarchy and systems screens were identified and associated with current business practices and user groups. This enabled the project team to define link specific system functionality to user groups, addressing end user questions such as "Which screens will I be responsible for learning?" and permitting development of end user training plans. Two more illustrations show this use of metatdata. The first describes the system according to its major components and the second shows the relative complexity of the develop work force portion of the system.

More metadata information is now available, we have just published a very nice paper in IEEE Software describing this effort in more detail.