From the Mist

In dit tweede deel wordt de structuur van het business domein component duidelijk gemaakt. Deel 1 behandelt de basisprincipes. Deel 3 gaat over de service architectuur koppeling.

Inleiding

Nadat de vorige keer een algemene structuur is geschetst van wat door mij genoemd wordt een domein- of business-centered architectuur, is het in dit artikel de bedoeling duidelijker te maken wat dit inhoudt.

Het doel van het domein component, zoals in het vorige artikel geschetst, is een draaiend software systeem dat een exacte replica tracht te zijn van de business.

Dit artikel is de tweede in een reeks van drie. In deel drie zal de architectuur uitgewerkt worden in een schets van een fysieke implementatie die probeert zo duidelijk mogelijk een beeld te geven van wat een mogelijke realisatie van de ideeën in de praktijk zou kunnen zijn. De term die hiervoor gebruikt wordt is die van Service Architectuur, waarin duidelijk wordt dat onder architectuur niet alleen een fysieke, maar ook een logische en conceptuele betekenis moet worden gehecht.

Doelen

Het component waarin de business logica geïmplementeerd wordt wil de volgende doelen bereiken:

• maximale onafhankelijkheid van leveranciers en technische standaarden
• maximale onafhankelijkheid van technische hulpmiddelen als hardware, programmeertalen en operating systems
• maximale aansluiting bij de binnen het domein of de business gebruikte terminologie
• ondersteuning van strategische evaluaties van de business: uitwerking van business scenario’s, optimalisatie van business processen, business (re-)engineering en -design
• maximale valideerbaarheid door de business

Live domain

Hieronder een voorbeeld van een business domein beschrijving.

Bij het call-center van de verzekeringsmaatschappij komt een telefoontje binnen van een geschrokken autorijder. Zojuist heeft zij een aanrijding gehad, en wil de schademelding doorgeven aan haar verzekeraar. Laten we deze persoon Lisa noemen.

De call-center medewerker, laten we hem Victor noemen, heeft op het moment dat hij de telefoon opneemt op zijn beeldscherm de business gevisualiseerd voorgeschoteld, en het eerste wat hij doet is de persoon aan de telefoon koppelen aan diezelfde persoon die als klant al bekend was bij de organisatie. In het systeem van de verzekeraar is Lisa als een object aanwezig, en zodra die persoon gevonden is maakt Victor kenbaar dat deze persoon een telefoontje pleegt naar het bedrijf. De buitenwereld van de business wordt immers “exact” gerepliceerd in de software!

Nadat de interne Lisa ook aan het bellen is met de verzekeraar geeft Victor aan dat Lisa een schademelding wil doorgeven. Het betreft een schade aan een voertuig die ook als object in de software aanwezig is, en wat gebeurt er nu dus (u kunt het al raden!): de auto wordt verteld dat hij beschadigd is.

Voor allerlei logging doeleinden is niet alleen de aard van de call, maar ook de call zélf iets wat bekend moet zijn, maar zeker voor het specifieke karakter van het live domain is het noodzakelijk dat dit zo gaat.

Wat er nu gebeurd is heel interessant. Het begint al duidelijker te worden waarom de business processen van een organisatie die OO gemodelleerd is op een totaal andere manier tot stand komen dan we gewend zijn in een procedureel model. De auto heeft namelijk een doel in zijn leven, net als Lisa trouwens. Voor de auto is het belangrijk om te kunnen rijden. Om succesvol te zijn in zijn verantwoordelijkheden is het belangrijk dat hij dit goed doet:

● goedkoop
● snel
● correct
● veilig

Lisa heeft ook doelen in haar leven. Voor de business zijn wellicht niet alle doelen relevant (…) maar een paar kunnen we noemen als direct van belang voor de dienstverlening die de verzekeraar wil kunnen leveren:

● Lisa wil dat haar auto het goed doet
● Ze wil bij noodzakelijke reparaties niet te lang wachten
● Ze wil niet teveel geld kwijt zijn voor de gewenste diensten

