Reverse Engineering

I support several units outside of the Enterprise Data Warehouse to retrieve, process, and export information. Most of this work is done using straight PL/SQL (Oracle’s transactional SQL language). However there are quite a few processes on a platform that we no longer want to support. These processes have a minimum (and I do mean minimum) amount of architectural documentation. This leaves me with the unenviable position of having to reverse engineer these processes and draw up a plan to convert them to a new platform.

Reverse Engineering – The process of discovering the technological principles of a device, object, or system through analysis of its structure, function, and operation.

Just to be clear: The only reason this is necessary is that the original architectural documentation was a) lost, or b) never completed. If the person who originally created the process or someone who understands the process was available to write the architectural documentation, reverse engineering would not be necessary. This, however, is not the case I found myself in.

So…How do you reverse engineer something? Here are the steps I’m using:

  • Get access to the current system.
  • Use current system to create a sandbox area.
    • If a sandbox already exists, ensure that the sandbox has the most up-to-date source code from the production environment.
  • Familiarize yourself with the existing platform: You need just enough knowledge to navigate the environment and read the processes. You don’t need to program it.
  • Start at a very high level and work your way down to the details. Each level that is delved into gives insight and clarity to the next. During this iterative process create the following documents:
    • Diagram of the major items. (These items will get smaller and more detailed the further down the iterative path you get.)
    • Description of the major items.
    • Listing of item’s code elements and locations.
    • Listing of major business rules.
    • Any other information that clarifies the system.
  • Analyze documentation and look for areas for efficiency gains and process streamlining. Modify documentation where appropriate.

Yeah…This is boring and tedious and VERY TIME CONSUMING. Example: My current documentation for the DMExpress jobs I’ve targeted for conversion is just north of 140 pages! Think of it…how much is it costing the company when this type of thing happens?

What it is not is a waste of time. Once completed I can sit down with a group of developers and break down this documentation into Agile stories ready for development. And this is exactly what I plan on doing.

I will return to my regular subjects shortly.

Leave a Reply