Last month I wrote about “Why Reverse Engineering is Always Worthwhile.” So the logical next issue to examine is forward engineering – its different approaches and its many comparative benefits. The best way to do this is via an analogical example J

I live in Dallas-Fort Worth. Let’s assume that I drove down to Austin at the start of the this year’s college football season to watch my #1 Ohio State Buckeyes play against #2 Texas. As I’m not too bright when it comes to driving and directions, I might have taken the following route: 45 south to Houston, 610 west to 290, and 290 west to Austin. That poorly chosen route would have taken 7 hours to drive!

Now when I arrived in Austin and met up with some buddies to attend the game, they all would have a great laugh at my choice of routes. Furthermore, they probably would have asked if I was going to choose 45, why not cut across 79 west about half way to Houston and reduce the trip to 4.5 hours – a 36% reduction in drive time.

That’s a perfect example of reverse engineering: using 20/20 hindsight to examine what you have or did, and possibly making some incremental or evolutionary improvements. But this approach is effectively nothing more than the simple tweaking of a potentially fundamentally flawed design.

Of course had I been smarter and called those friends first to ask what route to take, they would have said simply I-35 south with a drive time of just 3.5 hours – a 50% reduction! It’s the most direct route and a modern four-lane interstate highway the whole way.

That’s a perfect example of forward engineering: using available foreknowledge to arrive at effective and efficient solutions. It reminds me of the old adage – look before you leap.

There’s one more popular choice though these days, known as reengineering (I refer curious readers to Michael Hammer’s fine books - The Reengineering Revolution and Beyond Reengineering: How the Process-Centered Organization is Changing Our Work and Our Lives). Referring back to the driving example, had I taken the 7 hour route this time – but next time told myself there has to be a better way, that would be reengineering. My father had a much simpler name for this concept years before Hammer’s books – he called it learning from experience and mistakes – or wisdom J

So now focusing back on the data modeling and database design world, we can apply my overly simple driving example and observations to infer the methodology diagram below.

The primary reason that forward engineering is vastly superior to just simply reverse engineering is that the data models, and therefore resulting database designs, are based upon solid foundations: business requirements analysis, important lessons learned from prior systems, or both. In other words, comprehensive logical data modeling applies both forward and backward looking analysis based on genuine business requirements to arrive at truly effective solutions. In short, logical modeling gets it right (effective) and physical modeling makes it optimal for the chosen database platform and technology (efficient).

So it’s my belief that merely doing reverse engineering does not provide one enough opportunities to learn about the true nature of the business nor to fully appreciate and learn from past implementation shortcomings. Thus I’d recommend logical modeling with forward engineering whenever possible. The resulting systems can only be better.