Dit zijn een paar simpele puntjes nietwaar? Schijn bedriegt. De paar punten die hier genoemd staan zijn echter voor een procedureel model (en zeker voor een datamodel maar daar komen we later nog op terug) al van een schrikwekkende complexiteit!

Want alleen al het bepalen in een reeks van beslisregels wat de marges zijn van “duur” kan ondoenlijk zijn. En het blijft daar niet bij: wat Lisa duur vindt is ook nog afhankelijk van andere factoren: bijvoorbeeld zij kan zijn duurder uit zijn dan bij de concurrent in de hoogte van haar eigen risico, maar omdat zij een voorzichtige chauffeur is kan dit toch acceptabel zijn. Of misschien heeft zij bij de betreffende verzekeraar uitzicht op een aanzienlijke no-claim korting mocht zij inderdaad waarmaken de voorzichtige chauffeur te zijn die ze beweert te zijn.

Hopelijk is in dit korte script al aangegeven dat complexiteit schrikbarend toeneemt in een model dat niet OO is. Gangbare oplossingen lopen dan ook al snel vast op wat binnen een budget van een verzekeraar mogelijk is aan dienstverleningsniveau.

De software auto gaat op zoek naar een schade expert die kan beoordelen wat de hoogte is van de schade. Dit is namelijk nodig voor de auto om te beslissen op welke wijze hij zichzelf zo goedkoop mogelijk maar wel binnen bepaalde kwaliteitsmarges kan repareren. Of eigenlijk doet de auto dit niet zelf: het schadegeval doet dit voor de auto. Allerlei objecten worden gewekt of gemaakt om het probleem op te lossen. Een fax wordt gestuurd naar enkele schade-experts die in de buurt van het ongeval zijn. Het schadegeval heeft in dat kader de plaats van het ongeval nodig en vraagt dit (via het beeldscherm van de call center medewerker) aan de echte Lisa.

De verzekeraar gebruikt de melding ook op allerlei manieren. Zo wordt het schadegeval gebruikt om eventueel de hoogte van reserves te wijzigen (er is bijvoorbeeld een sterk opgaande trend in autoschademeldingen van een bepaald type) of om de reclamecampagnes te wijzigen.

De samenwerking van een groot aantal objecten, die stuk voor stuk zeer eenvoudig zijn, maakt het mogelijk een uiterst complex gedrag op te hoesten. Dit is het belangrijkste kenmerk van een OO model van de business. Wijzigingen in de wereld worden verdisconteerd in het model door de simpele toevoeging van simpele objecten, of soms door het wijzigen van het gedrag van bestaande objecten. Het gebeurt zelden dat de interface van bestaande objecten wijzigt.

Hier komt een essentieel kenmerk van een OO systeem om de hoek kijken: het is een schoolvoorbeeld van systeemtheorie: losse koppeling en hoge cohesie.

De koppeling tussen objecten is los doordat OO het afdwingt met het concept van inkapseling. De cohesie is hoog doordat veel objecten met elkaar samenwerken om een complex gedrag op te hoesten.

Ook zien we dat de interactie van de call center medewerker met de klant niet verloopt via een script (zoals gebruikelijk) maar via een schijnbaar ad-hoc tot stand gekomen vraag-en-aanbod spel. Onderhoud van dit script is geen issue. Ook zijn de handelingen van Victor uiterst simpel: hij heeft eigenlijk alleen maar de klant geïdentificeerd, en de plek van het ongeval.

Dit is een belangrijk punt:

Het business proces is een afgeleide (of een derivaat) van het business model

Wijziging van requirements

Een voorbeeld van de consequenties van ingrijpende wijzigingen is wellicht ook verhelderend.

Zoals gezegd zijn OO business objecten niet passief. Een object als een verzekeringsproduct verkoopt zichzelf! (slecht nieuws voor de marketingmensen…)

Laten we zeggen dat we dit als zodanig geïmplementeerd hebben, en dan komt de marketingafdeling binnenstormen om te melden dat voortaan verzekeringsproducten zichzelf niet meer verkopen, maar dat de verzekeraar voortaan gevoelens wil verkopen.

