RE: Needs to know everything; was: RE: [AM] ZZZ

(Responding to Paul)

>  EVERYONE NEEDS TO KNOW EVERYTHING!
> 
> > (Dagna)
> > I think that this is one of the problem areas - the dba may 
> not see it 
> > as 'traditional' or 'agile', but as 'risk'.
> 
> (Paul)
> That's fair enough, as long as all risks are evaluated 
> fairly, including the risk of being unable to respond to 
> change in a timely manner when it needs to happen.

DG: One way of reducing that risk would be to have a dba involved in the
project (in my youth, I made sure my grandmother was well up to date in the
latest egg-sucking techniques... <g>). While all the dbas I have ever
encountered have been obliging, flexible, co-operative team players (was
that a snigger at the back?), some tend to refuse everything or set up great
fences to be got over, to stop people messing up 'their' data. Or so I am
told. ;-) But if you can get them involved (and get over the two standard
responses - "you should have involved me sooner" and "why are you dragging
me in? I don't need to be involved yet!"), then 'your' data is also 'theirs'
- which helps a lot. If this sounds like I am anti-dba - apologies, I am
not, and I do appreciate how much they have to do. But I have also suffered
from their attitudes.

(Paul)

> Agreed.  Programming used to have the same problem
> of change being extremely painful, and one of the first 
> solutions was to encapsulate the data and put it and 
> behaviour behind interfaces, so that the ripple effect was 
> stopped.  That's now standard in programming, but not yet in 
> database.  I think that must be the first step toward 
> agility.  Yet it won't be as easy as it was for programming, 
> because 'we' didn't have data migration problems; 'you' have 
> always dealt with that for us.  OTOH 'you' have 'our' 
> experience to learn from.

DG: This  one took some thought. And will do for some time, I think. 

First thoughts - if it has been encapsulated, then surely that works both
ways? Answer - no, it almost certainly doesn't. If a data change is needed,
then encapsulation can protect those apps, calls and so on that don't use
the new structure (assuming that the old one is still supported). If the
underlying data remains the same, and maybe a new index or whatever is
added, or a table split into master and detail, then the outside world needs
to know nothing. But if the format or contents of a field changes, or the
field is no longer used, or a new one appears, then there is an impact on
the outside world. Especially if it is something like the infamous 'name
field split' scenario, which may require a change to the way the apps
present the name to the database for insertion and update.

Second thought - how about views? But they are a form of encapsulation or
the underlying tables, and the same applies.

Third thought - there is an amount of pain that is going to occur somewhere,
and 'you' pushed it 'our' way? That was mean of you. ;-> (See also Function
Point Analysis, if you ever can't sleep. Something that works (I have seen
it work), but makes "BDUF incorporating every little thing that anyone may
want to consider for the next ten years" look like prototyping... But it is
a way of measuring the amount of work needed to achieve a design, and (it is
a long time since I read the book, and I forget the details) if a set amount
of work has to be done, then I guess it gets done somewhere.

I am going to ponder this one some more. A few train journeys, glasses of
wine, sleepless nights (not that I *intend* to  lose sleep over it, but
those nights  when I can't sleep anyway), then I will see if I can come up
with something to float at dm-discuss, and bring it back here.

> 
> > And we are back to the need to come up with a generic, flexible and 
> > very granular design very quickly, at the start of the 
> project, which 
> > is why that great, monolithic, 120-entity Logical Enterprise Data 
> > Model, with all its definitions and formats and 
> cross-references and 
> > supporting stuff, is so valuable.
> 
<snip>

(Paul)

> There's also a question as to whether there's any reason
> to have all those 120 entities in the same database or
> whether the domain concepts would be better partitioned
> into subject areas - I've seen both approaches but don't
> know enough to say which approach is best in what
> circumstance.

I keep them together, because otherwise the overlaps are a impossible to
keep track of, but break them into subject areas. This being the Enterprise
Logical Data Model, it should reflect the underlying data structures of the
Enterprise, not of any individual application or database. The idea being
that any app or db can be replaced without affecting the ELDM. (That's the
theory, anyway.) It is also (I think, probably) a level of abstraction up
from any DB logical models. Including any warehouses you may have cluttering
the place up, so any attempts to use the ELDM as a db design without a close
review and (likely) expansion should be resisted. Firmly. To the last drop
of blood of the person making the suggestion. (As you can see, data
architects are a friendly, approachable bunch of people.)


(Paul)

> 
> I think this is about the right time to mention the 
> differences between Data-rich, Behaviour-rich and 
> Control-rich systems.  Programmers will already be throwing 
> up their hands in horror at your suggested approach, and 
> maybe I can explain why, before anyone starts casting aspersions  ;-)

DG: Yes, please. 

(Paul)
 
> In a data-rich system, the structure of the data drives the 
> problem, and though programmers would start with an object 
> model, starting with a data model would give perfectly 
> adequate results.  For behaviour-rich systems, the behaviour
> of the objects is significant, and if we are to have any 
> reasonable chance at building the system economically 
> and in a way that can respond readily to change, then
> correct apportionment of behaviour to objects is paramount.
> the data needed is determined by the behaviour needed.
> In control-rich systems, behaviour is also important, but 
> we have the added complication that the behaviour of 
> objects changes significantly with time.
> 
> In reality, encapsulation of the data will save the day,
> we hope, because the persistence layer can map
> between the business object representation and the
> underlying data representation, should they need to 
> differ.  Yet awkward mappings can be performance
> hogs.
> 
> (Phew - did I smooth all the ruffled feathers?)

DG: I hope this doesn't come across as a really stupid question... I think
it might, but please  remember that I am a poor, confused, data dinosaur.
Ahem.

How do you encapsulate the data when you then tie it up into objects? Can
you split it out under those conditions? Or have I totally missed the point
of objects? (I am quite prepared to accept that I have, but the reference to
the object having behaviours seems to indicate that an object involves both
the data and the processes it performs or has performed on it, which is my
original understanding. Unless the object has no data. Help!)

> 
> > A thought about the problem - maybe data is not agile
> > because it is the trail left (or the framework needed) by the 
> > execution of business processes and policy - and the data 
> can only be 
> > as agile as the things it records. Which is often pretty staid.

(Paul)

> 
> That's probably not relevant - I can envisage cases
> where the same data is used by a 30-year-old core
> business dinosaur and an ultra-modern agile added
> value miracle (carefully displaying extreme bias ;-)  ).

The 30-year-old core dinosaur being closely coupled while the young
whippersnapper goes through the APIs? (Biased? Me??) If only - can the young
upstart access the 30 year old file system? Or does it get an extract and
build its own version? (Replication! Duplication! *Bad* agile thingy...
<eg>)

Dagna
Dagna Gaythorpe
Data Architect
International IT
> tttt COLT TELECOM GROUP PLC
> Beaufort House, 15 St Botolph Street,
> London EC3A 7QN
t   (+ 44) 020 7 390 7896
f   (+ 44) 020 7 947 1176
e [email protected]




*************************************************************************************
COLT Telecommunications
Registered in England No. 2452736
Registered Office: Beaufort House, 15 St. Botolph Street, London, EC3A 7QN
Tel. +44 20 7390 3900


This message is subject to and does not create or vary any contractual
relationship between COLT Telecommunications, its subsidiaries or 
affiliates ("COLT") and you. Internet communications are not secure
and therefore COLT does not accept legal responsibility for the
contents of this message.  Any view or opinions expressed are those of
the author. The message is intended for the addressee only and its
contents and any attached files are strictly confidential. If you have
received it in error, please telephone the number above. Thank you.
*************************************************************************************

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------