About The Conference

• Date: April 1, 2006
• Location: Niagara Falls, NY
• Register Now
• Interview with Scott Ambler

Keynotes

• Put Testing Where It Belongs--At the End by Brian Marick
• Dead Fish Can't Swim But They Can Float Down a Waterfall by Tim Lister
• Extreme Programming Uninstalled by Ron Jeffries
• Super Model Driven Architecture: An Update From the OMG by Tyra Banks

Contact Information

The Waterfall Alliance
PO Box 1970
Cascade, Illinois

E-mail us

Sponsors

• 
• 
• 

Dinosaur Strategies: How Data Professionals Can Still Prosper in Modern IT Organizations

Scott Ambler

In recent years we've seen a meteoric rise in the popularity of agile techniques such as Extreme Programming (XP), Scrum, Agile Modeling, and database refactoring. Just as data professionals safely ignored object-oriented technology in the 1990s, we can similarly ignore agile techniques in the 2000s. For all the hype, organizations never adopted object technology to any great extent and it is likely that agile techniques will suffer the same fate. There is no need to worry.

So what should we do as the application developers around us once again waste their time trying new, unproven techniques? History provides the answer--we should look take our cue from the dinosaurs of course. Dinosaurs thrived for millions of years, millions of years! Clearly there must be strategies which the data community can adopt which will enable us to similarly thrive for at least that long. In this Birds Of a Feather session we will discuss potential dinosaur strategies such as:

• Guaranteeing consistency--With sufficiently onerous database change management procedures we can slow, if not prevent, schema changes by development teams.
• Centralized database control--By requiring development teams to work solely through the data group we can ensure that we won't go extinct any time soon.
• Promoting quality--Comprehensive reviews of both data requirements and database designs can ensure quality after the fact.
• Walking the talk without walking it--We only need to claim responsibility for data quality within an organization, we don't need to waste any time developing regression test suites for our databases. Nobody has noticed us doing this so far, so it should continue to work out for us.
• Justifying an onerous, data-centric process--We must prevent application developers from gaining data skills, ensuring whenever they do "go rogue" because they find us difficult to work with that that they will do a poor job designing the database. Once they're eventually caught we'll be able to point out why poor data quality is their fault even though we claim to be responsible for it.