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

> -----Original Message-----
> From: Paul Oldfield [mailto:[email protected]
<mailto:[email protected]> ] 
> Sent: 04 February 2004 22:18
> To: INTERNET:[email protected]
> Subject: Needs to know everything; was: RE: [AM] ZZZ
> 
> 
> (responding to Dagna)
> 
> > EVERYONE NEEDS TO KNOW EVERYTHING!
> 
> 
> > That's what the DBAs are paid for - and part of their job should be 
> > helping people who don't need to know the details, work 
> stuff out that 
> > they need to do.
> 
> Are you *sure* you work with data?  Or were you just about
> to add the "but not until 6 weeks after they ask for help"?  ;-)

DG: Yes, I work with data - but mostly at the metadata level. Which, IM(not
so)HO, covers everything from the Enterprise Conceptual Model to tuning the
databases. (At least, knowing what to look out for and what the dbas can
reasonably be asked to do, and not designing the thing to make it too hard
for them). 

<snip>

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

I think that this is one of the problem areas - the dba may not see it as
'traditional' or 'agile', but as 'risk'. 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.

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

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.

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