A few days ago, my first professional article about metadata-driven design was published by the venerable community at InfoQ. Many thanks to them, and you are encouraged to read it here. Go check it out!
——–
Metadata Driven Design – An Agile Bridge Between Design and Development
Aaron Kendall of Barnes & Noble discusses an Agile method they have been using that combines the design of the overall architecture and implementation.
Recently, we had to amend a Java project with some additional functionality, specifically to access Oracle databases and to automate the secure copy of files from one machine to another. After taking a quick look around online, I learned how Oracle’s licensing prevents the placement of its JDBC .jar file in the Maven repository (which apparently is yet another addition to the ongoing soap opera that is Java), and I learned about the Java Secure Channel project. In regard to the latter, the documentation was somewhat sparse, but there was a working example of how to replicate ‘scp’ functionality using its library. I added the JSch dependency to my POM file, and after only a few minor adjustments to its working example, I had it successfully running in our Java project. All in all, I was impressed with its ease of use. I only had one question: why wasn’t its working example (along with other documented examples) added as an actual method in its library? After all, thousands of developers were obviously cutting and pasting this example, leading to possible code bloat in other open source projects. Would it introduce too much of a maintenance nightmare to do so? Like with Oracle, were there legal reasons? Will Oracle ever change its licensing to become more compatible with open repositories? Tune in tomorrow and watch the next episode of “The Days of Our Java”.
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.
Meta Data Dojo 