Taking notations on agile data modeling

You can’t talk about agile data modeling without mentioning Scott Ambler, whom many consider the authority if not founder of agile data modeling.

In this tip, Ambler takes readers through an iterative approach to requirements modeling. His definition of agile data modeling is straightforward: Evolutionary data modeling is data modeling performed in an iterative and incremental manner … done in a collaborative manner.

Taking an agile approach to data modeling can help resolve one of the most onerous data modeling problems: very slow and complex notation development.

As explained by Burton Group senior analyst Joe Maguire, building data models takes so long because the practitioners developing notations aren’t seeking simplicity. “People designing notations are trying to get tenure, a PhD, when they design notations,” he said. “They don’t get tenure for making things simpler.”

Which leads vendors to incorporate more complex notation designs into their tools, he said. Data modelers are stuck working with these tools and forcing users (the consumers of this data) to provide information that covers every aspect of the requirements in these notations.

So how can agile data modeling help? Agile recognizes that there will be change, whether you are developing software or a data model, but beyond that it allows you to build a data model with less rigorous notations. System requirements, or information requirements, that are especially subject to change and ones that are less susceptible to change can be identified and put in different notation buckets.

“Then you can alter modeling behavior to model stable requirements earlier in the process with confidence, and not model unstable requirements too early in the process. That helps accelerate the process of data modeling,” he said.

And this needs to be done on a business, not technology level. “If the taxonomy in my head as data modeler is motivated by the business significance of the requirements, that’s something I think agile techniques would really improve, if [data modelers] took that kind of taxonomy to heart.”

This is only a snippet of his thoughts on agile data modeling and a much larger issue Maguire is taking on at Burton Group’s Catalyst conference in San Diego this week. Here’s the overarching theme of his talk: Agile software development has an offshoot: Agile data modeling. The decision to use agile data modeling depends on local realities about information architecture, buy-or-build approaches to software, democratization of data access, and the company’s commitment to business analytics. For IT strategists, the decision to use agile data modeling is further complicated by the rancor that accompanies the debate. The session will touch on:

• Why are typical data-modeling initiatives so cumbersome, and what can be done about that?
• Why do data modelers resist agile data modeling? Is the resistance justified? Unjustified?
• How can IT leaders mediate the disputes between agile software developers and data management professionals? Are these disputes a healthy phenomenon, or a symptom?
• What kind of business environments and IT initiatives are amenable to agile data modeling?
• How can agile data modeling techniques be improved to become even more agile?

I’d like to hear from you if you are taking on agile data modeling, and learn what obstacles or benefits you’ve encountered as a result. Email me at [email protected].