So, what kind of metadata am I talking about, anyway? Generally, it means “data about other data”, which means nothing and everything without some sort of context. In one case, metadata can describe some kind of recorded data (i.e., length of data). In other cases, it can describe how data should shape and behave in an application (i.e., configuration files). For the most part, I’ll be writing about metadata which is akin to the latter type, but I might digress and take metadata to an odd place. I’ve been known to do that from time to time.
If you’re a developer (especially of enterprise applications), then odds are you’re already acquainted with application metadata that controls application behavior, whether it be through a .properties file in Java or an app.config file in C#. If you’re a member of management, you may be a user of enterprise software like Salesforce, whose Metadata API empowers users to customize their SAAS experience as needed. If you’re a programmer who has spent any time with C++ and templates, then you might remember Andrei Alexandrescu and his interesting efforts with template metaprogramming. (And, yes, you can make the argument that template metaprogramming isn’t a form of metadata, but I count it. So nana nana boo boo.) And if you use frameworks like Spring, then you’re dealing with metadata XML files, technically speaking, up your wazoo.
In other words, metadata is ubiquitous in the computing world, and it’s been around since the dawn of time. So, in the sense of merely being a driver of applications, there’s nothing special about it; it serves as a pidgin between the program and its user. However, the potential of metadata doesn’t have to end there. Why can’t it be used to enable conversations between systems? And, more importantly, why can’t it also be a language between people?
Truly, one of the biggest problems with building any sort of infrastructure is the hurdle of communication and coordination between people of specialization. In the case of software, developers and managers often find themselves not being on the same page, especially due to misunderstandings; after all, Scrum meetings are meant to address both circumstantial issues (i.e., the project’s scope has changed) as well as issues with goal alignment (i.e., developer thought ‘A’ when manager thought ‘B’). Is there a way to further enable this communication, in order to mitigate these issues of being unsynchronized? It will be my goal in future posts to show how metadata can serve as a language and as a contract between developers, software, and managers. Since I don’t have a better term for it yet, I’m going to designate it as metadata-driven design. I’ll expound more about the potential benefits of metadata-driven design in my next post.