How much modeling was RE: [AM] Unfounded assertion

At 10:43 AM 2/4/2004 +0000, you wrote:

>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 you can do is suggest the new requirement, to deal with it as a 
compound field, and see what your stakeholders say.  If it's a good idea, 
and it often is, then they'll go for it.  If not, I wouldn't overbuild the 
software.


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

Once again, I'd avoid overbuilding it.  If your database is easy to change, 
then you don't need to overbuild.  If it isn't easy to change, I'd start 
refactoring it and the things that touch it so that it becomes easy to change.

Worst case I'd incrementally add the features that I need and let the 
legacy data sources constrain me as you imply (raising my development 
costs).  But I wouldn't try to do it all at once.



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

Yes, you need to take legacy concerns into account.  Your architecture 
should take potential future concerns, perhaps by exploring change cases 
(http://www.agilemodeling.com/artifacts/changeCase.htm), into account but 
that doesn't mean you need to overbuild.  You need to find the sweet spot 
between taking no constraints into account and doing BDUF.  Different 
projects, different answer to this question.



>I don't model the future of the enterprise.

Perhaps you can, check out the URL above.

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

Exactly what changes cases help you to do.


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


- Scott

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