An article written by Bert Scalzo was published in Information Management this week. The topic is 'Is Data Modeling Still Relavant?': it's short, to the point and well worth reading.
The article doesn't recommend a specific tool, it simply recommends the practice of capturing a model of the data at rest (old school approach) in addition to the newer techniques that focus on capturing the data in motion (process flows, business process modeling, etc). According to Mr. Scalzo, capturing the data-at-rest will lead to a solid design, one capable of maintaining both data accuracy and performance, and I absolutely agree. If a database administrator want to become a crucial resource to their company, knowledge of the data is the most direct path to achieve that goal. If you take the time to understand the data, understand how it is used and how it can be used by your customer, put that knowledge into the data structure and you will develop a system that your customer cannot live without. When the customer says, 'We didn't think of this in the initial planning, but we really need to be able to do X', (and they always, always say that) you will be prepared to provide that functionality far faster than they expected. (of course, it's up to you and your management whether you tell them you can do it two hours or two weeks - those decisions become all about managing workloads and expectations) Some times that extra functionality creates additional billables and revenue, which further increases your personal value right along with the system's value. It's not my role to negotiate which features are billable and which features become a gift to make up for some other issue, I just tell the suits, 'Yes, that can be done easily' or 'Yes, we can do that in the next release'. Sometimes I even get to say 'Yes, that functionality is already in there'. With a good data model, I don't have to tell them no and I like it that way.
The inherited project I've mentioned before landed in my lap with no data model at all, and a few months ago, it wasn't even capable of it's promised functionality much less anything extra. There was no real structure to the design, no constraints, no primary keys, no unique keys. (it did have duplicate records and that's not a good thing). It's been reworked and rebuilt, and in the last two weeks, I've been able to say 'Yes' to quite a few requested new features. The customer is beginning to see the real potential of the system, which is bound to lead to even more plans for new features and tools, and even more work and interesting challenges. None of this would have been possible with the original data un-model.
There was a second bit of the article I found interesting:
"... people get so caught up in novel paradigms such as extreme programming, agile software development or scrum that they compromise data modeling, or even skip it entirely. The problem is that these new approaches don’t always spell out exactly how data modeling should be incorporated, so people often forego it."
A separate project that I support on an as needed basis is in the midst of an agile development effort. They're building a new product which similar to an existing product so it's being built on the existing data model. I'd pointed out in the past that the data model is lacking in a few areas but nobody has time to revamp it as it would be a large undertaking with most of the code requiring a rewrite. I don't know much about the new app, and it may be that the data model is perfectly suited for this one. However, I have noticed that I wasn't needed for this 'agile' effort, until testing resulted in memory problems and by then, the release date was right around the corner.
Does anyone have an opinion about Mr. Scalzo's statement above? Do these programming paradigms ignore the step of data modeling? If so, do you think it is a failure to mention data modeling with the expectation that data modeling occurs elsewhere in the development effort? Or do people really believe that data models are not needed within Agile or extreme programming?
2 years ago