Tim Mallalieu's Blog.

Just a PM's random musings on data, models, services...

On Models

On Models

  • Comments 4

This post is inspired by a number of posts that I have read in the last couple months and my experience in my current team when we talk about models and the enabling infrastructure. Some of the interesting posts that have made me want to post on this particular topic are Harry’s post on the code is model, and Alexander's post on elegance is not simplicity.

So what's my point?  I have a very specific view of models. The view is consistent with the MOF view of the world where there are different levels of model abstraction… one must first define a meta-meta-model (say MOF) and then one can define a meta-model in terms of the meta-meta-model (say UML) with which one can define a concrete model (say some domain model for a particular solution) and finally one can define an instantiation of the model (say the M0 or data level). In this view of the world the core scenarios that we are concerned with are enabled through model to model transformation. Let's think of some:

  • Round-Trip Engineering – model-model transformation between data/objects and model, consider generative cases around code or schema.
  • OR Mapping – model-model transformation between two perspectives of a model at the same level (the data/object level).
  • BPM – model-model transformation across perspectives as well as levels of model abstraction (the business analyst perspective at the model level, the developer perspective at the model level, the developer perspective at the data/object level).
  • DSL’s – DSL's define leverage model-model transformation across many levels typically within a “domain-specific” perspective… the data perspective with logical and physical data models, DDL and SQL seems like a reasonable example.

The interesting thing that I experienced recently is that so many people get hung up with the perspective that they feel is “right” that they lose sight of getting the meta-model and the meta-meta-model correct. In fact, it gets worse… people focus on the perspective and fail to realize that if there is a common meta-model or meta-meta-model depending on the level where one is arguing then there is likely a meaningful model-model transform between perspectives and even levels of model-abstraction so they are violently agreeing on the need to express the same thing just through different lenses if you will.

So let's now introduce some of the sentiment from Alexander’s post on simplicity. I put to you that the most interesting term (in the context of this rant) that I stole from Alexander’s post was when he said that things must be approachable. Simple is too overloaded, even with the wonderful qualities of the term that he describes. Ultimately a model is contextually approachable given the viewpoint and concerns of the consumer… for example I could see many different model perspectives and levels of abstraction for every intersection of interrogative and role in the Zachman framework but they could all be for the same solution within a given Enterprise. It would be nice if these perspectives and levels of abstraction were transformable and traversable and you could indeed do like John Zachman says… loosely paraphrased “you do this, you do this, you do this” (walking down the levels) “and then you hit compile”. So my takeaway is that a model, above all else, must be approachable and that is specific to perspective and concern of the consumer.

Well, duh, I am sure anyone who reads this and is remotely familiar with models would say that this is obvious but we do not live in a world where we have done this. We are approaching it now with the acknowledgement that DSL's help us focus to domains and concerns but in general we still live in a world where the conceptual model is out of date as soon as you print it and put it up on the wall and you maybe are able to view a visualization of the code in some round-trip engineering tool. Further to the point, and consistent with Alexander's observation, we have not done a good job of separating the underlying machinery that enables the realization of one particular concern/perspective intersection of a model from another. Alexander used the J2EE app server as his example but the examples are all over the place.

One area that I have been thinking about a fair bit recently has to do with data models, persistence frameworks and ORM. There are folks who would love to have an ORM framework that is baked in a manner that they can define an object and then get the persistence mechanism and persistent store automagically implemented and deployed with the app. Others want an ORM framework where they can think purely about objects and have inline annotation of members that define the mapping to some persistent store. Other folks want first class conceptual models which form the basis for code generation and legacy mapping (or store generation) and finally others (and the area I am most interested in) want abstract virtualizations of persistent resources and may or may not have objects that sit on top of these virtualizations. All of these folks have models, some are explicit some are implicit… some folks have models purely at the 0 level of model abstraction, some have higher levels of abstractions, concerns and perspectives. Can we actually build a single solution with the requisite machinery that can enable the realization of all of these concern/perspective intersections and resulting models without compromising the approachability from a particular group? Seems like a hard thing to do.

Leave a Comment
  • Please add 1 and 4 and type the answer here:
  • Post
Page 1 of 1 (4 items)