ERP and The Throw Everything in One Big Database Crowdposted by Anna Mar, July 26, 2011
The other day, I was discussing enterprise architecture with the CTO of a retail bank. He said something along the lines of:
Why do all of our applications have separate databases? We need to do all this integration — can't we have one big database for everything?
My first reaction was to cringe but then I realized that this is a conventional architectural pattern — it's called ERP.
ERP — One Big ApplicationERP implements two architectural patterns:
1. one big application
2. one big database
ERP applications have such massive scope that they can theoretically replace hundreds of legacy applications. However, most real world ERP implementations retire few legacy applications — instead they integrate with them.
ERP is an Integration StrategyERP is all about integration of processes, data and user interfaces.
Most organizations have a terrible track record for controlling application proliferation. As a result, it is common for large organizations to have hundreds (or even thousands) of legacy applications. The IT landscape of many organizations has become a big ball of mud (technology so complex and disorganized that no one understands it).
Large ERP vendors promise to replace the big ball of mud with one best of breed application.
Does it make any sense?ERP solves a complex integration problem with a complex application. ERP benefits many organizations — if only because it gets everyone focused on a consistent IT strategy.
The complexity of ERP applications mean that implementation projects are fraught with risk — but as an architectural pattern ERP does make sense.
Learn about the 10 most important patterns for SOA success.|
The exciting world of ITIL metrics.|
Service-oriented Architecture (SOA) is as simple as can be — it can all be boiled down to these 9 principles.|
Imagine your hardcore IT geek talking to a company executive. What would they talk about? |