I thought Edmund DeJesus' article, Design for Success, was nice because it showed that [some] people realize the benefits of modeling. It brought up something that I've been fighting for some time, th database-driven design. I know that this is going to raise some eyebrows - especially in the Microsoft arena (i.e. VB6, ASP, .NET) - but here goes...
It seems like most people who use Microsoft technologies have one or more individuals who take care of software and database development, instead of having a pure DBA. I guess a lot of developers started doing small projects where they had to create and maintain databases themselves. So, since most of these developers have database experience, they develop applications based on database designs. There is good and bad to this. Ultimately, though, I feel like you're losing something in the process of moving in this order.
First off, it's obviously a good thing if you have more advanced database support than software support. A second situation is that you might have a legacy application that is being updated and the database cannot or will not change. I would suggest that you do change it, if you have the option. In most cases, legacy systems have bad database designs, so pushing for an update is probably worth it.
The biggest problem that I see in this is that software is about software, not databases. Databases are purely there to house data. If you were to use text files or even caching, the software should stay the same. And, while there aren't any new data store technologies on the horizon, that doesn't mean that they won't come up. I prefer to take a strong OO approach - one that is heavily rooted in how the objects exist and what responsibilities they cover. This allows you to do some domain modeling to identify what objects you are dealing with. From here, you then create a data model that will represent the database. After this, I like to create my data access layer, but that's outside the scope of this post.
The problem is that most people seem to model their database instead of the domain. Doing this will skew relationships and make it harder for customers to understand what the developer is thinking. This is why customers don't look at database designs in a lot of situations. [Honestly, they probably shouldn't.] It's better to provide the customer with something that can be read and fully understood easier. Except for the simplest of systems, you cannot guarantee a 100% accurate domain model unless the customer approves or verifies a domain model of some sort. Customers may or may not understand entity-relationship (ER) diagrams, so having them verify that is risky. If your customers do understand ER diagrams, more power to them. But, there's still a problem in the fact that ER diagrams don't effectively show the 5 W's - they only show 1.
Moving from the domain model to the data model allows customers to verify the business domain and it enables database developers to see the physical data entities and relationships on paper, instead of in their head. This helps ensure better database and ultimately software quality.
On a slightly different topic, ER/Studio sucks. I hate that program. IBM Rational XDE is OK, but I hate how it doesn't force conformance with UML. If you're using a UML tool that integrates with your development code, don't you want to make sure that it's right? And, not just something that looked right to the beginning developer/designer? I guess it's not made for large systems, anyway. The best modeling tool that I've found is Sparx Systems Enterprise Architect. I just wish that it had a VS.NET plugin. Has anyone else seen anything better?