[Do data modelers produce better entity models than OO designers?] 
RJLRef: $PH/OMG/uml2mdaCritique_gb050420.txt

>From omg-list-errors@amethyst.omg.org  Wed Apr 20 10:09:14 2005
>From: "BERRISFORD, Graham" <graham.berrisford@atosorigin.com>
>To: adtf@omg.org
>Subject: Two objections to OOA&D - provocation

BRIT: Analysts can/should/must factor back-end "business services" out of
use cases. That is both old-fashioned best practice and modern best practice
(cf. SOA). And they don't need any diagrams, UML or other, to do it.

SWEDE: OK, that's your procedure, I prefer to use the old fashioned (UML)
way of designing systems, and it makes it a lot easier if you intend to
follow the RUP process all the way. 

BRIT: Unless you wisely modify RUP to include business service interface
definition. And, second, if a data model is needed, then it should be a
primary artifact and part of the "logical view" as early as possible, not an
afterthought.

SWEDE: In short I do agree with you. The data model is important and when it
comes to implementation the parts that should be implemented should also
have been database designed first. This will however be made in a
iterative/incremental approach and "mainly" as a result of the object model
and in particular the business objects discovered. 

BRIT: Aargh! This is a daft round-the-houses way to reach what remains vital
for much enterprise application development - a normalised definition of the
data that is needed for actors to execute business processes (supported by
use cases at the system boundary). Saying the data model is or should be a
side effect that drops out of the "objectmodel" (and in particular the
"business objects" discovered) is at the root of many confusions,
difficulties and time/cost/quality issues in enterprise application
projects.

In a natural requirement-driven methodology for enterprise applications, the
data model should come before any kind of object model showing operations. A
data model follows naturally from encapsulating system behind an I/O data
interface. Teaching people to draw a "business object model", "conceptual
model" or "domain model", when you really want them to analyse the data in
the system's I/O interface and draw a data model is part of the problem we
have with projects, not part of the solution. It encourages people to draw
fanciful models of the "real word" rather than define the data the system
must store and provide to support business processes. Let us call a spade a
spade. The damn thing is a data model!!!

SWEDE: I had the feeling that you would have that kind of comments on OO and
data modeling :-) I am also familiar with the problems you described but
somehow we manage to solve them one by one.

BRIT: I could wish you didn't have to solve them, because your
methodology/process prevented them. Alistair Cockburn remarked (last time I
looked) on his web site that he finds data modelers produce better entity
models than OO designers - which is another way of making my point. Data
modelers know more clearly what they are doing, and how to do it, because
their task is the right one at the right time in the process.