To be honest, I have always thought about legacy systems as being poorly engineered.  I mean we know them to be unwieldy, expensive to maintain, and all-too-often unfriendly to the business.  In that sense, yes, you could say they are poorly engineered.  But that's a bit unsatisfying.  After all, most IT developers I've known are pretty astute, hard-working professionals.

In their new book, Smart (Enough) Systems,^[1] Neil Raden and James Taylor offer a different point of view.  They argue that legacy systems haven't been poorly engineered, they've been over-engineered.  To say the least, that's counter-intuitive.  But I think it's probably right.  What happens when you over-engineer something?  The solution you produce is usually too stiff or rigid or cumbersome for the real-world problem.  Think tree that doesn't bend with the wind.

That's exactly the problem with legacy systems.  The speed of business itself is accelerating rapidly, but the architecture of traditional systems is rigid and static.  Raden and Taylor describe the situation (p. 113) as follows. 

Part of the problem comes from a mind-set that systems, like other enterprise assets, should be built to last.  This focus results in detailed but largely static requirements and huge investments in system architecture and design.  However, it also buries critical code in complex systems.  To make applications robust and complete, a huge amount of business expertise must be embedded in the system….

That's exactly where the problem lies -- the embedding of business expertise (read business rules) within the system itself.  Building that way is actually quite hard.  Indeed, traditional development methodologies require IT developers to have a high level of expertise both in the business and in how to implement functional requirements under the given platform(s) or language(s) most effectively.  That's a lot to ask.  Even if you get the business rules right (doubtful in itself), the rules are now hard-coded in the application logic where they are hard to find, hard to understand, and even harder to change. 

And that's just it -- the business rules will change.  So you will be revisiting the code. 

There's a certain mindset in traditional IT departments that revisiting code with any frequency means the code must be fundamentally flawed.  But with respect to business rules, that's way off-target.  Raden and Taylor say (p. 113):

An important difference in automating decisions is that, unlike other aspects of information systems, decisions change continually.  Most IT departments consider code that must be constantly revisited to be suspect or "broken" in some way.  Decisions, however, aren't static.  The best way to make a decision should be expected to change.  Organizations learn, new data is collected, and regulations change, and all these events change how you should make a decision.

The obvious solution is a separation of concerns.  Quite simply, the business rules should be engineered separately from the functional requirements.  Can you really do that cleanly and effectively?  Hello!!  That's already been proven using off-the-shelf rule engines over the last decade.  If you are coming to the Business Rules Forum Conferences this month, you'll hear from some 50 companies about how they did exactly that.

Over-engineering resulting in rigidity is not a good thing.  It results in buildings that tumble in earthquakes and bridges that collapse in windstorms.  In IT terms, it produces a world where some 75% or more of all IT resources go toward system 'maintenance'.  It's time to move on to the next engineering paradigm.  Raden and Taylor call it Enterprise Decision Management (EDM), the way to build systems smarter.

References

[1] Neil Raden and James Taylor, Smart (Enough) Systems: How to Deliver Competitive Advantage by Automating Hidden Decisions, Prentice-Hall (June 2007), ISBN:  0132347962.

---

For more information on EDM and related ideas by the authors of Smart (Enough) Systems, access free recent webinars at: What Are Smart (Enough) Systems and Why Do You Need Them? Rules as a Basis for Enterprise Decision Management (Part 1) Rules as a Basis for Enterprise Decision Management (Part 2)

# # #