Home > blogroll, Commentary, consulting > Why Packaged ORM Frameworks are Bad for your Business

Why Packaged ORM Frameworks are Bad for your Business

There are as many ORM or middleware or data access layer frameworks as grains of sand on the beach in Miami. Most or all do a lot of work for you and can speed up development tremendously. They can reduce code, increase quality, and centralize solutions that solve known problems in software development.

Most software architects love frameworks. For every architect, there’s at least one home grown framework. For every architect there may also be one or more favorite packaged framework. Some make a living pushing their framework by using it as a ramp up to consulting projects. Some write books about all the great patterns they’ve implemented in their framework.

Managers and directors and chief architects will all do powerpoint presentations showing how the chosen framework will reduce costs, save time, and improve results.

What they won’t tell you is that frameworks can be a terrible thing for your business.

Now that I’ve thrown down the gauntlet, let me explain.

I’m going to talk about Technical Business Debt today. This is from my own observations of using various frameworks in the last decade and I believe it’s something very measurable and very important to understand.

You have an existing codebase in any established business. At some point the code, the database, the reports, the systems…they all seem old. Somewhere along the line someone decides changes need to be made to improve one or more aspects of the codebase. You need a new data model. You need a web based data entry system. You need web services to share logic with other departments or external businesses. Whatever the catalyst is, something needs to change.

The first thing most architects look for is an easy win. How can I take the existing codebase and replace it or fix it with a cool new framework. Let’s implement an ORM system or Dependency Injection or Code Generation. I can have that new system developed in no time. Trust me.

Sound too good to be true? It is, but you won’t realize it until it’s too late. The problem with these pre-baked easy to implement frameworks is that you lose an essential piece of the upgrade process. You lose your business. How’s that?

It’s simple. If you slap a coat of paint on an old house, fix the trim, get a landscape crew to spruce up the yard, have some aromatherapy going on inside the house when people visit…hey, it looks like a nice house. People will be impressed. But they won’t see the cracked foundation that draws a 4 inch flood every spring. They won’t see the 15 year old furnace that costs 60% more than a new one would. They don’t see dust in the carpet that’s making all occupants suffer terribly from allergies.

If you really wanted to fix the house, you need to live in it. Then you need to take the time to fix things properly. You need to note the cost of heat and replace the furnace. You need to replace the old carpet with new carpet or hardwood floors. You need to put new windows in.

The same holds true of your business computer systems. In order to truly upgrade, you need to do it step by step. You need to implement each element of your business systems again, from scratch. The reason you need to do this is because your business has changed. Your customers have changed. The world has changed. As you rebuild your systems from scratch, the developers will ask questions. These will get passed on to a business analyst or stakeholder. The stakeholder will listen to the question and the proposed or assumed solution and stop everyone in their tracks. They’ll do this because the question is bringing up old business practices as well as revealing new practices. This process actually shows the stakeholders how their business has changed, much of which would have never been examined if it weren’t for the process of rebuilding each element.

It’s a bit like the Socratic Method. You learn by questioning and testing the foundation of each question. If you look at your systems and question their purpose as you rebuild them, you will discover how your business used to work, but more importantly, you will determine how your business should work. If you’re smart and lucky, you’ll also see trends.

Using frameworks that simply put a new face on old systems is fine for short term solutions. But don’t kid yourself that you’ve moved your business forward. You haven’t. You’ve just increased your Technical Business Debt. And you’ve also lost a priceless opportunity to examine your business at a low level. Something all businesses should do on a regular basis. You may not think you need to rebuild from scratch, but trust me, if your business has changed, the only way you’ll know is by doing just that.

  1. Paul
    May 16, 2010 at 1:55 am

    David, Isn’t the ability to use the ORM or at least the CRUD portion of teh ORM truly a big win where you are then only left to learn what is specific to your business?

    • May 16, 2010 at 2:21 am

      Sure, but I’ve seen very few architectural decisions focus only on the table module code generation pattern, which is what you’re talking about. All of the environments I’ve seen, except for the ones where I’ve been the decision-maker, took the framework into relations and object-mapping via meta-data or some fluent mechanism. These are the things that I think are an enormous mistake for a changing business. Once you start mapping relationships and/or objects, you lose insight into how your business functions. Some may argue that the function of the business is at the object or domain level and there’s some validity to that. However, I believe strongly that instead of ORM we should be focused on DSL’s (Domain Specific Languages). So instead of using C# or Java to write code, we should be developing new coding syntaxes that represent our business model.

      In lieu of this, we should keep it simple, because the syntax of our business changes regularly.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: