I often find myself struggling to define what I do. "Solving world hunger" (in the "world" of common models and ontologies) - is one description, although it is a bit vague and altruistic. I had a much easier time of it when I was a programmer.  Then, I said things like "I write FORTRAN code that does test scoring and produces mean, standard deviation and other statistics about a test’s results” (yes, it was long ago). Or, “I transforms UML classes into database structures" (more recent).  Now, I say things like "I worry about the broad abstractions that are needed to support business processes and business modeling in general."  Kind of like saying, "I think about general relativity to solve today’s 3-body gravity problems”. 

Programmers are lucky.  They get to work on specific features (certainly in the context of bigger problems and big product releases), but specific features none-the-less. Also, the output of the work (the code) is good if all the scenarios are supported and all the test cases run. The code is even better if the work is done cleanly, quickly and elegantly. It all comes down to the implementation.  There is a clean beginning (when there is no code for something or an explicit bug) and an end (when the product ships with or without the feature or the bug fixed). But, a modeler’s world is a bit messier.  They have to worry about semantics and meanings (and worse yet, finding a good word to represent the intended meaning).  And, the model should support future extensions and uses that haven’t yet been conceived. As for a clean ending – forget it. A model is never really done – if it is good.  We can always do more work to subtype it, extend it, etc.  (A bad model has an end when it is discarded and replaced.)

Instead of worrying about specifics, a modeler needs to be a bit of a Renaissance person - knowing about lots of things so that they can see patterns, abstractions and commonality through the differences.  I have heard people refer to this as “grey hair knowledge”. (And, I am convinced that you can have “grey hair knowledge” and still color your hair.)

So, what do I think makes a good model?

·         As simple as possible, and complete (Better not bigger, spanning the semantic space)

·         Consistent

·         Extensible and reusable (Designed to evolve and be used beyond original purposes)

·         Design tradeoffs well-understood and documented

·         Normalized (To a point)

·         Incorporating stable and well-defined concepts and semantics – Usually taken from other standards and models

·         Designed and encoded for interoperability and sharing of semantics – But not limited by a specific encoding (such as XML Schema or database limitiations)

And, what makes a good programmatic implementation?

·         Efficient and complete – Where “complete” means addressing the scenarios and test cases, without gold plating

·         Performant

·         Code reuse is goodness, but not a show-stopper

·         Well-documented and designed for maintainability

·         Normalized (As much as possible)

·         Incorporating well-defined patterns

·         Designed and encoded for a specific language and environment

At the end of the day, you should be able to have one good model and several good programmatic implementations – but the model semantics have to be right to be useable.

Andrea