Looking back at packaged application rigidity and lock-in

When packaged applications first appeared on the scene a quarter of a century ago, it was normal for them to be very proprietary in nature.

Modifications and extensions were generally implemented through toolsets and programming languages that were each specific to the application concerned. Integration between systems was typically achieved through batch import/export mechanisms, or, if you were lucky, by accessing non-standard APIs from one of the few supported programming environments.

If you were really brave, you might bypass the application itself and access its underlying database directly. That was definitely not something for the faint of heart to attempt, however.

As a result of all this, by the time we hit the early 90s, many organisations were running their business on a tangled mess of heavily tailored packages. These would be hardwired together in various ways to create a brittle application landscape that cost a fortune to maintain and ran the risk of breaking at the slightest knock.

Indeed, many such application infrastructures did frequently break. Some organisations lived in constant fear of business operations being brought to their knees because of another software failure or dodgy interface.

It was at this point that the concept of Enterprise Resource Planning (ERP) came charging in like a knight in shining armour. The basic idea was to replace all of those individual systems and the interfaces between them with a single all-encompassing suite of software. With one database, data model and process model underpinning everything, all of the functions would work together seamlessly. Enter a new transaction into the sales order processing part of the system, and it automatically popped up in the logistics function to drive shipment, and the accounts payable function to prompt invoicing.

This certainly moved the game forward and solved some immediate problems for many organisations, but in hindsight, the ERP revolution just led to a different set of constraints. The hard-wiring between functions was now done by a combination of the software vendor and the consulting firm responsible for the implementation, instead of the customer. The problem of rigidity was often still there, but now there was the added complication of a greater dependency on third parties.

In larger organisations, the integration issues didn’t go away by any stretch of the imagination. It was not uncommon for multiple installations of ERP solutions to be created, each serving the needs of a different division or subsidiary, sometimes based on the same package, but often on alternative solutions. As CRM then exploded onto the scene in the late 90’s, along with many other packaged solutions, application integration came back with a vengeance, just manifested at a higher level.

Since then, we have seen Enterprise Application Integration (EAI) ‘hubs’ come and go, but only to be replaced by various other forms of ‘glue’ – from Business Process Management (BPM), workflow and ‘orchestration’ engines, through to Enterprise Service Buses (ESBs) facilitating exchanges between systems based on Service Oriented Architecture (SOA) principles. You might regard this as acronym heaven or buzzword hell depending on whether you are a software marketing person or one of the rest of us just trying to get stuff working together without tying ourselves up in knots. Or, as some would put it, pouring concrete over our business processes.

With all this going on, and every application vendor claiming the next major release of its package is more flexible and open than ever, are things really getting any better? We know that some vendors are ploughing many millions of their customers’ maintenance fees into re-engineering their software.

Are they succeeding in making your life any easier or protecting your organisation’s investment? And from a requirements perspective, as we solve one set of issues – such as integration behind the firewall – do others arise, e.g. dealing with cross-border transaction processing up and down supply chains while managing security, access and information integrity?