🚀 go-pugleaf

In article <bksDpv1r1.qI@netcom.com>, bks@netcom.com says...
>
>[...]
>However, well defined taxonomies are not easy to come by.  The
>problem is that the taxonomy of the woman on the warehouse floor
>is *not* the same as the taxonomy of the guy in accounts
>receivable which differs yet again from the salesman, ad 
>nauseum throughout the customer's organization.  Each person
>chops up the flow of work in a different way.
>
>    --bks

Good point.  An endemic problem in software development is the inability to 
freeze software requirements, partially because the requirements are being 
driven by several different sources with competing goals and agendas and 
divergent ideas about what the end software product should be.  Requirements 
become overloaded.  In OO, sometimes it is just a philosophical difference on 
how to decompose the problem domain and sometimes people who must share 
information and bridge work flows really do have completely different 
perspectives that justify different taxonomies.

Usually it is because we aren't really talking about a single problem domain 
that can be solved by a single piece of software (with elegance, at least, 
and without shoehorning some unwilling users into the tool's paradigm, rather 
than supporting their work flow).  A few different software packages that 
break out each community's areas of concerns with well defined interfaces 
between them helps here, laced together with DCE or CORBA or an OO/RDBMS 
server (or whatever).  (The ODP concept of different perspectives on a single 
system: even though inventory control, A/R and sales all need to know about 
Acme Co.'s grapple grommets, they have *justifiably* different perspectives 
and that product fits differently into their scheme of things.)

Usually this isn't as much added effort as it sounds, because such division 
vastly simplifies analysis and looks like a win-win solution to the 
independent user communities (each gets it own goals and agendas attended to 
without detracting from others), a good chunk of code is common (especially 
DBs, GUIs, and other such conventional stuff), and except for naming 
collisions, it is fairly easy for different taxonomies to co-exist in the 
software if they must (usually each taxonomy ends up in separate software).  
(However, some techniques for object distribution make it difficult to in 
effect say 'these objects are really different ways of looking at the same 
object'.)

Another really tough part is getting people to agree where the problem domain 
segments cleanly into smaller problem domains (promotes turf wars) and then 
defining interfaces without dictating what lies behind the interfaces (by Use 
Cases, perhaps, with each community being a 'block'; unfortunately, some 
practioners try to magic up interfaces a priori without a first cut at the 
problem domain analysis).  Linkages between taxonomies are difficult to 
manage; taxonomies should be related only by information flow across well 
defined interfaces.

Using our cooked example, sales maintains an independent idea of what grapple 
grommets are and how they fit into a sales taxonomy.  When 500 of the 
beasties are sold, warehousing must know to take 500 out of inventory control 
and ship them to the receiver, and notify A/R for billing, again using an 
independent idea of what grapple grommets are in a warehousing/inventory 
taxonomy.  A/R then looks up things grapple grommets for cost, applicable 
discounts, shipping rates in the accounting taxonomy.  My mind boggles 
imaging trying to define a grand unified grapple grommet overloaded with all 
the attributes and operation each of these domains needs.  (And obviously, 
you need concensus at some level; each accountant cannot have her own private 
taxonomy.)

But still, it presents unique challenges differing from monolithic 
taxonomies.  (Which makes me think of, somewhat off topic, one of the more 
common recent damaging trends in software development: deciding on a 
distributed architecture a priori -- because somebody has just discovered 
CORBA or Java in a magazine article, usually -- and arbitrarily dividing up a 
perfectly monolithic architecture and taxonomy into a distributed one.  These 
are usually the same development teams that spend seven weeks defining 
interfaces between systems without even a fundamental analysis of the problem 
domain.  Whereas problems that beg for distributed architectures motivated by 
the nature of the problem domain are still being packed into a single 
software package while the end users fight over the paradigm to be adopted by 
the software.)

Even starting a spec with 'we require an application which' insidiously 
pollutes the analysis with implementation details, because it is not yet 
known that a *single* application best addresses the requirements, and the 
analyst begins with the premature assumption that a *single* taxonomy is 
required.

-- 
Brad Shapcott, Technical Consultant
Lockheed-Martin's Advanced Concepts Center
Ottawa, Canada (613) 592-8744 x227