RE: [AM] [dm-discuss] ZZZ Farewell Fellow Agilists

(responding to Dagna)

> It might be worth mentioning a fairly widely publicised,
> comparatively recent change to data structures, just to
> illustrate the kind of thing that DBAs have to take into
> account when they change a column.
>
> Remember Y2K?

Indeed.  I didn't hear of any really bad horror stories,
but loads of potential for things to go wrong.  What I'd
like to do is take that as a driver for making that sort of change 
easier.  Why was it so hard?  Can we do things now to make
any future change of that sort easier?

> It is a fairly extreme example - we had to find and change a
> load of columns, and then test everything. And have people
> standing by in case anything got missed. 

I'm not sure I understand the full ramifications of the problem,
but it seems to me that a large part of the problem in this
case was the failure to uncouple the meaning of the data
from the implementation.  Applications are going straight
into the database rather than going through an interface.
Say, using embedded SQL rather than stored procedures.
(No doubt the re are other ways to provide such an interface).

Anyway, the basic problem from my point of view is that
I'm not sure I understand.  I may be good at 'agility' but I am
not a DBA.

> But any change to a database has to be checked to see
> what else uses it - other apps, interfaces, user reporting tools
> (Business Objects, Excel, Access...) And if the DBA misses
> one, the project that asked for the change probably won't get 
> users phoning them up and screaming down the phone...
> Which is one reason why they don't like changing columns
> 'on the fly'.

My thoughts are that if everyone went through stored procedures,
then you'd only have them as clients of the database.  I guess
the picture isn't so simple for some reason, but why not?

> Brief introduction (since this is my first post). I am a data architect,
> been doing that for about 12 years now, mostly corporate/enterprise
> architecture - which also involves being part of project teams and
> providing either full data models or starter logical models so the
> developers can get on and develop. Before I did this, I was a COBOL
> analyst/programmer. I have been involved in four data warehouse
> projects - two built, one abandoned when the company was sold,
> one may still be going on as it was for the company that sold my
> then employers.

Does Data Warehousing have special problems?  Again, I
don't know enough to comment on what approaches would be
good.

> I joined this list to find out more about Agile methods, and see
> where Enterprise Architecture fits in (I think I know, and when I
> am sure, I will post my ideas).

Always good to have another point of view.  If you don't think 
we're talking sense, yell.  Somebody will learn something,
with any luck.  Either we'll learn to express our ideas better,
or we'll learn to express better ideas   ;-)


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