Having created a successful implementation of metadata-driven design with our job scheduling system, we were given the official nod to proceed, and we began to develop the main project in much the same way…until we were told to stop after only taking a few steps. As with the case of many other project beginnings, we were suddenly handed yet another new requirement for our design to overhaul the product data system. A few years prior, the Sarbanes-Oxley Act had been passed by the U.S. government, and our hired auditors were now pressing us for certain guidelines to be met by our various departments. To be in accordance with the regulations set by the new bill, a certain amount of auditing data needed to be recorded in reference to data processing. Of course, I expected such auditing to be applicable to our groups who dealt with finances and inventory, but I was surprised to learn that it even applied to the product data itself.
In addition to simple access controls and a few other minor goals, the design now also had to provide functionality that could generate reports about data processing and its various idiosyncrasies (such as how many times a product’s price was altered on any given day). Despite the compulsion to complain about this additional work, I instead saw it as yet another opportunity to showcase the flexibility and adaptability of our new trusted method. After spending hours in sessions to iterate and improve the metadata (within various tables and files) of our new system, we had designed a decent blueprint that described the fundamentals of our data processing. With this foundation set in place, the task of incorporating this new specification was the simple addition of another layer upon its sturdy shoulders. Our metadata just needed another iteration of examination and enhancements, and after our design team had met and conversed on the subject for a few hours, we delivered a revised plan that now accommodated this new set of imperatives:
Even though we had already started to develop the engine fed by our metadata, we were sure that it would take very little work and very few code changes to adapt this new functionality within the implementation. After a couple of design iterations and after writing a few more lines, our code base suddenly had both auditing and reporting layers that were also fully integrated with the existing metadata. In the weeks that followed, we continued to enhance our design by incorporating more options for management, like creating a flag that allowed managers to specify which fields should be audited. These requests, like the initial auditing feature itself, were easily handled with the application of metadata-driven design. Even though the number of requests aren’t nearly as hectic as compared to years before, we continue to receive requests on an infrequent basis, and as of yet, they have nearly all been quickly brought to fruition through this technique.