In dit artikel, het eerste van twee opinieartikelen, wordt betoogd dat de 5GL (fifth generation language) geruisloos zijn intrede op de markt aan het maken is. Er wordt uiteengezet wat een 5GL is en dat realisatie van bedrijfslogica met 3GL en/of 4GL (third en fourth generation languages) daardoor overbodig wordt.
André Hartman van Progress Software heeft in twee opinieartikelen met als titel ‘4GL springlevend’ (Computable van 25 augustus 2006 en 6 oktober 2006) betoogd dat softwareontwikkeling met een mix van 3GL en 4GL zinvol kan zijn. Vanwege de beduidend hogere productiviteit en flexibiliteit wordt gebruik van een 4GL aanbevolen voor realisatie van de bedrijfslogica in zakelijke applicaties.
In zijn slotwoord over de toekomstige ontwikkelingen op het gebied van ontwikkeltalen stelt André Hartman dat de software-industrie wat dit betreft eigenlijk stilstaat en dat er nog geen zicht is op de volgende stap die men 5GL zou kunnen noemen. Het wordt volgens hem hoog tijd dat iemand een briljant idee heeft dat de basis kan vormen van 5GL-producten, die een grote stap voorwaarts moeten zijn in productiviteit, en kwaliteit, kosten en het tempo van de softwareontwikkeling naar een volgend niveau moeten tillen.
Traditionele software-industrie
Zoals in dit artikel wordt aangetoond zijn de briljante ideeën die de basis vormen van 5GL-producten al tientallen jaren geleden bedacht. In het volgende artikel zal worden aangetoond dat moderne zakelijke toepassingen in toenemende mate met een 5GL worden gerealiseerd. Een belangrijke drijfveer hiervoor is de steeds hogere wendbaarheid en transparantie die de business en daarmee ook de zakelijke toepassingen ten toon moeten spreiden. Softwareontwikkeling door techneuten, ook met een 4GL in een moderne gestroomlijnde modelgedreven software factory, is domweg te star en te traag om het vereiste hoge verandertempo van de business bij te houden. Er is sprake van schieten op een accelererend doel en dat is bijna onmogelijk met een kanon dat eerst uitgebreid in stelling moet worden gebracht.
Het probleem met softwareontwikkeling wordt nog veel nijpender omdat steeds meer bedrijfslogica op moet worden genomen in zakelijke toepassingen. Dit komt door de toenemende mate waarin primaire klantgerichte bedrijfsprocessen van verkoop tot levering geautomatiseerd moeten worden. Bovendien moet meer en meer achteraf kunnen worden verantwoord dat men zich aan de (wettelijke) regels heeft gehouden en dat is knap lastig als de regels nagenoeg onherkenbaar en onvindbaar zijn begraven in de softwarecode.
De traditionele software-industrie is hierdoor aan het einde van zijn Latijn gekomen: de rek is eruit en het wordt tijd voor een oplossing in een andere richting.
5GL komt uit onverwachterichting
De 5GL is dan ook geen ontwikkeltaal voor software engineers, maar wordt gebruikt door op de bedrijfspraktijk gerichte analisten, die het beste kunnen worden aangeduid als ‘business engineer’, ofwel mensen die met een engineeringbril op naar de business kijken. Dit verklaart waarom de opkomst van de 5GL over het hoofd wordt gezien als men een volgende generatie programmeertaal voor softwareontwikkeling had verwacht. Men kijkt dan gewoonweg de verkeerde kant op. De 5GL is een taal voor businessontwikkeling en wordt gebruikt door ‘business engineers’ onder verantwoordelijkheid van de business. Ict verdwijnt eindelijk onder de motorkap, de veel besproken business-it alignement is niet meer nodig en it-business architecten kunnen over enkele jaren met pensioen.
De 5GL blijkt zich in de hedendaagse praktijk te manifesteren als een combinatie van wat in de markt wordt aangeduid als business process management (bpm) en business rules management (brm). Als bpm en brm hecht worden geïntegreerd met als ambitie realisatie van volledige geïntegreerde zakelijke toepassingen, is het resultaat een volwaardige 5GL. Dit is geen theorie, maar wordt in de alledaagse praktijk al bewezen met indrukwekkende resultaten voor de business, zowel op het gebied van productiviteit als van wendbaarheid en transparantie.
Wat is een 5GL?
Wat in de tachtiger jaren door James Martin is aangeduid als een 4GL slaat eigenlijk op een 5GL. Hij had het in dit verband over niet-procedurele specificatietalen op hoog niveau. De gebruikelijke 4GL’s voldoen niet aan dit criterium vanwege het volledig procedurele en algoritmische karakter van de specificatie van bedrijfslogica. Het onderscheidende kenmerk van een 5GL is juist dat in belangrijke mate alleen de regels en randvoorwaarden hoeven te worden gespecificeerd waaraan de oplossing van het probleem moet voldoen. Er is sprake van een vergaande declaratieve (niet-procedurele) specificatie van bedrijfslogica. De procedure die moet worden gevolgd voor het oplossen van het probleem kan grotendeels in het midden worden gelaten.
Door de introductie van een databank werden data in de jaren tachtig gescheiden van de algoritmen in de software. Bij een 5GL wordt dat ook gedaan met de bedrijfslogica. Naast een databank is er dan sprake van een kennisbank. De bedrijfslogica wordt nu aangeduid als bedrijfskennis of bedrijfsregels. Wat resteert aan de kant van de software is een generieke softwaremodule die uitgaande van de vraag zelf de weg naar het antwoord zoekt, gebruikmakend van de toepasselijke regels in de kennisbank.
De specificatie van een bedrijfsregel kan hierbij automatisch als foutmelding worden gebruikt bij dreigende overtreding van de regel.
Bovendien kan de computer nu gaandeweg verklaren waarom bepaalde gegevens worden gevraagd en achteraf uitleggen hoe de voorgestelde oplossing aan de regels en randvoorwaarden voldoet. Dit laatste vormt de natuurlijke oplossing voor compliance.
Het is al met al niet verwonderlijk dat het idee van een 5GL afkomstig is uit de hoek van de kunstmatige intelligentie. De computer vindt immers zelf een oplossing voor het probleem in plaats van dat deze vooraf precies geïnstrueerd moet worden over de te volgen procedure.
Een belangrijk verschil tussen een 4GL en 5GL is verder dat een 4GL primair bedoeld is voor dataprocessing ofwel de traditionele automatisering van kaartenbakken. Een 5GL is echter primair bedoeld voor het geautomatiseerd vinden van oplossingen voor problemen en het nemen van beslissingen en is daardoor een veel krachtiger hulpmiddel voor de automatisering van bedrijfslogica dan een 4GL.
In de laatste twee decennia van de vorige eeuw is er veel geëxperimenteerd met algemeen bruikbare 5GL’s, zoals Prolog en OPS5, en met gespecialiseerde 5GL’s, zoals G2 en AionDS. Vooral met de gespecialiseerde 5GL’s zijn in de loop van de tijd vele succesvolle, op zichzelf staande toepassingen gerealiseerd. Deze zogenaamde kennissystemen zijn ingezet bij het nemen van beslissingen, zoals de acceptatie van hypotheekaanvragen. Er was echter nog geen sprake van kennisgebaseerde ondersteuning van de uitvoering van volledige bedrijfsprocessen. De 5GL was nog niet breed inzetbaar en gebruik ervan bleef beperkt tot tamelijk op zichzelf staande toepassingen in specialistische niches. Nederland is hierbij vanaf het eerste uur een onbetwiste koploper geweest en gebleven. Dit gebeurde destijds onder de vlag van ‘knowledge engineering’ en kennistechnologie.
Hoe ziet de ideale wereld met een 5GL eruit?
De ideale wereld met een 5GL wordt afgebeeld in de figuur op pagina 16.
De 5GL manifesteert zich als een ‘business engineering studio’ waarmee ‘business engineers’ in nauwe samenwerking met ‘business specialisten’ op grotendeels declaratieve wijze bedrijfskennis eenduidig vastleggen . De ‘business engineering studio’ biedt faciliteiten om de ‘bedrijfskennis’ direct te valideren (klopt het inhoudelijk) en verifiëren (is het correct en consistent).
Het begrip ‘bedrijfskennis’ beperkt zich hierbij niet tot wat traditioneel wordt aangeduid als bedrijfslogica, maar strekt zich uit tot bedrijfsprocessen, producten, validatieregels, acceptatieregels, domeinconcepten en interactie met zowel gebruikers als (services van) systemen. Op basis hiervan kan dan ook de volledige uitvoering van bedrijfsprocessen met onderliggende taken op een kennisgebaseerde manier worden ondersteund en zelfs vergaand worden geautomatiseerd.
De ‘bedrijfskennis’ wordt opgeslagen in een ‘business content repository’, ook wel aangeduid als kennisbank. Er is sprake van generieke ‘business engines’, die de benodigde business content op het juiste moment weten te vinden in de repository en deze vervolgens automatisch weten toe te passen. Hierdoor is dezelfde business content zowel te begrijpen door mensen (via de ‘business engineering studio’) als toepasbaar door de computer. Daarom kan er direct worden gesimuleerd en getest door de ‘business engineer’ en de ‘business specialist’. Er is geen onderscheid meer tussen simuleren en testen. Bovendien is er geen tolk (programmeur) meer nodig om een vertaalslag te maken naar een technische taal (3/4GL) waar de computer van oudsher wat mee kon. Er is zodoende geen behoefte meer aan dure en vertragende software factories (al dan niet offshore) voor de realisatie van specifieke ‘bedrijfskennis’ in computertoepassingen.
De business content kan worden vergeleken met executeerbare formele functionele requirements. Het functionele model is de oplossing, in plaats van dat het de basis vormt voor realisatie van de oplossing.
Waarom maakt MDA het ideaal niet waar?
Veel ict’ers geloven (nog) dat modelgedreven architectuur (mda) voor softwareontwikkeling de oplossing uit de eerder genoemde impasse voor ict zal bieden. Mda impliceert dat er vanuit een technologieonafhankelijk functioneel model en systeemontwerp, code voor een specifiek technisch platform wordt gegenereerd en handmatig wordt aangevuld. Op het niveau van model/ontwerp kan er in het beste geval worden gesimuleerd met ‘executable UML’ en zelfs dat staat nog in de kinderschoenen.
Bij toepassing van mda is zodoende nog steeds sprake van een gecompliceerde en daarmee vertragende technische vertaalslag met bijbehorende verder vertragende distributie van executables. Het probleem dat er pas in een (veel) te laat stadium kan worden getest, bestaat zodoende nog steeds.
Bovendien impliceert modelgedreven ontwikkelen een hoge mate van voorspelbaarheid van het eindresultaat. Bij de steeds sneller wijzigende bedrijfsvoering van vandaag is er steeds minder sprake van voorspelbaarheid. Daarom neemt de behoefte aan evolutionair ontwikkelen en veranderen toe. Een 5GL ondersteunt dit van nature.
Een en ander betekent een organisatorische revolutie aan zowel de kant van de business als die van de ict. Enerzijds moet de business de verantwoordelijkheid op zich gaan nemen voor eenduidige vastlegging en beheer van zijn bedrijfskennis. Anderzijds wordt ict volledig ontkoppeld van de veranderprocessen in de business en raakt zo het werk in de vorm van programmeren van specifieke ‘bedrijfskennis’ kwijt.
In de komende jaren ligt het werk voor ‘business engineers’ met veel materiekennis voor het oprapen. Dit wordt helaas nog nauwelijks onderkend aan de kant van de opleidingen en al helemaal niet bij de aankomende studenten. Het wordt hoog tijd dat de term ‘informatica’ wordt vervangen door ‘busimatica’.
Toch is er ook voor software engineers nog het nodige werk aan de winkel. De verdere ontwikkeling van zowel de ‘business engineering studio’ als van de ‘business engines’, vergt het onderste uit de kan van de beste software engineers. Daarnaast zijn software engineers betrokken bij de integratie met andere systemen en bij de omzetting van de interactiecontent naar de gewenste presentatie.
Leo Hermans, Getronics Everest
Een systeem zonder architectuur?
In het artikel ‘5GL springlevend’ (Computable 5, 2 februari 2007) wil de auteur ons doen geloven dat hij de ‘silver bullet’ voor Software Engineering gevonden heeft: de 5GL. Met een 5GL is het mogelijk om de bedrijfsregels te specificeren en daarmee de impasse waar de IT volgens de auteur momenteel in zit te doorbreken. Het functionele model staat centraal en de kennisbank (ofwel business content repository) vormt het hart van de bedrijfsapplicatie.
Nu ben ik het volledig eens met de auteur wanneer hij spreekt over het lostrekken van bedrijfsregels van de rest van de applicatie. Een prima idee, maar – zoals hij zelf ook al aangeeft – niets nieuws onder de zon. De bedrijfsregels vormen inderdaad een onderdeel dat je liever niet met de rest van de code vermengt. Maar om business rule en business process modeling als 5GL als een complete, generieke oplossing voor hedendaagse bedrijfsapplicatieontwikkeling te bestempelen, gaat wat mij betreft te ver.
De eerste reden hiervoor is dat het in de meeste systemen nog steeds om de administratie van gegevens draait. Bij bijvoorbeeld banken, verzekeringsmaatschappijen, webshops en luchtvaartmaatschappijen gaat het toch veelal en voornamelijk om de juiste afhandeling van gegevens en transacties. Het lijkt dan ook verstandig om een aanpak te kiezen die het inkapselen van gegevens centraal stelt. Een goede modelering van bedrijfsentiteiten is dan ook essentieel voor de succesvolle ontwikkeling van dergelijke systemen.
De tweede reden is dat niet-functionele eisen nog altijd een zeer belangrijke rol spelen in de hedendaagse applicatieontwikkeling. De performance van een systeem, het aantal transacties dat op piekuren moet worden verwerkt, de beveiliging zodra het aangeboden wordt op internet, de usability van een systeem of het ontsluiten van functionaliteit via services (SOA) zijn allemaal voorbeelden van niet-functionele eisen. Deze eisen zijn zeer moeilijk te specificeren in een functionele 5GL-taal. De softwarearchitectuur is een veel geschikter vehikel om te specificeren hoe aan niet-functionele requirements kan worden voldaan. En het mooie van een modelgedreven aanpak (MDA) is dat een software factory kan worden ingezet om de keuze van de architectuur meer onafhankelijk te maken van het eerder genoemde business model. Tevens kan bij een geautomatiseerde software factory een heel groot deel van de architecturale code worden gegeneerd zodat alsnog de beoogde productiviteitswinst wordt behaald.
Helaas noemt de auteur in zijn artikel MDA een vertragende vertaalslag en schildert hij deze aanpak af als niet evolutionair. Dit ligt echter ver weg van de realiteit die ik zie bij bedrijven die modelgedreven applicatieontwikkeling inzetten. In feite passen de (5GL) bedrijfsregels uitstekend als n van de DSLs (Domain Specific Languages) in een modelgedreven aanpak. Juist door de scheiding tussen het bedrijfsmodel, de bedrijfsregels en de technische softwarearchitectuur is het mogelijk om via een iteratieve, lichtgewichte methode een systeem te ontwikkelen. Maar nu met als grote voordeel dat je met MDA wel controle over de architectuur hebt en dus over die o zo belangrijke niet-functionele eisen.
Bastiaan Schönhage, product manager Compuware
Hierbij mijn reactie als auteur op de reactie “een systeem zonder architectuur”.
Natuurlijk impliceert een moderne 5GL een heleboel technische architectuur en MDA onder de motorkap. Het bijzondere is dat vergaand geautomatiseerde bedrijfsprocessen (met veel geautomatiseerde business beslissingen) nagenoeg volledig (inclusief intelligente interactie met gebruikers en dus niet alleen bedrijfsregels in de enge zin) gemaakt kunnen worden door op de business gerichte engineers. Voor realisatie van meer dan 80 procent van de bedrijfslogica blijkt geen beroep meer te hoeven worden gedaan op software engineers en MDA (het formele functionele model is de oplossing i.p.v. een model dat nog een gecompliceerde en daarmee vertragende en foutgevoelige technische vertaalslag moet ondergaan).
Bij eenmalige installatie van het generieke onderliggende platform met de business engines, wordt uiteraard de nodige architecturele embedding en technische tuning uitgevoerd. Dit legt dan de technische basis voor een hele reeks business applicaties gemaakt door business engineers. Het zeer complexe generieke platform met de business engines wordt ontwikkeld door zeer capabele software engineers en daarbij speelt MDA een belangrijke rol (maar dus niet meer bij de realisatie van een specifieke applicatie).
De aansluiting bij de reeds aanwezige administratieve systemen wordt gerealiseerd via services. Hierbij zijn ook weer de nodige bedrijfsregels betrokken, die uiteraard ook door business engineers moeten kunnen worden beheerd. Bij vergaande transparante automatisering van bedrijfsprocessen worden de gegevens ondergeschikt en horen juist de bedrijfs(beslis)regels centraal te staan.
5GL niet de volgende stap na 4GL
In de twee artikelen ‘5GL springlevend’ van Leo Hermans wordt 5GL ten tonele gevoerd als de ‘heilige graal’ voor de wereld van de softwareontwikkeling. Daarin schetst Hermans een scenario waarin de rol van de programmeur definitief ‘end-of-life’ is, mede doordat ‘softwareontwikkeling door techneuten te traag [is] om het hoge verandertempo bij te houden’.
Wat is het toch soms lekker om te dagdromen zonder zorgen over de verantwoordelijkheid van een software development-manager om kwaliteitscode op te leveren die funktioneel doet wat eindgebruikers willen, met de performance en beschikbaarheid die past binnen een vooraf vastgestelde SLA.
Binnen de 5GL-dagdroom is een centrale rol weggelegd voor Business Process Management (BPM) en Business Rule Management (BRM). Die aandacht is prima, want elk tool en elke methode die kunnen helpen om in de analysefase beter vast te leggen wat de business nou echt wil hebben, is meegenomen. Want binnen het ontwikkelproces neemt de analysefase verhoudingsgewijs steeds meer tijd in beslag. Als de eindgebruikers niet actief meedoen in het ontwikkeltraject door middel van RAD-sessies, kan die voorfase soms wel tot 50 procent van de tijd vragen.
Echter, onder de tijdsdruk waar ook Hermans naar verwijst, lijkt steeds vaker voorbij te worden gegaan aan het aloude credo ‘eerst organiseren, dan automatiseren’. Er wordt te snel naar een tool gegrepen alsof die alle problemen oplost. Om bijvoorbeeld straight through processing en self service-concepten door te kunnen voeren, is het belangrijk om niet de huidge processen in een tool vast te leggen, maar om vooraleerst samen met de business te kijken naar de meest simpele vorm van een proces en het vereenvoudigen van de business rules. Ik durf de stelling aan dat een organisatie zo hard aan vereenvoudiging moet werken dat ze geen BPM en BRM tool nodig heeft. Lukt dit niet, dan is het nog steeds te complex.
De hiervoor beschreven aanpak sluit ook naadloos aan bij het concept van de Real Time Infrastructure (RTI), zoals Gartner dat heeft beschreven. Hierbij is de belangrijkste uitdaging op alle onderdelen van IT te komen tot een zo simpel mogelijke invulling, gebaseerd op open standaarden. Hierbij hoort naast het verminderen van het aantal servers ook het verminderen van het aantal applicatieontwikkelomgevingen, het verminderen in plaats van vergroten van het aantal tools en het vereenvoudigen van applicatiearchitecturen, bedrijfsprocessen en het verminderen van het aantal applicaties binnen het applicatieportfolio.
In het licht van de moeite die sommige organisaties hebben met applicatie-integratieprojecten of het implementeren van een enterprise service bus ten behoeve van een SOA-project, is het eerst uitvoeren van een RTI-project het beste advies. Eerst vereenvoudigen, daarna pas denken aan software ontwikkelen. Mits goed uitgevoerd,
zorgt een dergelijk project ervoor dat business-processen en business rules weer overzichtelijk worden en daarmee de applicatieontwikkeling samen met eindgebruikers een feest.
Ik zie de besproken ‘5GL’s’ meer als analyse- en documentatie-tools. Met sommige produkten kan een beslissingsboom opgezet worden voor een front office-applicatie, zodat bijvoorbeeld de genoemde automatische hypotheekaanvraag gerealiseerd kan worden. Om die producten echter een 5GL te noemen gaat veel te ver.
In de situaties waarin nu 4GL’s worden gebruikt, zoals bij het bouwen van grote backoffice applicaties, liggen de eisen geheel anders. In zo’n grote omgeving van pakweg vijfduizend functiepunten of meer worden hoge eisen gesteld aan performance, applicatiebeschikbaarheid en een waterdichte recovery, zodat nooit een transactie verloren gaat. Zulke omvangrijke, kritische en complexe applicaties wil je toch niet laten bouwen door business engineers, maar door professionele softwarebouwers. Met het best mogelijke gereedschap dat er voor die klus is, een moderne 4GL, die business rules onderbrengt in callable global logic, ofwel re-usable code, centraal opgeslagen in een repository. En de sterk vereenvoudigde bedrijfsprocessen zijn onder te brengen in bijvoorbeeld BizTalk. Door deze combinatie wordt de gewenste wendbaarheid, agility, verkregen.
Een moderne 4GL maakt gebruik van of Eclipse of Visual Studio en bevat een repository waarin alle specificaties aan elkaar zijn gerelateerd, waardoor aanpassingen slechts op n plek hoeven te gebeuren. Dat is wel iets anders dan ontwikkelen met C# of Java, waarbij elk programma los van de andere opgeslagen wordt in een file-structuur.
Een dergelijke 4GL genereert vanuit het hoge abstractieniveau alle on-line en batch programma?s in C# en/of Java, zodat organisaties de keuze hebben qua productieplatform: Windows of Linux. Tevens kan zo’n 4GL uit diezelfde specificaties de databasspecificatie genereren. Hierdoor verdwijnt veel technologie onder de motorkap en kan de software ontwikkelaar zich concenteren op de functionele wensen van de eindgebruiker. En daar is het toch allemaal om begonnen.
Maarten Schneider
marketing manager AB Suite Unisys EMEA
maarten.schneider@unisys.com
Graag wil ik reageren op de eerste reactie, die typerend is voor wat we gewend zijn in applicatie-ontwikkeling: niets mis mee, maar het is een gemiste kans om de potentie van 5GL als ’te ver’ te bestempelen, zeker omdat we het hebben over een realiteit en niet louter een idee.
Het eerste argument, dat de meeste systemen om gegevens draaien, is op zichzelf een feit, maar wordt langzamerhand ingehaald door de noodzaak tot verantwoording van wat men met die gegevens doet. Verantwoording op basis van regelgeving noodzaakt bedrijven in toenemende mate om vast te leggen wat de bedrijfsregels zijn die men hanteert om de gegevens te bewerken. Kortom, het argument van gegevens-centrisme is inmiddels ingehaald door de prioriteit van verantwoording.
De tweede reden betreffende het belang van niet-functionele eisen is inmiddels ook ingehaald. In dit geval door de software leveranciers. Die hebben de laatste jaren niet stilgezeten en hun conclusies getrokken t.a.v. de diversiteit aan niet-functionele eisen die telkens weer werden gesteld. Laten we wel wezen, het valt best wel mee met die diversiteit; we weten allemaal behoorlijk precies welke eisen er toe doen, en weten inmiddels ook de bandbreedtes waarbinnen de meeste domeinen zich begeven – het gaat immers zoals de auteur van het commentaar stelt vooral om administratieve systemen. Die verschillen zijn, op een enkele uitzondering na, niet zo verschrikkelijk groot. Daarnaast is ook standaardisatie van bijvoorbeeld user interfaces zover gevorderd dat specifieke eisen hierover niet meer nodig zijn. En wat je nu ziet is dat de meeste volwassen software leveranciers, zeker die van de met BPM en Rule engines verrijkte middleware, voorbereid zijn op alle gebruikelijke scenario’s. Daar hoeven architecten geen eisen meer aan te stellen, net zo min als je nog eisen moet stellen aan de functionaliteit van een tekstverwerker: het zijn commodities geworden.
Kortom, ik wil de auteur van het 5GL artikel ondersteunen in de opvatting dat het bedrijfsperspectief prioriteit krijgt en het enige wordt dat er nog toe doet. Dat is misschien wat zuur voor de applicatie-ontwikkelaars en architecten, die gewend waren allerlei technische overwegingen in hun structuren mee te nemen, wat dus in steeds mindere mate nodig blijkt te zijn. Daar staat tegenover dat de uitdaging om het bedrijfsperspectief op een formele manier te specificeren alleen maar groter wordt. Tenslotte wil ik de auteur van het 5GL artikel dan ook ondersteunen in de oproep om opleidingen te ontwikkelen en op de markt te brengen die gericht zijn op business engineering, een soort formele bedrijfskunde.
Alcedo Coenen, voorzitter werkgroep Business Rules van het Nederlands Architectuur Forum.
Hierbij wil ik als auteur van het originele artikel reageren op de reactie van Maarten Schneider van Unisys.
Dat er absoluut geen sprake is van dagdromen blijkt uit de praktijk van Everest waarin, m.b.v. onze 5GL Everest Framework en met de bijbehorende business-gedreven ontwikkelmethode, met groot succes bedrijfskritische FO/MO oplossingen voor de primaire processen zijn en worden gerealiseerd voor o.a. hypotheken en verzekeringen. Deze oplossingen worden grotendeels gerealiseerd door business engineers, met weinig of geen benul van software engineering maar met het nodige benul van de business. Daarbij wordt er zoals Maarten Schneider voorstaat, eerst georganiseerd en dan pas geautomatiseerd. Het gaat dan ook niet om optimalisatie van de huidige werkwijze, maar om innovatie van de business en haar diensten en producten met de bijbehorende processen. Dit komt dan ook tot uiting doordat de business veelal de opdrachtgever is en niet een ICT-afdeling.
Als ik Maarten Schneider moet geloven is de hedendaagse business eigenlijk zo simpel dat er volstaan zou moeten kunnen worden met traditionele gegevensverwerkende toepassingen gerealiseerd met een 4GL. Al dat ingewikkelde gedoe met betrekking tot klant- en partnergerichte genuanceerde personalisatie van procesgang en commercieel productaanbod zou dus faliekante onzin zijn. Typisch dat de commercie daar juist steeds zwaarder aan tilt, maar dat is ‘ver van mijn bed’ voor de techneuten in de backoffice. Zij maken zich vooral druk om de schijnzekerheid van functiepunten en niet-functionele eisen en in ieder geval niet om het faciliteren van de in een inherent onzekere wereld opererende business. De business moet zich maar aanpassen aan de beperkingen van de backoffice en anders kunnen ze het bekijken (de kleinste wijzigen hebben een onwaarschijnlijke doorlooptijd en kosten kapitalen, als men al bereid is om ze te realiseren). Het wordt hoog tijd dat ook de backoffice toepassingen worden gerealiseerd door business engineers m.b.v. een 5GL (op basis van een ketenbreed productmodel) en niet meer door businessvreemde techneuten die verstand hebben van business rules in callable global logic (hoe verzinnen ze het) en technisch gevogel met BizTalk (als BizTalk een ding niet doet is het praten in business taal).
In de praktijk is aangetoond dat ook de met een 5GL gerealiseerde oplossingen kunnen voldoen aan zware niet-functionele eisen. Omdat dit wordt gewaarborgd in de implementatie van het onderliggende generieke platform, hoeft hier per individuele business applicatie niet meer te worden geesteerd. En zo hoort het ook!
Bij Maarten Schneider is de crux van mijn betoog kennelijk niet helemaal goed overgekomen. Zolang er per applicatie nog technologie moet worden ingericht en gegenereerd is de technologie niet onder de motorkap verdwenen. Pas als het beschikbaar stellen van een nieuwe applicatie geen wijzigingen op technologisch vlak meer impliceert is er echt sprake van onder de motorkap stoppen van technologie. Dat is nu precies wat een 5GL onderscheidt van een 4GL of 7GL (3GL + 4GL, zie Computable van 9 februari). Het is dan ook juist niet ‘de software ontwikkelaar die zich moet kunnen concentreren op de functionele wensen van de gebruiker’, maar de business engineer die met het formeel modelleren van die functionele wensen direct de oplossing heeft gerealiseerd (het functionele model is bij een 5GL de oplossing!). Software ontwikkelaars kunnen net zoals hun technologie onder de motorkap blijven. Dat de complexe infrastructuur onder die motorkap tot in de puntjes geregeld moet worden door zeer bekwame software engineers staat buiten kijf.
Consultants en managers die denken het weer beter te weten hoe ze een applicatie moeten maken dan de programmeurs en software architecten.
Software architecten en programmeurs weten zeer goed hoe ze de architectuur van een applicatie flexibel op moeten opzetten. Daar heb je dat 5GL spul helemaal niet voor nodig.
Laten we a.u.b. ons beperken tot waar voor opgeleid zijn.
Evert Tigchelaar jr
Junior Software Engineer
De reactie van Evert Tigchelaar getuigt van het typische maar begrijpelijke onbegrip dat techneuten hebben voor een totaal andere, niet technische, manier van ontwikkelen van toepassingen (het is de bekende blindheid voor een nieuwe dimensie). Een 5GL maakt inzet van programmeurs en software architecten overbodig bij de ontwikkeling van een specifieke applicatie. Zij (en wel de meest capabele) zijn echter hard nodig voor de ontwikkeling en implementatie van de intelligente generieke business engines die de formele functionele modellen (gemaakt door business engineers en niet door software engineers) dynamisch kunnen executeren. Feitelijk is er zodoende sprake van business-IT alignment door een volledige scheiding teweeg te brengen tussen business en IT. De 5GL aanpak zou ook beschouwd kunnen worden als een vergaande vorm van content management (executeerbare bedrijfslogica in de vorm van content; W3C beweegt zich in deze richting met het “semantic web”).
Belangrijke trendwatchers zoals Gartner en Forrester onderkennen intussen ook dat het raadzaam is om specifieke business logica niet meer in software code te stoppen. Enkele uitspraken van Gartner (ITxpo 2006) zijn in dit verband:
* Fold knowledge into metadata so program logic can be stupid and robust;
* You can not code your way into the future;
* Move business volatility into data;
* Generic engines parse the metadata describing rules, processes, data and rendering.
Enkele uitspraken van Forrester (2006) zijn in dit verband:
* Digital Business Architecture is the future IT foundation for Business Flexibility;
* This implies a Business Metadata Core that describes processes, policies and structure;
* Enables rapid, intelligent, and efficient change to the operation of the business.
Laat me raden, zeker weer een uber-manager in krijtjespak met stropdas die dit artikel geschreven heeft.
Leer eens een echt vak en wordt eens een keer echt vakkundig, voor je zulke onzin uitkraamt!
Wat een onzin LOL!!!
@Werkbeoordeling, kijk eens waar je op reageert. Het is een artiekel van RUIM 2 jaar geleden.
Eigenlijk bega ik zelfde fout als jij doet door op jou te reageren.
U kunt het met het artikel van de auteur eens of oneens zijn, en daar inhoudelijk op reageren.
Ik ben zelf ook een ’techneut’en verdien mijn boterham met het ontwikkelen van financiele applicaties in een 4GL.
Ik ken de auteur van zeer nabij, en weet dat hij juist het tegendeel is van een uber-manager in krijtjespak.
Leo was juist iemand die een hekel had aan schreeuwende managers en commerciele ratten.
Leo was een zeer fijne zachtaardige man, die leefde voor zijn werk en collega’s en dit tot de laatste dag heeft gedaan.
Hij is 25 juli. jl. overleden als gevolg van een slopende ziekte en vandaag gecremeerd.
Hij verdient echt meer respect dan als een uber-manager in krijtjespak te worden bestempeld. Foei !