Gniffelende gezichten bij de marketeers: bewijs nu maar eens hoe flexibel jullie model is!

Welnu: na enige brainstormsessies (over het proces van het tot stand komen van dit business model straks meer) is het business component team tot een oplossing gekomen die uiterst simpel en effectief is: verzekeringsproducten gaan samenwerken met een Gevoel. Wat bleek: VerzekeringsProducten werkten al samen met een Strategie object, dat onder andere bijdroeg aan de reclamecampagnes, en het enige wat nodig was, was dat dit Strategie object samen ging werken met een Gevoel object. In de campagnes resulteerde dit in het naar de achtergrond dringen van de producten zelf, en het Gevoel object op de voorgrond plaatsen.

Van de bestaand objecten hoefde niets gewijzigd te worden, de interfaces bleven exact hetzelfde, alleen presenteerde het bedrijf zich in de buitenwereld op een totaal andere manier.

Bij een bestaande verzekeraar is dit precies zo gemodelleerd, en de case kon dienen als een schoolvoorbeeld van de flexibiliteit van het model.

Business architectuur en de “heersende metafoor”

Het is gaandeweg in dit exposé vermoedelijk wel duidelijk geworden dat waar we hier over praten geen software architectuur meer is. Het is een business architectuur geworden, waar de software architectuur een afgeleide van is.

De term architectuur is in de software wereld een populair begrip geworden. Software ontwikkelaars kijken met argusogen naar engineering disciplines die hun zaakjes beter voor elkaar lijken te hebben, en de discipline die het meest voor de hand ligt is die van de bouwwereld.

We zien dan ook dat de term architectuur in de software engineering heel sterk geschoeid is op de corresponderende term in de bouwwereld. Voor het doel van deze artikelenreeks is het echter belangrijk om te benadrukken dat mijn definitie van architectuur een geheel andere is.

De gangbare definitie van de term heeft sterk infrastructurele connotaties: de layout en de componenten van het netwerk en de operating systemen alsmede de daarop gedeployde applicaties.

De definitie van architectuur die ik in het kader van business architecturen wil voorstellen heeft nauw te maken met datgene dat de grotere bouwwerken mogelijk heeft gemaakt, namelijk het principe van krachtsverdelingen.

In een pilaar oefenen de componenten lineaire krachten op elkaar uit. Dit houdt intrinsiek een beperking in van de grootte van de te bouwen structuren. De hoogte van de pilaren is aan het maximum gebonden dat bepaald wordt door de interne cohesie van het materiaal. Uiteindelijk zal de pilaar onder zijn eigen gewicht bezwijken.

Ook de overspanning is aan de grenzen van het materiaal gebonden.

In een boog echter oefenen de elementen krachten op elkaar uit die niet meer lineair zijn. Wellicht weet u dat de totale hoeveelheid steen die gebruikt is om de kathedraal van Chartres te bouwen kleiner is dan die van het Parthenon – het verschil is architectuur. De kathedraal van Chartres bestaat vooral uit lucht. Dit principe van een slimme verdeling van krachten, oftewel lage koppeling, is in extreme vorm doorgevoerd in Buckminster-Fuller’s Geodesische Bol [1]

Bij deze structuur is de verdeling van krachten zo optimaal dat bewezen is dat met deze techniek structuren gebouwd kunnen worden van onbeperkte grootte.

Bij de bouw van software systemen gaan we nog te vaak uit van het enthousiasme van de amateur timmerman nadat hij een hondenhok in elkaar heeft getimmerd: “hé, nu hetzelfde maar dan 300 keer groter en we hebben een kathedraal!”

