Feeds

back to article 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 …

COMMENTS

This topic is closed for new posts.
Pirate

A repeating pattern

Actually, ERP was there before "canned applications" - it was easy when applications were built in-house. I designed one in 70's, huge insurance company, 18K applications and all what was needed just one API wherever resources (money mostly) was moved. The management had "real time" view, the checks and balances automatically reflected for any systems, etc.

But, as the article says, then came the clueless spending on "canned applications" and the whole system came obsolete, more and more was missing from total! Total chaos after a couple of years, more spending on "special" applications, more people needed to manually do what was already automated, and so on. And one day they couldn't any more manage it, sale time. What's new?

0
0
Anonymous Coward

and also....

You ask some excellent "white elephant in the room" questions. I do like the concrete comment especially. I was part of a big system vendor during the boom period of SAP/ERP/BPR at the turn of 2000 and was stunned by the desperate rush to throw cash at IT software vendors in order to make the customers company run the same as the software told them it should. The consultants advising made massive fees as well as the product vendors. They were even told they would have reduced operational efficiency for 1-3 years during adoption.

I would like to add one more sacrifice on the bonfire, outsourcing. Tightly connected to the deployment of these juggernauts was outsourcing and if you want to ask a certain large grocery provider about their experience I would be stunned if you can get anyone to go on record. The famous no-milk/bread moment was down to a complete FUBAR between so called enterprise applications with the added piquant flavour of outsourcing.

I still fail to understand how passing the operational control of a live, constantly changing business through a legal contract to an outsourced for-profit company can benefit operational flexibility and continual process improvement. If the market changes and you want to move first/fast show me a benefit of outsourcing other than sacking people to reduce costs and capability.

ERP is an excellent concept and having watched the degree of detail and engineering SAP placed into their product I can only say I am stunned by the quality. Outsourcing of some functions makes solid sense, static, repetitive, non-critical, non-secure but your entire business process engine ?

I guess a thousand IT consultants will flame me to hell. I guess I must just be to cynical.

0
0
Anonymous Coward

Software

I don't t think this problem is unique to the kind of business management software that you are referring to. I think it's a problem with software as a whole.

If you look back at what was going on the 70's, stuff was being created that was routinely and genuinely unique and innovative.

What's happened since? Our OS's are basically the same as they were back then (only slower, less reliable, and HUGE). Applications have gone the same way - WHY does my word processor require half a GB of code when all I want to do is write a letter? It's ridiculous. Same goes for all the other usual suspects - spreadsheets, databases, etc etc.

Your average ERP package has faired no better. They are generally enormous, hugely complex, and cost a fortune. Most people who work with this stuff have a few horror stories to tell and pretty much everyone who uses one will have a good list of daily complaints and groans ("Why does it work like bla - that's silly!").

While hardware speeds and capacities have raced ahead over the last 20 years or so, software in general seems to have grown in size but little else. It's certainly not "better". It might be bigger and it might be able to handle more data in more complex ways, but that's mostly just making use of the hardware that's available. It's not easier. It certainly isn't simpler. And (as you point out) is still often very inflexible (or any flexibility comes at an often large premium).

So no, we have not progressed. In fact, I think we've been going backwards for a long time.

0
0
Flame

In other words, CS people are muppets

As an engineer, if there's one thing I'm consistently impressed/depressed by, it's the Computer Science crowd's ability to get money for old rope by putting new acronyms on the rope and painting its box a different colour. Their actual ability to deliver a working product is no greater now than it was 20 years ago when we were all forced to draw Jackson Structure Diagrams. Remember them? Every software department in the world foisted them on its students in the belief that they were the perfect solution, because that's what CompSci said, and they're the experts, right? Jackson later admitted that they were a dismal failure... "but look folks, here's a new set of diagrams and processes I've invented which *is* the right solution! And here's the tie-in book for them!"

"Wow, great!" shout the CompSci folk. "Where do we sign up to take it up the bum from another process shitwit?! I'm all Vaselined up and ready for it!"

There's a difference between engineering and CompSci. Engineering, you never lose sight of the fact that there's a real piece of equipment that needs to do something. CompSci, they're too busy arsing around with the latest buzzword processes/methods/tools to actually make something, and if they do make something, it's pretty much guaranteed to run like a three-legged dog, because the CompSci folks have put all their effort into the layers of overheads and indirection instead of in actually making something to work.

0
0

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

0
0

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.

0
0
Pirate

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?

0
0
This topic is closed for new posts.