Sorry to be missing-in-action again.  But, my daughter's end of the school year, vacations and work seem to have gotten in the way of blogging. Well, I'm back ... :-)

The topic of this post deals with creating a "good" model - and the need to combine domain AND modeling expertise to accomplish this.   Individuals with either kind of expertise, working on their own, will not define a "good" model - since each lacks the experience and knowledge of the other.  In addition, a "good" model typically requires multiple iterations. The first pass design should be considered solely as a prototype for evaluation and refinement. At least one more design pass is usually required to obtain even a reasonable model.

In the book, Framework Process Patterns, Lessons Learned Developing Application Frameworks (Addison-Wesley, 2002, ISBN 0-201-73132-0), Carey and Carlson discuss this development approach as the pattern, “Where’s Mr. Spock When You Need Him?” or “Domain-Technical Cross-Team Communication.” They say: “[D]evelopers need in-depth information about the domain functions for which they have responsibility. The earlier this information can be transferred, the less likely that … errors will be introduced, and those errors that are introduced will be less costly to correct."

Another valuable guideline from the book is to consider areas where the domain experts disagree or where their answers are “it depends” to be areas for possible extension and customization. Carey and Carlson discuss this under the heading ... "It Depends" (aka "Identifying Customization").  The intent of the pattern is: “To find potential extension points (points of flexibility …) that have been missed, … [ask] leading questions and …[listen] to domain experts discussions and arguments. “ In the pattern solution, Carey and Carlson recommend that you “listen for key phrases (for example, ’It depends’) that indicate the need for customization.  Listen for domain experts arguing. Often the points of contention are extension points.” 

I have used both of these approaches and can testify to their value!  It is great that Carey and Carlson documented them so succinctly!

Now, after having extoled the wonders of cross-group (cross-model and domain) collaboration, I have to point out some downsides ...  the terminology that both groups use is usually quite specific.  It is always a good idea to consider the terminology of the individual domains but also to generalize and abstract it for reuse and extension. In order to correctly capture abstractions and concepts, it is usually necessary to get past the specific terminology and constraints of a single domain.

A case in point is the use of the term, “computer”.  In some contexts, it is a specific entity that that has a processor, disk, memory, etc., whose piece parts are contained within a physical chassis.  In other contexts, it is solely virtual (just a logical entity providing “compute” capabilities), such as a virtual machine or a “grid computer”.   If your model reflects a “computer” as strictly a physical entity, then another term must be found for the virtual system.  In addition, one must deterministically know when an entity is the computer or the virtual system.  Unfortunately, this answer usually depends on your perspective. The answer could be different when examining the system from the perspective of the operating system (with internal knowledge) versus as a user.

Then, there is the secondary problem of terms with multiple or ambiguous meanings ...  Unless you have a very flexible tool, users of the models will quickly tire of trying different queries, against different type hierarchies, searching for their concept of interest.  Always consider this in defining entity names!

I need to come back to the iterative aspects of defining a model, for a bit ... and caution against the “big bang” approach to modeling – where everything goes into a model at once.  Iterative design suggests that you start with “what you know” – such as using operational observations to drive the general abstractions and specific subtypes of a model design.  This design can then be refined and tested.  The results of each iteration influence the follow-on work.  For example, one could indicate the desire to include organizational data in a design by creating a basic namespace and generic abstractions. In some work that I did, this was accomplished by defining an "Organization" namespace, and an abstract OrganizationalEntity (clearly indicating that the type is still in development by the use of meta-data, isExperimental=”true”). Then, in a later iteration of the model, sub-elements and sub-types were added to give substance to the type.

As part of the iterative process, it is very valuable to review a model outside the team that defined it (it is especially valuable to talk with customers), learn from mistakes and then update the model design.  This should be done at least once, but ideally until the only feedback is that "this is an excellent model". :-)  When doing reviews, put focus on the top of the model hierarchy - since that is where extensions will occur and where key conceps are captured.  However, the leaf entities are certainly not exempt from review and refinement. In addition, always try to use/query the model as part of the reviews, and try to extend it.  This really helps to highlight errors, ambiguities and missing semantics. 

Andrea