Het principe van losse koppeling is er één die software architecturen gemeen hebben met bouwkundige architecturen. Dat wil echter nog niet zeggen dat de bouwkundige metafoor geschikt is voor de bouw van software-systemen. De metafoor voor de ontwikkeling van software-systemen is al te lang ontleend aan mechanische vakgebieden. Het wordt tijd dat we een werkelijke paradigmaverschuiving gaan bewerkstelligen door de metafoor te ontlenen aan de biologie [2]. Hier valt een heleboel over te vertellen, ik wil de belangstellende lezer graag verwijzen naar de boeken en artikelen in de voetnoten die hier verder op ingaan. Graag wil ik hier Alan Kay [3] aanhalen, de uitvinder van de moderne computer en de bedenker van de term objectoriëntatie: “de computerrevolutie heeft nog niet plaatsgevonden”.

Pull model

De wijze waarop business processen tot stand komen om de meest optimale configuratie van activiteiten tot stand te brengen noem ik het pull model, met dank aan Toyota, die deze term noemde in een artikel in de Automatiseringsgids van februari 2000. Op de voorpagina geplaatst zal dit artikel desondanks aan de aandacht van de meeste lezers zijn ontsnapt. In het kader van het hierboven geschetste scenario is het echter uiterst belangwekkend. Toyota had problemen met de IT afdeling van het bedrijf “omdat het niet in staat was software te ontwikkelen dat in staat was het business model te steunen dat het bedrijf voor ogen stond”.

Dit model werd door Toyota het pull model genoemd. Wat stond de organisatie voor ogen? Een klant besteld een auto, en vanaf het moment dat de bestelling binnen komt richt de organisatie zich optimaal in om die auto, die uniek voor de individuele klant is, tot stand te brengen tegen minimale kosten en maximale kwaliteit. Het is te vergelijken met het uit de organisatie trekken van het product. Het is alsof de organisatie een weefsel is, met allerlei draden die met elkaar verbonden zijn in een wonderlijke en onontwarbaar kluwen, en dat op één plek aan dat weefsel getrokken wordt en alle draden zich meebewegen om tot het resultaat te komen.

Het hierboven geschetste scenario van een schademelding is bij uitstek een voorbeeld van een pull model.

Onafhankelijkheid van de techniek

In het volgende artikel zal ik hier uitgebreider op ingaan. Het is van kritisch belang de business component zo onafhankelijk mogelijk van de techniek te houden, en dit wordt gedaan door in de business component op geen enkele plek rechtstreeks te verwijzen naar de andere componenten (de satellieten in de illustratie van artikel 1). In de illustratie is de blauwe component de business component, de gele een service component. De oranje componenten zijn adaptercomponenten, waarover in het volgende artikel meer.

Die koppeling is echter in indirecte zin wel noodzakelijk. Als voorbeeld hebben we een persoon in het business component dat van adres veranderd als gevolg van een verhuizing.

Het business component is een systeem dat draait op een applicatieserver en als zodanig niet persistent vanuit zichzelf. De definitie van persistentie die ik hanteer is: wanneer de stroom uitvalt op een willekeurig moment moet het mogelijk zijn de state van de business component weer volledig te herstellen.

Logisch gezien is het scenario waarin het adres van een persoon wijzigt volledig onafhankelijk van een eventuele database. Dat er in de business voor gekozen is om de persistency service in te laten vullen door een relationele Oracle database management systeem betekent echter dat de wijziging van het adres uiteindelijk zal moeten resulteren in een wijziging van een veld in een tabel.

Onthoudt echter dat logisch gezien er maar op één plek iets gebeurt: de persoon verhuist. Dat dat resulteert in een update van een veld in een database is een neveneffect, en relatief onbelangrijk. In een toekomstige versie van het systeem zijn relationele databases wellicht niet zo interessant meer en zijn betere oplossingen mogelijk. Zonder dat de business-kritische component gewijzigd hoeft te worden is dit mogelijk door eenvoudigweg de bestaande persistency service te vervangen door een ander component.

Hoe vindt echter de wijziging van het persoon object zijn weg naar de tabel in de database component?

Dat gebeurt door middel van een event mechanisme, dat de mogelijkheid creëert voor de satelietcomponenten door een publish and subscribe mechanisme op de hoogte gebracht te worden van deze wijzigingen en de relevante acties te ondernemen.

