The Problems With Modeling

As we wind up the year I thought I'd share an issue in the architecture and project management spaces that I saw crop up repeatedly in 2006: data and architecture models (and the people who made them) getting trashed by IT managers and business execs as a waste of time and resources.

In one case, a client manager was presenting a conceptual data model to his management and other interested parties in a project kickoff meeting. As the primary focus of a CDM is to directly map business requirements to data entities at a very-high level, the model did not contain materials that would normally appear later in the design/development, such as the physical data model or the DLL code necessary to actually install the physical model into a relational database.

This guy couldn't get to the third slide in his Powerpoint deck before getting smacked upside the head by the VP, with other managers piling on directly after. The managers could have cared less about a conceptual data model - when were they going to get their data warehouse so they can analyze their costs and financials? One exec, a former techie, went so far as to begin a macabre bout of row-column engineering on the thing, right there in the meeting. Our guy very quickly lost control of the room and the meeting degenerated rapidly from there.

In a few other instances over this past year, I've seen some architects take it on the chin for producing models that were largely 'academic' in nature and of little use to the projects they were developed for. These unfortunate scenarios cause a lot of problems with job performance, project costs, and the time spent developing models that could have been better spent using modeling to directly influence the success of the project.

Does this mean I'm against architecture and data modeling? Not at all. However, it has to be done intelligently, expeditiously, and with the project/organization outcomes in mind at all times. With that, I offer some rules-of-thumb on modeling that I hope folks find useful.

1. The later a modeling effort occurs in a project, the less value it has to the project. Sometimes architecture and data modeling are brought in 'late to the party' on a project for various reasons political and technical. A CDM or logical data model developed right before or during development has little value to anyone working within the development process because it's essentially too late to change development plans and issues without taking a schedule slip. The value of a CDM at that point is usually for documentation/artifact purposes only, and I would think twice about that if it will cost the project more in terms of schedule and money that it will save.
2. Academically rigorous models have value only to academics. I saw a couple of data modelers fall on their swords this past year defending ornate, complicated data models that only made sense to them, not to others. Worse, the models had little or no value to anyone else on the project and even worse than that, the modelers in question got defensive and spent much meeting time defending their work. That might be fine for Ph.D dissertation defenses, but in business, as one of these modelers found out, it can cost you a job. Unless a model has direct and positive impact on directly-connected downstream development processes, it might be prudent not to perform the exercise, or to produce only enough to enable such processes. Watching these two colleagues "fail" their projects with ornate, over-designed models that 'took too long' leads me to believe that there is a definite line between the academic exercise in modeling and the ones that enable business projects.
3. "Taking too long" is usually fatal. Modeling efforts are usually in some proportion to the size and complexity of the project. However, modelers must keep in mind that even if things are generally going well on the project, timely and useful information from models must always be provided. Most project managers will question why a modeling effort is scoped at weeks or months, and rightfully so, particularly if downstream development activities are delayed because of it. Models need to provide actionable information as quickly as possible, which places time constraints on their scope and complexity. Modelers would be wise to re-think their approach if there are scope and time objections, because this is a leading indicator that project managers and developers are not seeing enough value in the effort to continue the process.
4. If the model is for documentation/artifact purposes only, skip it or produce the minimum required. Unless the model is: a) necessary to comply with some regulatory or project requirement; or b) directly actionable and useful to development and test teams, the only value the work product has is as shelfware in the modeler's cubicle. Not a good situation for the modeler, the project, and the organization.
5. Whiteboards and digital/cell phone cameras are acceptable modeling tools, particularly if time is short. I've observed that an excellent way to get on the wrong side of management and development teams is to state that entering and validating the models into expensive design toolsets will take a lot of time. I have validated this approach on more than one occasion by taking photos of whiteboard exercises and pasting them into documents unedited. Nobody ever complained about the format but many did remark that they got the information they needed promptly. Beyond the whiteboard sessions themselves, the cut-and-paste jobs took about 10 minutes each.  Entering them into a modeling tool to produce and validate 'pretty pictures' churned out on expensive plotters can take days. Do the minimum required to convey the information and stop worrying that your toolset skills are less valued - because in a lot of cases, your ability to quickly get vital architecture information out to those that use it is much more valued on projects than being a good tool jockey.

While I realize that a lot of this will go against the grain with some of my readers, I felt I had to share it because these issues repeatedly came up on projects I worked on or had detailed knowledge of in the past year, and I really don't see the tide turning back to documentation-and-process-burdened development. Organizational needs and 'attention span' are too short these days for that luxury.

And its time to deal with it.

Comments

[Ben Craigo]

Enjoyed your post. You touched on several important points.

For data warehouse projects there are so many folks involved that managing how information is communicated is critical. I feel sorry for the guy who presented the CDM - it was probably not the meeting for it and definitely not the crowd. What bugs me is that his management was there and it looks like they left him flapping in the wind - not good.

I posted more about this on my blog.

For the academic modelers out there - there are always going to be developers, modelers, architects and so on that have to be monitored and realed in from time to time. It's also a good indication that those folks need mentoring and coaching to better focus their skills.

Thinking in the abstract, academically or out-of-the-box is not a bad thing - as long as you can pull out and get to business if it doesn't pan out.

What's required is strong management both up and down the chain.