As this is my first post I wanted to start with an explanation of the theme of this blog. The title: Rapid Application Development, refers to the software development methodology started by James Martin in the 1980's, not to some vague marketing concept as the term is more frequently used (for details see my article: http://www.blueink.biz/RapidApplicationDevelopment.aspx).
My specific spin will be designing, architecting, and implementing Microsoft .Net n-tier web applications since that is my career and my passion. That's the idea anyway, let's see how it looks after more than one post. ;)
Appropriately I wanted to start with with a discussion of the importance of developing a Logical Data Model, which should represent a vital step in the building of all software development projects, and is a core part of the rapid application development methodology.
Previously I'd thought logical data models were a crutch for people who were unable to model physically. I mean, why use some rough approximation of a real data model when you could use Micorosft Visio to develop something that will actually turn into a real database in order to start your actual software development?
Recently, however, I've had the pleasure of working with Steve Dempsey, a man who worked with James Martin and knows the RAD process inside and out. More specifically he is someone who believes a project will not suceed without a logical data model.
The more we've discussed our differences of opinion, the more I've come to concede my point. It hit home for me when I considered a recent project where using it would have drastically shortened the length of the project.
It comes down to how you apply the logical data model. For instance it's not just a starting point for the database, think of it as a starting point for the object's in an object oriented world as well. The strength of the logical data model is realized for instance when you build UML sequence diagrams based on the entities in your entity relationship diagram - and more specifically when that doesn't mirror your actual database structure!
My recent project used objects that didn't mirror the logical data model and the consiquence was non-intuitive code, a degredation of maintainability, and designing in complexities that could have been avoided.
Conclusion? Logical data models rock. Use them. They're not a crutch, they're a launching point for development.
And in case you're visually oriented consider the contrived example below where employees are denormalized into their company in the physical model, but are used in the logical model and sequence diagram (click the image to enlarge):
If this thought make sense then this is a BLOG is for you. Not sure? Please comment. I will post more concrete how-to's, .Net code samples, my favorite web resources, and undoubtedly random thoughts that may still interest you ... some other day.