Years ago, my group at Barnes & Noble was responsible for retiring an old legacy system (and its corresponding applications) that was crucial to our infrastructure. Namely, it was the system responsible for all of our product data. At the time, the legacy system was a leviathan that was composed of a number of different tools and languages, held together by duct tape applied over decades. Since J2EE was the new swaggering technology at the time, the preliminary train of thought was to simply port all of the code to Java, and then we would give it shape with the assistance of some middleware (like Weblogic). Some of us, though, knew that this moment was a rare opportunity to direct the course of a system for the next few decades, and it was not something into which we should simply rush. Despite the cacophony from certain parties that urged haste, we decided to take advantage of the moment in order to prepare ourselves for the future.
Since this legacy system was responsible for product data, it had quite a few obligations. Its duties to our product data included reading, saving, validating, transforming, securing, auditing, and reporting (among a few others). This outdated system’s responsibilities were spread out among a number of subsystems, each implemented on a different platform and technology and each carrying a fair amount of redundant functionality. Not surprisingly, applications of this legacy system used no metadata and had all important app data hardcoded. So, the bar was low enough that literally anything was an improvement. However, we didn’t want just a few simple enhancements. Sure, the first thought was to consolidate these subsystems onto one platform and technology. Also, we assessed what metadata would give the new product system a significant degree of flexibility. However, that wasn’t enough; we wanted something more from this new system.
After making these initial improvements, we started to imagine the needs of this system for projections that were years ahead. Currently, the system performed asynchronous and scheduled tasks for its users. However, what if the system needed to become more available and reactive to its users? What if the scope of the system’s data were to expand on a more aggressive schedule? How could managers respond to business needs quickly and without constant coordination among the developers? Could we reduce the amount of time that was spent constantly fixing the system, which seemed to happen with every release of the legacy system? As we scrutinized our precursor design, we began to find patterns within our initial metadata, and these abstractions became the metadata for a whole new generic system. Even though we had no term for it, it was then that we started to actually practice metadata-driven design. In the next post, I’ll provide an example of our first foray into this odd yet rewarding method.