Back to writing about modeling guidelines .... sorry about the long delay in my posts, but I got caught up in some standardization work that you will be hearing about in the next few weeks :-).  I want to talk in this post about scenario-based modeling and how we bring our preconceived notions of the world into our models.

The decision on how to model something (an individual object or a full domain) is heavily influenced by the scenarios that drive the design, and how we approach and understand the problem space.  My strong advice is to fully consider both the scenarios and our own prejudices. If you focus too much on product scenarios, you typically miss the “big picture” since product teams only have a limited set of scenarios in scope. But, if you focus too little on the scenarios, you may create a great model that is not useful to the product teams. And, if you read all the scenarios, with a filter based on what you think that the model should be, then you only see this one answer.

In his book on "General Systems Thinking", Gerald Weinberg discusses the multiple views of a problem space:

1. "Get a ‘complete’ view – one broad enough to encompass all phenomena of interest – so we are not surprised; 
2.  Get a ‘minimal’ view – one that lumps together states that are unnecessarily discriminated – so we do not overtax our observational powers;
3.  Get an ‘independent’ view – one that decomposes observed states into non-interacting qualities – so as to reduce the mental effort required.”

An examination of all of these views of the modeled environment is needed in order to determine the states, qualities and entities of interest. This is much more than analyzing scenarios, but deals with understanding and abstracting the “things” in the environment to create the correct entity definitions. And, it highlights defining the entities only after you have done this analysis.

I have been criticized that this approach is "boiling the ocean", looking for big solutions when little ones are needed.  I totally agree that it is a bad idea to model beyond current knowledge. But ... it is defnitely a good idea to examine the problem space broadly, and anticipate extension and the support of less restrictive scenarios (which will certainly happen at a later time).

There are some interesting examples of how extensibility and future changes can influence a design. For example, most of us view software as executing on a computer.  In fact, it is tempting to tie software to the computer so tightly that they are inseparable (actually embedding the software’s data as sub-elements of the computer’s definition).  But, there is an interesting world of agent-based software that makes those assumptions problematic. Agents execute at different times in multiple locations, carrying along their state and data as they move within a network.  Although physically it is true that the agent stops executing on one computer and then is “reborn” on another, logically that is incorrect – since the “same” agent is reborn.  Modeling for the standard scenario of strict deployment on a single computer makes the agent-based scenario cumbersome. However, anticipating less restrictive scenarios enables evolution of the model versus its rejection as cumbersome or incorrect.   

So, it is a good idea to think broadly about the entities to be modeled, and then to make reasoned choices in your design (versus making uninformed choices).  Larry Page, in an interview in Fortune (May 12, 2008), said "If you look at the people who have high impact, they have pretty general knowledge.  They don't have a really narrowly focused education."  Now, I admit, he was talking about innovations that change the world - but model that are supposed to support a changing environment need these same principles of being based on general knowledge and broad thinking.

Well, I will end on this very philosophical statement :-).  More on this in the next installment.

Andrea