At this point, we had established how this metadata could be the condensation formed from the vapor of our thoughts, especially when it came to the overall design of the model and functionality within the architecture. By molding both the tables and the files through a series of iterations, we were routinely applying a system that seemed to work methodically and successfully. At this point of the design, we were optimistic enough to start discussions about another important aspect of our distributed architecture: communication. Namely, how were the various processes (which were executing on heterogeneous systems) supposed to communicate with one another? Almost a decade ago (when these design sessions occurred), web services were not as popular as today, and so they were not given much consideration. (Due to the volume of data that was expected to pass between machines, web services were not favored as an option anyway.) Since there were no cheap options available for use and since we were limited by a miniscule budget, we decided to create our own mechanism for communication. And how would we do that? To that general question, we again gathered around the runes of our metadata and peered closely in order to decipher the needed answer to our inquiry.
Since XML had already been used as a markup language both to showcase the metadata and to help specify some of the project’s needed functionality, a few of us proposed that we nominate it as a candidate for a homegrown protocol. At the time, XML and JSON (along with other contemporary standards like REST) had not yet become normal options for communication, but we pushed for such an adoption. Some senior managers had concerns, but for the most part, they were very intrigued by the idea. We just needed a thorough example to make the final argument. In order to make the argument rock solid, we would have to incorporate all of the other changes made to our metadata within the past few weeks. For example, we had added other important points to our security metadata known as ‘fields’; now users could lock the specific field of a specific product, so that no other user could alter it. After a day or two of consideration and playing with various options, we created the first iteration of our communication protocol:
<?xml version="1.0" encoding="windows-1252"?>
<Title validate=”check_max_length”><![CDATA[This Is an Example Title]]></Title>
Of course, we knew the final implementation of our communication layer would need to incorporate other complexities (like an intelligent XML parser and a homegrown TCP/IP networking layer), but those components were part of the actual software implementation. Here, we simply wanted to demonstrate how we could utilize the metadata as a basis for our communication protocol, and we had done so. In the months and years to follow, we would be pleasantly surprised to learn that this choice would pay in dividends. In the seven years since the delivery date of our product data system, this protocol and its supporting libraries have been flexible enough to never require any code alteration. By relying on the metadata, any required changes have always been made to the numerous tables and files of our metadata, but the code has never needed such. In truth, we would learn how this pleasant surprise would become applicable to many other subsystems based on our metadata-driven design. Would you believe me if I said that the changes needed for our product data system (and its distributed architecture) have increased by 50% each year, but the actual code changes to our system have dropped by 20% each year? Even though MDD does require some level of commitment, there are quite a few rewards which can be returned from such an investment.