In een Asterix-verhaal (ik geloof Asterix en het 1ste legioen) komt een scene voor waarin een aantal "barbaren" dienst neemt in het romeinse leger. Ze moeten gekeurd worden, en ontdoen zich dus van hun diverse kledij. Er is ook een Goth bij, die een ontzettend martiaal berevel draagt, en er deswege zeer indrukwekkend uitziet. Bij die keuring echter blijkt uit dat berevel een buitengewoon schriel mannetje te stappen. Zonder berevel blaas je 'm zo om.
Ik moet aan dat beeld nogal eens denken als het gaat om de extractie van business-logica uit legacy. In legacy-systemen is erg veel geld, soms tientallen miljoenen, gestoken. En we hebben dus ook het idee dat die business-logica dus ook wel een forse omvang zal hebben. En menig bedrijf vleit zich ook met de gedachte dat dit "unieke" business-logica is, en daarom van nog grotere waarde.
Echter, als we die business-logica uit het legacy-systeem halen, en ontdaan van redundantie, code die nodig is voor de gekozen architectuur (database-benadering, scherm-afhandeling, transactieonele integriteit, enz) eruit halen, dan blijft er doorgaans een mooi en overzichtelijk business-model over. Een systeem van 600.000 regels code blijkt dan samen te vatten in een model van 27 classes. En een zeer groot deel van die 27 classes blijkt ook nog eens uiterst generiek te zijn: ze zijn vrijwel helemaal ook van toepassing op een willekeurig ander bedrijf.
Met andere woorden: de echte business-logica is slechts een zeer klein deel van een systeem (althans gemeten in regels code), en ook nog eens voor een klein deel uniek.
Nou gaat dit alleen om de business-logica, en die andere code is ook nodig. De database moet benaderd worden, de schermen moeten worden afgehandeld, enzovoort. Het berevel was wel nodig. Maar die architectuur-logica geldt voor alle systemen, en vrijwel al die code zou, mits goed gescheiden van de business-logica, kunnen worden hergebruikt. En met MDA/D/E kan dat.
Dus: als we in staat zijn om:
- generieke business-logica te hergebruiken
en
- software benodigd om de business-logica in de gewenste architectuur te hergebruiken
dan kunnen we bestaande systemen vervangen voor een fractie van de investeringen in het legacy-systeem.
En als we dan ook nog eens de voordelen die SaaS in dit verband biedt (centraal beheer, delen van kosten over vele gebruikers) in acht nemen, dan leidt dat tot een onrustbarende maar waarschijnlijk onontkoombare conclusie: de vervangingswaarde (en daarmee de economische waarde) van veel bestaande software ligt ver, ver beneden de waarde waarvoor de software in de boeken staat, laat staan de som van de investeringen.
Oeps. Betekent dat nou dat we al die jaren niks nuttigs hebben bereikt? Nee, natuurlijk niet. Er waren toen geen betere mogelijkheden. Maar dat is geen reden om onze kop in het zand te steken. Het kan nu wel anders.
Moet dat dan onmiddellijk gebeuren? Nee. Als een legacy-systeem goed werkt, dan zijn meestal de operationele kosten laag. Vervanging is dan lang niet altijd economisch zinvol.
Maar dat laat onverlet dat de consequenties van "functionaliteit uit de muur" verbijsterend zijn.
Abonneren op:
Reacties posten (Atom)
1 opmerking:
Mat,
Wat is in je verhaal precies de scope van "architectuurlogica"?
In welk begrip zit alles wat met BPM te maken heeft? BPM omvat in legacy applicatie veel code en is m.i. niet herbruikbaar.
Verder heb ik beeld bij je stellingen.
Een reactie posten