Looking back at packaged application rigidity and lock-in
Have we progressed that much in 25 years?
Steps to Take Before Choosing a Business Continuity Partner
Workshop 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?
Whether you have thoughts on any of these questions, just want to sound off because of your frustration, or maybe give us examples of how things really are getting better, we’d love to hear from you in the comment section below. ®
COMMENTS
Times
Tim S, you are right, even I have designed systems like yours.
But - and a big but, you really don't see the logistics behind that, so simple as for example taxes, varies by source, destination, product, etc - even worse pro-rated changes, changes to when sent or received, tolls, whatever. Now, add to that the currency changes, fluctuating daily or maybe hourly, non-payments, disputes, even returns (rules change, you know) and maybe changes in accounting laws, regulations, etc - again maybe pro-rated. And because you are VAR (or whatever), all these work on both sides, both on your providers and on your customers. Find me a software package which can handle all those including your house rules without a lot of re-work.
Believe me these were just the simple examples, systems change, infrastructure changes, vendors go out of business, service contracts fail every day, business grows and needs more resources, new laws are created which can change almost anything, knowledgeable people change jobs, get sick, retire, even die - your system is built for one OS which gets obsoleted and the vendor doesn't care, your system only supports one type of interfaces / browsers / etc which are found to be unpractical / unsafe / etc, the management wants to add new business functions, get new types of reporting, connect to new financial interfaces / institutions, whatever.
The current problem with ERP or whatever systems is that they are not achitected to (your) business needs (most often, not a rule) but try to force the business to follow the ways products work. These can be easily dealt when you design a system from your business perspective instead trying to force your business to match whatever is the current fad.
Some business is so volatile (dynamic) that I sometimes wonder (not much, another story!) how they can even think some outside system provider knowing better than they what they do / need?
Times We're Living In
The person who orders stuff for my department can do the following (I'm not omitting any steps):
1. Receive a part number for an item from CDW from me.
2. Login to our in-house purchasing website (running Oracle apps).
3. Select CDW.
4. Paste in the part number.
5. Select one of our department's accounts from a list with only our department's accounts.
5. Click the "purchase button".
The item arrives in under 48 hours, often under 24 hours. We don't have to do anymore accounting for this purchase - its tacked onto the right account, the money is deducted immediately. Later, he can easily create a report of everything that was purchased for that account, or when the purchase was made, etc. But in reality, once the "purchase" button is pressed, that's the end of it. For stuff that we can buy from one of our partners, there's no paper work when we get audited. There are no errors (we still check though.) We always get a price equal to or less than the one listed on CDW, and never pay shipping.
That's a small example, but it is fantastic for the end users. (Not all facets of the system work this nicely, but its indistinguishable from magic when things go right.) This might involve us paying with money that we haven't received yet, but the financing for all of this wrapped up nicely and we can shift the money around later if necessary. The Budget and Controller's office is happy, we're happy, the vendor is (presumably) happy.
Bottom line, we really do to do quite a bit without paper, without tedium. I don't think this could work without well tuned processing, well tightened plumbing, and top to bottom integration. People talk like we've been running on a treadmill for thirty years, but it may be they take for granted how smoothly things are capable of working.
BPM, ERP, and the challenges of increasing specialization in application software
Very interesting perspective. I think that part of the problem is that business and the technology needs of business have gotten much more specialized during the last decade. This has put a whole new level of stress on "tool" vendors because they often find that their tool does not come with everything the client needs.
One indication of this is the incredibly high percentage of solutions which are still home grown. If ERP and BPM solutions are so comprehensive, then why are so many CEOs/CIOs taking decisions to build their own applications? Are they just getting poor advice? Or are there too many confusing options to choose from? I don't think so.
I think it is because they are looking at the tool sets from their vendors and then saying, well, if I need to pay XYZ vendor $1 million to adapt the solution to my business, then why don't I just build something that is designed for my business from the ground up. After all, most of the money I am going to be spending will be spent on teaching the vendor about my business.
This is one of the great ironies. The tools have gotten better and better, and the tool vendors (my company included!) want to sell to more and more customers in order to keep growing the tool, but the business scenarios are growing at a faster rate and with more specialization.
Our answer to this is to keep the tool open. ProcessMaker is open source because we realize that BPM vendors just aren't meeting enough of the challenges out of the box. We believe that it is better to let those customers that really need something different to have access to the code so they can take the software in the direction they want to go. In this scenario, if a customer needs something truly different and they don't want consultants learning their business in order to create what they need, they can start with ProcessMaker and build an entirely new application if they want.
-Brian Reale
http://www.processmaker.com
IT infrastructure monitoring strategies
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Cloud based data management
Enabling efficient data center monitoring
Agentless Backup is Not a Myth
