There's a good discussion between Jean-Jacques Dubray, Doug Purdy, and Charles Young about if/how Oslo relates to MDA, MOP, UML, SOA, metamodels and a number of other high-science concerns related to modeling. I'll leave those discussions to the experts and too be honest I tend to look for the nearest exit when a modeling discussion goes meta. If it goes meta meta  (and it almost always does) I take out a bottle of Percoset and a hammer and spend the ensuing hours debating which to apply to my head. Eventually everyone agrees to disagree, they with each other, me with myself, and we all get back to the business of solving customer problems.

This is not intended to diminish the importance of these perspectives and concerns or clarifying Oslo's relation to them. They are a vital part of the discourse but, you won't find them here. They are not the droids I'm looking for. The droids I am looking for are shared notions of some very concrete, non-meta issues the first of which is: What Does Oslo Mean by Model-Driven?

What Oslo Means by Model-Driven: Part I

There is certainly an established cadre of model-driven * efforts in the industry and I'm not attempting to redefine anything and if after discussing Oslo you have suggestions for better terminology PLEASE send them our way. For the purposes of this discussion we'll focus on Oslo's notion of a Model-Driven Application. This notion focuses on solutions where the majority of application behavior is described in models that are consumed and executed directly by a runtime. At this point it is very tempting to try to define what we mean by "application", "behavior", "models", "directly", "executed" and "runtime" and while we will get there I'd rather not go directly down that rabbit hole and instead go through a couple concrete examples of model-driven systems. Hopefully, through some examples, a shared understanding of Oslo's notion of model-driven applications will emerge.

So, let's start with an example of a model-driven application that all of us use every day and that many of you are likely using right now: an HTML browser. From an Oslo perspective, the HTML spec is the Model Schema, an HTML page is an Instance of the model, and your browser is the Runtime. The browser consumes the HTML model instance to drive its behavior.

There are a couple aspects of the model-driven nature of HTML and browsers that you could argue have contributed to its wild success and the resulting growth of the WWW. First, the declarative nature of HTML instances lends itself to tooling. It's certainly not perfect but the rapid explosion and endurance of WYSIWYG HTML editors is evidence of this. Once these tools arrived on the scene you quickly saw a distinction emerge between "HTML programmers" and "HTML designers" and distinct tools to address their unique concerns. An HTML programmer's principal way of interacting with the model is through HTML text which Oslo would call a Textual Domain Specific Language. That is, the HTML syntax is a DSL for defining a web UI. An HTML Designer's principal way of interacting with the model is through a graphical, WSYWIG tool which Olso would call a Visual Domain Specific Language. Today, the HTML ecosystem provides a broad range of Graphical and Textual surfaces over HTML that are targeted to specific roles and, depending on how well the tools comply with the model, instances of HTML can flow between tools/roles as necessary. Here's a picture mapping these aspects of the HTML domain to Oslo terminology:

Another important characteristic of HTML’s model-driven approach is that the model instances are consumed directly by a runtime, in this case, a browser. You don’t (typically) generate code from HTML and then compile and deploy the code, you just deploy the HTML. A key benefit of this approach is flexibility. Need to make a change? Open the instance in your tool of choice, make the change, hit save. Change made and deployed. Of course if you want/need greater change management you can lay in all manner of source control, ALM, and governance systems and processes to provide those services.

At this point many of you may be thinking something like "that's not at all what I thought you meant by model-driven" or "that's certainly not what I mean by model-driven" and I think that's a basis for a great conversation moving forward. It's early days and just as we're looking for feedback on the bits and architecture we absolutely could use constructive feedback on how we describe their value, intended use cases, target customer, and longer term strategy. In part II I'll take a stab at mapping some other examples of model-driven applications into Oslo terminology.