RE: [AM] Unfounded assertion

This one got me all fired up...

A database designer won't be able to anticipate all the future requirements,
at least not until Oracle TM comes out. (TM - Telepathic Module, that does
it all automagically). But we can (or, at least, I can, and I don't think I
am that unusual!) work out that if a field is made up of compound data (like
initials + surname, or quantity multiplied by price to give net value), then
someone is going to look at it and want to get at the elements. (The price
per unit.)  What the designer must do is to catch the compound stuff early
and either break it down, or explain to the business clearly, and written in
blood (theirs) that this field may look like a compound field, but it isn't
and the only way they can break it out in the future is to get the data
quality team to fix the underlying data. (And if they don't have a DQ team
(even a team of one person), then they may be in more trouble than they
realise.)

If the database is going to be getting stuff in from other systems in the
future (maybe you are building a warehouse), and you know what they are (or
should be, or may be) and what is in them, then it is a good idea to design
your early phases with the later stuff in mind - like other customer types,
or fancy stuff with taxes and levies that will come in with the commercial
customers once you have the domestic data nailed. (I used to work for a
large utility company.)

My design may not cope with the way the company does business in five years.
In five years, the processes will have changed, and so will the business.
And that is normal, expected, and why new systems get written. The old ones
keep on running, because while we are doing new stuff, we still sell the
original product. (Five years is a very long time - unless the business has
a hugely long product development cycle.) But if my design falls over within
six months because my basic analysis was sloppy, or because I didn't listen
when I sat with the users and they showed me how they do their jobs, then I
am sloppy, incompetent, and maybe need a refresher basic data analysis
course. And a kicking from my manager.

I don't model the future of the enterprise. I model an enterprise that can
change without too much pain. If your data people have the quaint belief
that the enterprise is a solid, monolithic thing that will never change,
then encourage them to wake up and join the real world. They could start by
going to a presentation by John Zachman, on how the enterprise will change,
no-one knows how (not even the people running it), and how it can survive.
(His presentations tend to leave the audience feeling pretty breathless).
And if your enterprise is a solid, monolithic thing that will never change,
then get on as many training courses as you can, keep your cv (resume) up to
date, and wait for the redundancy payoff.

We can't anticipate change, but we must design to allow it.

(Another option is to hire me at a suitably immense salary... <g>)

Regards,

Dagna

> -----Original Message-----
> From: Steven Gordon [mailto:[email protected]] 
> Sent: 03 February 2004 18:54
> To: [email protected]
> Subject: RE: [AM] Unfounded assertion
> 
> 
> I am sorry, but this attitude that the designers of a 
> database are responsible for anticipating the future 
> requirements is a big contributor to making the data side of 
> the enterprise so resistant to agility.
> 
> You cannot anticipate future requirements.  A new set of 
> users want what the users did not want it 5 years, so learn 
> to live with change.  The sin of the past was NOT that the 
> database designers should have thought of this unstated 
> requirement.  The sin of the past was that the application 
> developers used the database directly throughout their code.  
> This tight coupling is what makes it hard to change either 
> the database or the applications without changing the other.  
> 
> Placing the blame on the database designers will just 
> embolden data modelers to waste time trying to perfectly 
> model the whole future of the enterprise before they will 
> risk producing a database design or changing an existing one.
> 
> -----Original Message-----
> From: Gaythorpe, Dagna [mailto:[email protected]]
> Sent: Tuesday, February 03, 2004 2:47 AM
> To: '[email protected]'
> Subject: RE: [AM] Unfounded assertion
> 
> 
> But if the users want the name field split, don't waste time 
> wondering what to call it - that time would be better spent 
> explaining to the person who designed the database that they 
> messed up and should have thought of this one, and then 
> finding out that they did, but the contents of Name are in no 
> clear format - surname + initials, forename + surname, 
> initials + surname, all in one field in the source system 
> (which isn't this one)... 
> Regards, 
> 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] 
> 
> For more information about AM, visit the Agile Modeling Home 
> Page at www.agilemodeling.com
> 


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