Modeling Methodologies

I’m very excited to be blogging here at the ERwin Expert Blogs and I look forward to creating a destination for noteworthy issues and musings on information architecture.  Today, I am thinking about the methods and methodology used to bring together the data model.  No, I’m not talking about dimensional versus normalized.  That decision point deserves due consideration and is an important starting point for numerous data modeling architectural guiding principles.  I see many organizations acting very inefficiently in their modeling methodology - their approach to building the data model.

In building up to the recommendations, I first offer several observations of the business climate surrounding modeling as a foundation.

1. It’s a real-time business world where information is a key asset that must be properly nurtured
2. Data modeling is no longer confined to the major operational and analytical systems
3. Systems are being built and appended to on a very frequent basis
4. Data modelers must start modeling for data that will not persist forever
5. Information cannot be out of date and the business actions triggered from the evidence within data should trigger immediate action
6. Architecture cannot be sacrificed for deadlines
7. Deadlines cannot be sacrificed for architecture

On the one hand, there is the waterfall approach to modeling whereby full requirements are gathered up front, next comes design with all of the associated gatekeeping reviews and possibly even physical sign offs.  Said model and associated development is then moved through unit testing, functional testing, performance testing, regression testing, end-to-end testing and possibly other types of testing that the program manager feels is necessary.

The plan with this approach is that the model will still hang together for the business need in the multi-months that have passed since requirements.  It never does.  Modeling is not linear.  Modelers preferring this approach may get upset when reality intervenes and changes are required.  It can be overheard that “management doesn’t know what they’re doing, they keep changing their mind.”  Yes, “they” always will.

At the other extreme, where quick response is a must, policies and procedures may be unheard of.  Whatever happens happens, as long as the business need is met in a perceived quick, but sometimes undocumented, timeframe.  I’ll call this a methodology-less modeling environment. 

Creativity is valued in these environments.  Responsiveness is essential, since requirements for new tables, columns, relationships and calculations come in or are discovered irregularly over time, as opposed to up front.  Often times, the model development does not resemble development at all, but active support of a production model that happens to be pre-production.  The lack of controls in these environments can lead to poor development, a ton of trust in the data modelers – perhaps more than even the modelers would allow, and a very chaotic environment that can get the best of the best modeler.

In summary, the downside to the modeling extremes are:

Fast forward to the reality that mature, efficient data modeling operations end up at over time – Agile.

We’ve all heard of Agile by now.  It’s what I use for modeling and overall project management whenever I get the chance.  You have to have the right personnel to do it right, but it’s truly a balance of the above extremes.  With Agile, modelers have guidance in the form of principles and milestone dates, but are also allowed the freedom to shift focus and do what it takes.  There is a fair amount of guided prototyping with the users.  The business is actually part of the extended development team in Agile modeling.

Agile modeling done right means:

1. High Quality, Low Maintenance Models with Minimal Breakage
2. Limited Rework
3. Fewer Working Hours with more Productivity
4. A Predictable Environment
5. Resource Leveling (enough resources in the right places)
6. On Time and On Budget Models
7. Easier Justification Process and Business Approval of New Modeling Approaches
8. More Opportunity for Career Path, Employee Development and Training
9. Faster Problem Resolution with Calculated Predictive Research Actions 
10. Realistic Expectations Set at all Levels,  Open Communications

Approach methodology is as important as the modeling style of dimensional or normalized.  It’s every bit as important as architecture.  Unlike the common impression that Agile sits at the chaotic extreme end of the spectrum, true Agile-based modeling is guided by methodology.  It’s methodology that strikes the right balance between architecture and deadlines.