When we initially planned to overhaul the product data system, we placed our entire focus on the servers that would constitute the distributed architecture. In other words, we had only been concerned with the layer of machines that belonged to our middle tier and back tier. It had been assumed that the client applications would not need to be overhauled, and the stakeholders that used those applications (i.e., the users) would be satisfied with a simple port of the existing GUI application. This GUI application (which was known as Product Master) had always made direct calls to the database, and its team had maintained it that way for many years. Why change it now? However, there were the steadfast few of us who had pushed the idea for our architecture (along with metadata-driven design) to this road marker, and we were not going to be satisfied with letting it rest there. From our point of view, a simple port of the client application would be a travesty for a number of reasons. One simple reason was that in order for the application to take advantage of the new system’s functionality (i.e., locking fields), Product Master would need additional code changes to make use of it. Also, this new version of Product Master could become another beneficiary of our nascent MDD method. Most importantly, though, a GUI client application should almost never bypass existing middle tiers and server tiers; that scenario practically guarantees code redundancy and conflicts.
Initially, there was some resistance from the Product Master team, but since we steadfast few had already built momentum and had the majority of the stakeholders behind us, we eventually got our way. Our planned update was a bit of a culture shock for the Product Master group; they had operated in the same manner for decades. For the users, these new proposed GUI forms and controls were a bit daunting at first, but they were actually eager to learn about a new way of being more productive. Within a short amount of time, they embraced these functional enhancements. The Product Master development team, on the other hand, started a little more reticent and turned a bit recalcitrant. (In their defense, it was a complete shock for them, given that it was a 180-degree shift from their usual direction.) They were not eager to relinquish direct access to the database, and they had never used a homegrown API before. However, after we got the chance to create a mockup of a client API, their grumbles eventually disappeared as they realized that this client API would free them from maintaining the banal routines of CRUD operations. Instead, they could specialize by focusing solely on Product Master’s interactive features that would assist our users. After we had finally won that battle, it was time for the coup de grâce to their old habits: an introduction to metadata-driven design.
Since the Product Master application would use our client API in order to retrieve and save data through the middle tier, it would need to become compatible with our overall design and its potential actions (like locking a field, for example). However, given that it was a client application, it had special requirements of its own that were only for its users. As an example, managers had requested more detailed security on the forms’ controls (i.e., certain grayed out boxes and menu items for certain novice users), and in this next edition of Product Master, it was going to be expected. Our small team then introduced the MDD method to the Product Master development team, and much like with our own beginning, we created a schema with metadata that represented their domain values. In this case, though, these values represented the desired functionality for only their client application, including the security for various forms’ controls. It wasn’t long before that schema and its tables were represented by a set of XSD files within their Visual Studio project, and by synchronizing those XSD files and their respective database tables, it would eventually become one of the central pillars to the Product Master application. They would also eventually experience similar results as our group, with less code changes and more control in the few made. Again, it seemed that MDD had proved to be a tool for circumventing all convention, much to the benefit of all involved.