Monday, August 30, 2010

Middle Distance Ontologies -- an Intermediate Summary

I've posted a number of design exercises using middle distance ontologies including:

At this point I think it's worthwhile to look back and see what, if anything, is different and useful about the middle distance approach.

What struck me most as I was thinking through the examples was how similar the process was to object oriented class design. Using opaque identifiers allows moving a clump of stuff (attributes, identifiers, functionality, behavior) to another class so that the objects in the system correspond to objects in the world. They can then be analyzed as a coherent whole (aka modularization). Pragmatically, such partitioning allows developers to become intimately familiar with how the stuff within that partition operates and evolves over time, permitting them to develop a high level of fluency in the domain.

A key component of this approach proved to be the use of the criterion what could change to drive the splitting off of the chunks of stuff. As such, it is an extension to/refinement of existing design techniques rather than being a replacement for them.

So, how does middle distance thinking extend current techniques?

Extension to DB design: A focus on "objects in the world," rather than just cardinality, results in a more fine grained partition of the problem space. All things which are one-to-many or many-to-one are necessarily distinct and have different potential rates of change, but sometimes things which are one-to-one are also distinct, and should be separated to accommodate future change.

Refinement of OO design: middle distance ontologies are problem space oriented rather than software oriented. As such, it is less concerned with factoring out the appropriate superclasses than OO designs. This is because software design criteria that push such refactorings are "within the system" rather than "in the world." There is nothing in the middle distance approach that pushes common functionality up to a common implementation.

One other aspect of the middle distance approach is that it allows you to pull attributes out of the design and hide them behind the opaque identifiers. This modularization allows you to change the definition of such things as validity as your knowledge of what constitutes validity in your problem domain changes.

In summary, I think the middle distance approach is useful as a design principle, but is not a distinct design technique per se. Assessing its utility in practice must await an opportunity to apply it to a real world problem.

Monday, August 2, 2010


Andy Siegel of Genzyme, Hemant Virkar of Digital Infuzion, and I gave a talk, ArchiMate as a Communication Tool in Launching an EA Effort, at the Open Group's Boston Conference. It discussed our experiences using ArchiMate as a communication tool for rolling out an EA Effort at Genzyme.

As I've mentioned before, I have found ArchiMate to be a practical, useful, framework. This presentation delineates some of the reasons why I came to that conclusion.