Hij zegt oa:
"At the core of those new technologies is an object-oriented approach that severs the dependence on SQL database tables at the heart of much of the brittleness of current ERP software. Back in the early 1990s, I worked for a small business owner that wanted to harness the new-found power of SQL query language and 4GL programming languages to build his company’s business systems. The company was a PC reseller, so it wanted to manage customers, orders, sales commissions, suppliers. The first step was to decide in advance how to structure the data: there had to be a table called ‘orgs’ that identified each business the company deal with; and then various tables of the different kinds of business could be joined to the ‘orgs’ table — suppliers, customers and so on.
At the time, this was a breathtakingly elegant and powerful way to map a business’s data. Yet I couldn’t help wondering what would happen if some business need came along that required a table you hadn’t defined into the original SQL database structure. Surely you were building in a significant hostage to fortune?"
En verderop:"The breakthrough that Workday achieves is to move away from a fixed database structure. The SQL database in a traditional business management application defines the meaning of data into the table structure, and that is its achilles’ heel. Workday’s database tables reflect the needs of the object-oriented application architecture — there are just three tables, for ‘instances’, attributes’ and ‘references’ — and the data and definitions stored in the table are instantiated only when the application runs. The definitions are therefore as easy to change as the data.
When I use terms like ‘instantiated’ I’m slipping into the language of object management. At the heart of Workday is an object management server (OMS) — 30,000 lines of Java code that runs as an Apache Tomcat process, entirely in memory. When the Workday application runs, it scoops up all the data and definitions stored in that three-table database and turns them into meaningful data that can be accessed and manipulated. Changing the business logic — even at a very fundamental level — is simply a matter of changing a few definitions and re-running the application. Workday’s favorite demonstration of this capability is showing how it’s possible to reorganize the structure of your business on the fly, without recoding. In fact, Workday’s application developers never write code. They simply work with the 40 or so object types that have been built into the application, and define and instantiate them as required."
Hmmm, ik weet niet of ik hier zo weg van ben.Om te beginnen: Phil maakt geen onderscheid tussen twee verschillende rigiditeiten:
1. de rigiditeit die voortvloeit uit de problematische wijzigbaarheid van het model in een 4GL-omgeving. Die was er inderdaad, en voor een deel hing die samen met het feit dat er eigenlijk alleen een datamodel was, waaraan de rest hing.
Het gebruik van oject-modellering lost dat probleem op.
Maar een deel van de moeilijke wijzigbaarheid van een business-model wordt niet veroorzaakt door de modelleertechniek, maar door de aard van het model zelf.
In dit geval ben ik bang dat de Workday-modellen ook niet zo makkelijk te wijzigen zijn. O ja, technisch wel, maar de (semantische) consistentie moet ook verzekerd zijn.
2. de rigiditeit die voortvloeit uit het feit dat tussen het model en de werkende code een compilatie oid. zit. Als dat het probleem is, dan is de oplossing om alles te maken, zoals Workday heeft gedaan, de juiste. Maar is dat het probleem? En is het dan nodig te volstaan met een bare-bones-metamodel met alleen classes, attriuten en relaties?
Zo te horen heeft Workday Smalltalk weer eens uitgevonden. Dat was en is een fantastische taal en omgeving, maar schaalbaarheid was altijd een probleem. En of dat nu zoveel anders is?
Belangrijker: het is niet nodig. Een implementatie bv op basis van de color-modellen zou mooier, minder riskant, en handiger voor het modelleren zijn geweest.
Geen opmerkingen:
Een reactie posten