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

(responding to Dagna)

 EVERYONE NEEDS TO KNOW EVERYTHING!

>> (Paul)
>> I think what may fall through the cracks here are the cases where 
>> the DBA gives explanations that are valid in the good old 
>> fashioned traditional environment, but no longer hold true in 
>> the agile world.  I guess if the DBA doesn't know how to do 
>> it in an agile fashion we are stymied anyway - but the 
>> ability to say there's another way *would* be handy.  The DBA 
>> might just consider learning how to do it the agile way.
>
> (Dagna)
> I think that this is one of the problem areas - the dba may
> not see it as 'traditional' or 'agile', but as 'risk'.

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.

> I am not entirely convinced that the Agile method can be
> extended beyond software development too easily -
> one of the things I am on this list to learn. And if it can't,
> then the architects have to learn how to work with the agile
> developers and the dbas so as to minimise the pain felt
> all round.

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.

> 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.

Well, I'd start with a Domain Model...  I think there are a few
basic mismatches between an Object model and a 3NF
relational data model.  The ones that spring to my
relatively untutored mind are the inheritance problem
and the reference / foreign key problem.  It seems to me
that some sort of compromise should be possible, but
the solution may be biased different ways in different
cases.  But what should determine how the solution is
biased?

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.

> Once that is done, the any part of the initial design that has
> been done before is just picked out of that, and the new bits
> added - my average time at this point is a one-hour meeting
> at the start of the project where I get told what the project
> does, the relevant bits of the enterprise logical model are
> drawn up on the white board, and then any new stuff is
> added in and agreed. Then I go and extract the basic project
> model, add the new stuff, and hand it over. Then go through
> it with the dba, if he wasn't at the original meeting. Total time
> can be less than half a day for a new operational/processing
> application. (And the tools I use can generate the scripts to
> create the db). Then we just have to find somewhere to put it.
> Go buy a new server, maybe, work out the space and stuff,
> do we need new licences... Maybe some of the problems
> with dbas are caused by the drag of the hardware?

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 aspertions  ;-)

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?)

> 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.

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 ;-)  ).


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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
--^----------------------------------------------------------------