Hitting the wall - the destiny of enterprise software.

A wall named complexity. Overly complex and utterly self-inflicted.

The problem is banal but hard to overcome; it's the wrong choice of modelling method.

That method, thanks to the gentlemen in Venice 514 years ago and ne'er questioned, makes the complexity 100 times, nay, 400 times more complex than reality pure.

In reality a widget is a widget. One object.

Add "distance management" of the widget in a widget producing or consuming organisation and the double-entry bookkeeping monster roars, requiring precise representation of each and every transaction.

Every order, every task, every move, every change of colour or bent ear - all must be properly documented, then entered into the books or system.

In that model each widget is represented by invoices, purchase orders, sales orders, work orders, bills of lading, journals and reports. The widget itself does not "exist". A paper based model that never knew of modern IT.

But it does not have to be like this, we have IT now. Let a singular data-object represent a singular real-object, then capture the what, who and when onto itself. Not "what" as defined by some GAAP, but rather the "what" as in reality - now moved to warehouse B, now painted blue.
Transactions and events can thus be gleaned from changes to relations and properties: A change of the relation "is owned by" is often what legally constitutes a sale or purchase, thus useful for a (P&L say) report. A change to the relation "is located in" is useful to produce inventory reports at any time and so forth without limits. (This is what thingamy does of course, straight reality modelling albeit slightly enhanced.)
Most important result - one data-object only per real-object, simple as in reality. A reality-model.

So, let's do a simple calculation: Say you have 20 objects to handle, 20 real world things and for simplicity, each goes through ten transactions or events. Then relate them all, objects and transactions/events criss-crossing the organisational fabric.

Thus the maximum number of relations* for the two modelling methods pans out to be:

Reality model: 380 relations.
Transaction / event based model: 39'800 relations.

An increase in complexity over real-world complexity of 10'374%. Or about 105 times more complex.

Now do 100 objects each represented by 20 documented transactions and you'll have 403 times the complexity, an increase of 40'203%. That's how to complicate things in an efficient manner!

Of course systems creating such complexity are big and... eh... complex. They have to handle the self-inflicted transaction and event-based complexity. Selber schuld, kein mitleid as the Germans would say.

Use the reality model and you'll have a system that could be 105 times... eh... 403 times... eh... "better"? It might even avoid the wall.

Or...

Reconcile 39'800 relations instead of 380, query ten times more objects.
Handle fully formatted objects instead of raw data and buy more CPU power.
Save thousands times more manipulated data and bloat your DB size and query times freely.
Create processes for modern world corporations following constraints designed in Venice 514 years ago. Duh.

What can I say?

I can say one thing; forget about tweaking the current systems, you'll have to start over again. A car does not become an aeroplane by adding decals on the doors (SaaS anyone?).

* [n!/k!(n-k)!] where k=2 and relations are not symmetrical thus total is twice the number.

Comments

[iav]

Having worked on several large scale projects related to converting reporting from Local GAAPs to IFRS or to disentangling and de-consolidating multi-billion dollar business units, I fully agree that an object oriented approach would drastically simplify and accelerate those processes while leaving less room for errors and interpretations. Especially in companies running paleontologist-grade ERPs with un(der)-documented processes...