The idea of building a conceptual model during the early phases of a project was once a critical deliverable in an IT project plan. As we all know, IT development methods have changed over the years and with that change came changes in artifacts. I’ll start this discussion by saying that the activities of conceptual modeling still exist in some shape but not necessarily in the form of a conceptual model. I’ll stick my neck out by saying that today’s development environments pretty much ignore or minimize the value of conceptual modeling in their methods.
Any discussion on conceptual modeling gets bogged down in what really constitutes a conceptual model. I’ve seen many perspectives. The simplest being a single page pseudo ERD with boxes representing business areas of interest and lines between them representing the interaction of these areas of interest. More complex conceptual models have decomposed layers of diagrams supported by pages of business process definitions. Sometimes these models may be diagramed with a modeling tool such as CA ERwin. Guess what? They are all indeed valid conceptual data models.
Over the past few years, I find myself working with fast moving development teams. They are a steamroller cruising down the highway. The desire to deliver solutions faster to market compresses the time allocated for business analysis and requirements gathering. That developer steamroller just keeps coming faster on the tails of business systems analysts, systems analysts and data analysts who are laying the roadbed for the project team. It’s crunch time and usually the conceptual modeling effort suffers with abbreviated analysis. The logic is that we will do more of it when the logical model is designed. And… it usually does happen.
Do we suffer when we undervalue the benefits of conceptual modeling? We most certainly do. The idea of conceptually sketching out your plan of attack prior to walking down the development path has proven to be of great value over the years and still holds water in new development methods. The challenge data modelers face is knowing what level of conceptual model is needed and the appropriate time to spend on the modeling activity. Data analysis and design has gotten a bad rap over the years from slow-to-respond and non-project-aligned database development teams. You know I was going to get my common theme of alignment and responsiveness into this post. They are key attributes that make data modeling teams and data professionals successful.
The discussion above spoke of the conceptual data model. It could as well apply to any conceptual model. What is the answer to the questions of the appropriate level of detail and time invested? It’s something that comes from experience in the craft of data modeling. Here are some guidelines I follow. Work with the project managers building the project plan. Data tasks and deliverables should be at the same level of detail as other domain areas’ artifacts. Be responsive to the project team. Make sure your artifacts are used by other team members and you use their artifacts. Nothing is worse than producing a deliverable that no one uses or cares about.
Give the above some thought on how you conceptually model today. Leave me a comment. I would love to hear your feedback.
Follow ERwin online through Twitter, Facebook, and LinkedIn.