Zoals gezegd zal het volgende artikel dit concreter proberen te maken en tevens wat verwijzingen aan te geven naar bestaande implementaties van dit principe.

Positionering van ontwikkeling en onderhoud van het business component

Het business component vervult, zoals we kunnen begrijpen na voorgaand betoog, een centrale kritische rol in de organisatie. Het is de repository van de business intelligence, het kader voor business engineering, het handvat voor kennismanagement, en de blauwdruk voor ondersteunende software systemen.

Dit is geen component dat geschikt is om te ontwikkelen en te onderhouden op de wijze waarop de meeste software componenten tot stand komen. Het probleem dat ontstaat bij inrichten van hergebruik is hier in nog extremere mate aanwezig: de kwaliteit van het component overstijgt de belangen die in een projectorganisatie (de structuur van de meeste bedrijven) op projectniveau zijn belegt.

Hiervoor is het inrichten van de organisatie die dit model wenst te omarmen als een reuse organisation in de zin van Jacobson’s boek [4] van misschien nog groter belang dat het anders al is.

Dit component is een component dat in een nauwe samenwerking met de business ontwikkeld dient te worden. Daartegenover staat dat de wijze waarop dit component in de bestaande business geïntroduceerd wordt absoluut geen big-bang operatie is, en dat persé ook niet moet zijn. Het proces van introductie zal incrementeel dienen te geschieden.

Één van de criteria die gesteld kunnen worden aan de ontwikkeling van dit component is dat het geen geld moet kosten. Ja u leest het goed!

Dit doel kan bereikt worden wanneer gebruik gemaakt wordt van een agile method [5] voor de implementatie. Hierbij wordt het systeem incrementeel ontwikkeld aan de hand van een voortdurend wijzigende lijst van business wensen. Een doelstelling is om binnen een zeer korte tijd na de start van het project te komen tot een deliverable dat daadwerkelijk ondersteuning biedt voor één of ander business proces, en dus de investering die erin gedaan is meteen terugbetaalt!

In een grote organisatie kan op deze wijze het gehele business component ontwikkeld en beheerd worden door een relatief uiterst kleine groep mensen. U moet zich voorstellen dat een organisatie als de ABN-AMRO bank in staat zou moeten zijn dit te doen met een groep van ca. 10 mensen.

Deze groep kan bijvoorbeeld bestaan uit 6-8 OO deskundigen, en bij toerbeurt (maar wel 100% van de tijd!) 2 mensen uit de business, om voortdurend het model bij te werken.

Deze groep zal bestaan uit deskundigen, het is van essentieel belang hier mensen bij te hebben die minstens 5 jaar ervaring hebben met OO vanuit een bedrijfskundige hoek, en geen techneuten zijn. Dit kan een risicofactor zijn bij de implementatie van het model: zijn deze mensen aanwezig, of kunnen ze aangetrokken worden? Opleiding is al nauwelijks mogelijk vanwege het hoge ervaringsniveau dat vereist is.

Risico analyse

Helaas zal ik geen tijd nemen om dit belangrijke aspect uit te werken. Wat zijn de risico’s wanneer we dit model als werkmodel annexeren? Zijn er criteria aan te geven wanneer organisaties niet geschikt zijn voor de geschetste werkwijze? Kunnen we aangeven wat criteria voor kwaliteit zijn?

Vele belangrijke vragen heb ik hier nog niet kunnen oppakken en dat zal in de praktijk bij het implementeren van het model wel degelijk dienen te gebeuren. Het is niet de bedoeling met het verhaal een enthousiasme te creëren dat leidt tot “silver bullet” syndroom. Er is geen aanpak die alle problemen op kan lossen. Het enige wat ik wil poneren is dat de tijd is aangebroken dat sommige problemen wél opgelost kunnen worden, en dat de techniek zover is dat dit mogelijk is.

Het is tijd voor een nieuwe wending op de evolutiespiraal van business en IT. Wie durft?

Lees het volgende artikel in deze reeks: Business-Centred Architecturen III.