At this point, metadata-driven design had clearly become a favored tool at our meetings for designing our new architecture, but a compelling argument had not yet been made for the case of using this metadata as the basis of an implementation. Some managers were very hesitant about such a massive undertaking, and even though we empathized with this skepticism, we steadfast few had the conviction that it was entirely possible and that it was well worth the risk. However, without any proof, we didn’t have enough ammunition to win our case, and the two sides of this issue were at an impasse. The onus of proof was on us, and in order to bolster our argument, we would need to show something tangible. (After all, it was one thing for the Product Master dev team to incorporate this new method into an existing implementation, but it was something entirely different to create a new architecture around it.) Fortunately, an opportunity arose when people finally began to talk about the revamp of our job scheduling subsystem; this particular subsystem mainly existed in order to load data files into our product data schema. Recognizing it as our sought chance, we nominated this overhaul as the flashpoint for our assertions, and we requested permission to create a new job scheduling subsystem, both designed and implemented using our metadata-driven design method. Management, in turn, agreed to our request; they were satisfied with giving us a project with less dynamite to hurt ourselves and others.
I and a fellow colleague took the lead, and fortunately, my comrade-in-arms had more business knowledge than me. Due to having worked on the professional job scheduler ActiveBatch in another lifetime, I had some technical expertise that could contribute to our team effort here. Together, we employed MDD in order to forge a set of database tables that articulated the requirements for our new scheduler package. Initially, this metadata only described the individual processes that needed to run, but since MDD gave us a chance to visualize our ideas, we saw a chance at enhancing our job scheduler. Among various increments to our design, we created additional metadata that organized the processes into groups, so that jobs were essentially “process buckets” with similar start times and settings:
Since we had become familiar with employing MDD, the design phase went as well as we had expected…but the challenge here was the implementation. With only a few days to prove our case, we couldn’t create a failsafe program using a conventional programming language. Instead, it would have to be something a bit more ‘dirty’. So, imposing a crunch period upon ourselves, we worked into the late hours in order to build a Korn shell script framework that would accomplish the task. We eventually finished the prototype, and as our demo date approached, we crossed our fingers and hoped for the best.
Unfortunately, the demo did not proceed without a hitch, and there were a few bumps during our presentation. (On the plus side, we did learn that Korn shells are not consistent across all variations of UNIX, and some versions of UNIX are definitely worse than others.) In the end, though, it wasn’t important. When we altered the value of a job’s frequency, it would sleep and awake at a different rate. When the managers got involved and altered the value of a job’s inbox directory, it would attempt to load files from the new directory instead of the old one. After watching values change in our clearly marked tables and then consequently observe the different behavior from the scripts, managers began to nod in approval, and in that moment, we knew that we had finally planted the flag of victory into the ground. It then became obvious to everyone how these metadata tables could not only be quantifiable representations of a design, but they could also become rudimentary control panels for involved processes. Whether in the form of scripts or executables, processes could be designed and controlled through the very same set of metadata. It was a clear win for metadata-driven design.