So, assuming that you’ve read all the previous posts about metadata-driven design, you might ask how one goes about putting MDD into practice. I’m glad that you asked! Of course, there’s a good deal to write about such a subject, but at first, I’ll start with something more familiar to programmers. As I’m sure that any reader here knows, there are a number of methodologies in place to build the implementation of a given software design, and one of the most popular and effective methods is Agile. It’s a supremely flexible way to handle the various, dynamic obstacles thrown at software development, and you’d be mistaken if you’ve never even considered it as applicable to your own environment. However, despite its popularity with software implementation, Agile is rarely ever considered for one important aspect of software: design. As noted by Andrew Binstock in a recent piece for Dr. Dobbs Journal, the authors and proponents of Agile have never written about its application to design. Why is that? There are probably a number of reasons, but personally, I think that it has been a conundrum due to an important question: to what are we applying the Agile method when it comes to the subject of design? We need a medium to mold our ideas…and, in this case, I think that the potential answer is metadata.
In the case of software, the goal is to build the implementation; in the case of software design, the goal is to construct an architecture. In the case of software, the medium which represents and constitutes the software is the code (or, if in its early stage, UML and/or pseudocode); we can refactor the code as the requirements change in real time. In the case of software design, I nominate metadata as the medium which represents and constitutes our ideas; we can refactor the metadata as the overall requirements of the project change in real time. (In this case, I’m referring to metadata in a general sense, referring to both data that describes an application’s schema and the configuration data that powers the processing.) By having a palpable representation of the architecture, we can apply some of the same methods that create a refined code base in order to craft a sleek design. Does that sound a little crazy? Maybe a little bit.
However, I don’t think of it as that crazy of a suggestion. In our group here at Barnes & Noble, we use this type of method whenever we initiate a project of any significant scope, and during the design process, we apply similar practices that are also found in Agile. Instead of paired programming, we assign a stakeholder and a designer/analyst together, and together, they will draft designs of the application’s metadata. We then have iterations of reviews that look to refactor these preliminary designs, and each person has a certain degree of accountability for the molding of this metadata. Like actual software development, sometimes the information needed for the architecture can only be obtained through a slow trickle, but with another version of continuous integration, we abstract the necessities of new requirements and then attempt to fit them into the metadata which is already in place. (Surprisingly, we have found numerous instances where one entry of metadata can be multidimensional, providing a functional direction to several applications layers at once.) Of course, there are other examples, but it’s fair to say that Agile can have a role in software design. In addition, by using metadata as our medium, perhaps we can even apply some of the tools from lean software development; since we’re dealing with something quantifiable, maybe we can analyze our own design process in order to improve it at a later date. So, do I still sound crazy? Hopefully, at very least, I sound a little less so.