From the Mist

Dit is deel 1 van een serie van drie artikelen. Deze artikelen introduceren de architectuurprincipes die ten grondslag liggen aan een business-centrische architectuur. Toen deze artikelen voor het eerst werden gepubliceerd (als pdf downloads op de site van Cibit) waren ze maandenlang de meest gedownloade artikelen.

Titel	Inhoud
Business Centred Architecturen I	Introductie en principes (dit artikel)
Business Centred Architecturen II	Business domein component
Business Centred Architecturen III	Service-oriëntatie, voorbeeldimplementatie en adapters

Deze serie is oorspronkelijk gepubliceerd in 2001. De artikelen worden up-to-date gehouden (tot 2021) zodat de uitgelegde principes nog steeds actueel toepasbaar blijven.

Motivatie

Het is een gezonde trend in moderne bedrijven om zich voortdurend te bezinnen op wat nu eigenlijk de core business is van het bedrijf.

Een telecom operator heeft als core business het exploiteren van telecommunicatie faciliteiten en het leveren van diensten daarmee. Een schoonmaakbedrijf heeft als core business het schoonmaken van gebouwen en ruimtes.

In dat kader is het heroverwegen van ICT investeringen een onderdeel van deze bezinning. Welke aspecten van de ICT kosten zijn onderdeel van de core business, en welke niet?

Elk onderdeel van een bedrijf dient zijn bijdrage aan het bedrijfsresultaat te onderbouwen. Geen enkel onderdeel kan in dat proces buiten schot blijven. Het zijn slechts de beschikbare resources die dit proces van bezinning onderwerpen aan restricties. Het wijzigen van de bedrijfsstructuur, door sommige delen af te stoten of juist uit te bouwen door er extra in te investeren, kost tijd en geld. In zekere zin is dit proces zelf ook een bedrijfsonderdeel dat voortdurend meegenomen dient te worden in dit bezinningsproces.

Het bezinningsproces leidt bijvoorbeeld tot het outsourcen van sommige ICT-activiteiten. Dit kan succesvol zijn, of niet. Er zijn in de onderzoeken naar de effectiviteit van outsourcen elkaar (schijnbaar) tegensprekende resultaten. In het algemeen lijkt het belangrijk om te letten op een aantal eigenschappen van die onderdelen die kandidaat voor outsourcen zijn. Ik noem er een paar ter illustratie, het is zeker niet bedoeld als een uitputtende lijst:

• Zijn er voldoende (concurrerende) aanbieders op de markt?
• Is het onderdeel voldoende volwassen (bijvoorbeeld in CMM zin)?

De relatie tussen ICT en business is niet een uitzonderlijke, maar kenmerkt zich natuurlijk wel door een aantal aspecten. Zo is ICT te vergelijken met bijvoorbeeld een ander essentieel bedrijfsonderdeel, bijvoorbeeld de catering. Zonder mogelijkheden tot voedselopname zullen weinig werknemers tot productiviteit in staat blijken te zijn. Catering valt zeker niet onder de core business. Toch onderscheidt ICT zich van bedrijfsonderdelen als catering doordat het veel meer verweven is met de core business dan welk ander bedrijfsonderdeel ook. Dit is juist dat aspect waardoor het veel moeilijker te beoordelen valt op welke wijze ICT met de business dient samen te werken, en tevens de oorzaak van de gespannen voet waarop de verhouding tussen ICT en business leeft.

Wat nodig is in dit dilemma is een duidelijke markering van de grenzen tussen business en ICT. Het is een simpele constatering, en het is uiterst belangrijk deze constatering te maken. We kunnen veel woorden vuil maken aan wat er allemaal aan problematiek speelt, maar in essentie komt het hierop neer, en het formuleren van het probleem in zo eenvoudig mogelijke termen kan ons helpen grip op de situatie te krijgen en maatregelen te nemen om de problemen te verminderen en eventueel zelfs op te lossen.

De fout die eigenlijk alle ICT producten maken, en intrinsiek de fout die gemaakt wordt door de leveranciers/bouwers van die producten, is dat in die producten het onderscheid tussen business en ICT juist veel te veel verweven is. Misschien zit hier een doelbewust beleid achter om de gebruiker afhankelijk te maken van het product, maar dat is te betwijfelen. De oorzaak zal veel meer te vinden zijn in de onvolwassenheid van ICT in het algemeen. Het is nog een primitieve technologie en de vuistregels van het werken ermee zijn nog niet uitgekristalliseerd.

De oplossing valt dus te vinden in het uit elkaar trekken, in de software oplossingen die wij bouwen, van business en ICT.

Hoe dit gerealiseerd kan worden is geen eenvoudig verhaal. Het is echter wel degelijk zo dat er wat aan gedaan kan worden, en dat wij geen willoos slachtoffer zijn van leveranciers, of dat de tijd er nog niet rijp voor is — kortom er zijn geen excuses om de aanpak van dit probleem nu we het onder woorden hebben gebracht en onderkend hebben uit te stellen. Het is een stap in de verdere volwassenwording van de ICT dat we hiermee beginnen, en voortdurend werken aan de verdere implementatie van deze oplossing.

Dat er wat aan gedaan kan worden is een eye-opener voor veel business managers. Momenteel is de situatie teveel die van een willoos slachtoffer: de ICT mensen kunnen van alles beweren, er zijn immers veel te weinig criteria om te kunnen toetsen of datgene wat ze beweren ook daadwerkelijk hout snijdt. Is er weer eens een project mislukt? Moet er weer een product aangeschaft worden? Moet de business weer eens aangepast worden omdat de ICT anders niet de voordelen kan bieden die het belooft?

In deze vrije-jongens-cultuur wordt het tijd dat werktuigen in handen komen van de niet-IT’ers onder ons waardoor we in staat worden gesteld de beweringen van de IT onder de loep te leggen en te beoordelen op hun mérites.

Kort samengevat is dus wat wij graag willen het uit elkaar trekken van:

1. technische componenten die gebouwd kunnen worden door mensen die technisch gericht zijn en niet noodzakelijkerwijs de vaardigheden hoeven te bezitten die hierboven beschreven zijn
2. business componenten die deze eigenschappen noodzakelijkerwijs wél dienen te bezitten

De twee basisbouwstenen van moderne systemen

Systeemontwikkeling is moeilijk. In de loop van de tijd is het alleen maar moeilijker geworden en het zal de komende jaren zeker niet ophouden met moeilijker worden. In het offensief van leveranciers van allerlei redding-in-de-nood oplossingen is het voor de gewone ontwikkelaar bijna ondoenlijk geworden zijn keuzes te maken en die te baseren op een redelijke inschatting van de ontwikkelingen.

Toch is er licht aan de horizon. Het is namelijk helemaal niet zo ingewikkeld als het lijkt. Zou het misschien zo zijn dat die leveranciers van oplossingen er baat bij hebben de situatie zo ondoorzichtig voor te spiegelen? In dit artikel wil ik de twee basisbouwstenen voor moderne systeemontwikkeling uit de doeken doen, twee relatief eenvoudige beginselen die de ontwikkelaar in staat stellen de draak van de complexiteit misschien niet te verslaan maar toch tenminste van zijn klauwen te ontdoen. Twee basisbegrippen ook die eigenlijk helemaal niets met IT te maken hebben. Zou het mogelijk zijn dat houvast te vinden is in iets dat niet gegoten is in esoterische informatietechnologische terminologie? Iets waarvoor geen meerdere jaren van onderdompeling in de cultuur van systeemontwikkeling nodig is om te begrijpen? Je zou het graag willen geloven …

De sleutel tot begrip ligt in de relatieve eenvoud van deze basisbeginselen. Tevens ligt daarin de oorzaak van de onderschatting of zelfs de relatieve onbekendheid van deze beginselen. Iets dat zo eenvoudig is kan makkelijk over het hoofd gezien worden. De vermeende complexiteit van objectoriëntatie is niet veroorzaakt omdat het zo moeilijk is – het is ontstaan doordat de meeste ontwikkelaars niet op de hoogte waren van deze eenvoudige basisbeginselen of deze uit het oog verloren onder de druk van de deadlines en requirements.

Welke zijn deze basisbeginselen nu? En zou dit artikel in staat zijn aan te tonen dat ze zo eenvoudig zijn als erin beweerd wordt?

1. IT- en business alignment door domain-centered architecturen
2. De wereld van Roger Rabbit

De terminologie waarin dit artikel gegoten is gaat uit van weinig voorkennis, maar heeft als primaire doelgroep systeemarchitecten, en als secundaire doelgroep systeemontwikkelaars in het algemeen. In een gewijzigde terminologie kunnen (en dienen) deze basisbeginselen ook uitgelegd worden aan niet-IT’ers. Zoals later ook betoogd zal worden is het ook van groot belang om dit te doen. De niet-IT variant van dit artikel zou misschien samen met dit artikel binnen organisaties verspreid moeten worden om beide doelgroepen tenminste in de discussie te betrekken.

IT- en business alignment door domain-centered architecturen

Het is misschien een wat algemener geaccepteerde constatering van een symptoom voor de problematiek van moderne systeemontwikkeling dat IT’ers zo slecht in staat zijn te communiceren met de business. De ivoren toren waarin de IT een aantal jaren geleden zat heeft zij ondertussen wel verlaten en de erfenis van die periode vinden we terug in het misschien gerechtvaardigde wantrouwen vanuit de business. Succesvolle ondersteuning van zakelijke processen door informatietechnologie zal nooit plaats kunnen vinden wanneer de twee werelden – waar helaas nog steeds sprake van is – elkaar niet vinden. Communicatie wordt algemeen gezien als essentieel voor succes, maar helaas zijn weinigen ertoe in staat.

Geven en nemen van twee kanten is hier de sleutel. Er begint al een kentering te ontstaan in de houding van de business ten opzichte van de IT. IT wordt minder gezien als een noodzakelijke ondersteuning van de primaire en in principe IT-onafhankelijke bedrijfsprocessen. Traditionele automatisering is immers doen wat je al deed, alleen nu ondersteund door computers. De kentering is natuurlijk in gang gezet door een paar belangrijke ontwikkelingen:

1. Internet
2. Globalisering van markten

Deze twee ontwikkelingen hebben allerlei bedrijven geconfronteerd met het feit dat IT niet meer iets is dat de primaire bedrijfsprocessen ondersteunt, maar dat veel van die primaire processen geheel of gedeeltelijk IT processen zijn, of tenminste afhankelijk daarvan zijn. Een ontnuchterende constatering. Lucratief voor de IT op het eerste gezicht, want alom zien wij de IT budgetten de pan uit rijzen in een poging van bedrijven deze symbiotische relatie wat minder wankel te krijgen. Minder lucratief echter wanneer wij als IT’ers ons realiseren dat we nauwelijks in staat zijn deze sterk toegenomen afhankelijkheid ook effectief in te vullen.

Domain-centered architecturen zijn hier onontbeerlijk, om deze symbiotische relatie in te vullen. Dit betekent echter dat zowel vanuit de business als vanuit de IT offers gebracht moeten worden.

Welke offers zijn dat?

Vanuit de business dient de erkenning van de wezenlijke rol van IT op het strategisch niveau niet meer iets te zijn wat afgedwongen of geëvangeliseerd hoeft te worden. Wanneer dit nog het geval is, is de organisatie nog niet rijp voor de fase in de richting van een volwassen relatie tussen business en IT — een fase waar dit artikel enkele richtlijnen voor hoopt te geven.

Vanuit de IT dient er een erkenning te zijn van het feit dat de business het enige is dat telt. IT is niets anders dan een enabling technology, die geen waarde in zichzelf heeft. Als we praten over de financiële wereld dan praten we over transacties, winsten, boekingen en dergelijke. We praten niet over databases, dagafschriften, en zelfs niet over boekhouding. Dat zijn allemaal krukken om de primaire zaken waarover de dagelijkse business gaat te ondersteunen. Deze krukken kunnen weggegooid worden wanneer nieuwe krukken zich aandienen of wanneer informatietechnologie eindelijk volwassen genoeg wordt om op eigen benen te staan. Praten met de business is dus iets wat geen noodzakelijk kwaad meer mag zijn. De klant of de opdrachtgever kan niet meer iemand zijn waar smalend uitspraken over gedaan worden als “de klant weet niet wat hij wil”, of: “wij begrijpen de business beter dan de klant”. Er dient een denkraam te ontstaan waarin dergelijke uitspraken niet eens meer mogelijk zijn. Nog afgezien van het feit dat het dan (gelukkig!) moeilijker wordt om op deze manier over de klant te praten want de klant is hoogstwaarschijnlijk aanwezig, intensief betrokken bij de systeemontwikkeling als een onderdeel van de verschillende teams.

Wat zijn nu de kenmerken van een domain-centered architectuur?

1. Er is een OO model van de business
2. Het model is een Roger Rabbit model van de business (zie hoofdstuk 2)
3. Dit model is geschreven in UML
4. Het model is geïmplementeerd in de één of andere taal (of meerdere talen) en draait als een executable systeem, wel of niet gedistribueerd/gerepliceerd op een application server
5. Het model is een exacte replica van de business en draait als het ware een simulatiemodel van die business

Er zijn twee businesses. De externe, werkelijke business, en de interne representatie daarvan. Dat die interne representatie een exacte representatie is, is de verantwoordelijkheid van de IT. Dat de business zich zo heeft geëngineerd dat die interne representatie gemaakt kan worden is de verantwoordelijkheid van de business. Dit betekent niet alleen dat er een (OO) model van de business gemaakt moet worden, maar ook dat de business zich heeft gemaakt tot een (OO) business. Dit is re-engineering van de business, maar op een nieuwe manier die niet eerder in de boekjes van Hammer en Champy zo is uitgelegd. Dit is een wijze van re-engineeren die ontleend is aan engineering praktijken afkomstig uit de IT.

Zo heel vreemd is deze re-engineering techniek niet. Het is misschien makkelijker voor de business om deze aanpak te slikken wanneer ze zich realiseert dat ze eigenlijk al lang gebruik maken van IT technieken om hun business in kaart te brengen. Procesmodellen worden namelijk alom gebruikt om inzicht te krijgen in bedrijfsstructuren. De manier waarop deze modellen worden vormgegeven  is gedeeltelijk ontleend aan de IT. Het zijn vormen van dataflowdiagrammen. Waar de IT de tekortkomingen van deze manier van modelleren al lang heeft ingezien wordt het misschien voor de business ook tijd hier iets aan te doen. Dat de manier waarop bedrijfsprocessen worden gemodelleerd ontleend is aan de IT is trouwens helemaal niet vreemd. In de loop van de geschiedenis hebben mensen steeds de wereld waargenomen door de bril van wat ik de “heersende metafoor” noem. Er is een tijd geweest dat mensen alle verschijnselen die ze in de natuur waarnamen verklaarden met behulp van de stoommachine. Zelfs mensen werden uitgelegd aan de hand van deze metafoor. De heersende metafoor van onze tijd is de computer en we hoeven dus niet verbaasd te zijn dat mensen zichzelf, de levende en niet-levende natuur en de maatschappij met behulp van deze metafoor proberen te begrijpen.

Dit model van de business kunnen we misschien moeilijk nog een model noemen. Een model is immers een representatie van iets waarbij teneinde inzicht te bevorderen zaken zijn weggelaten. Zaken die het model voor de doeleinden waarvoor het gemaakt is onnodig complex zouden maken. Modellen zijn in principe hulpmiddelen die een subset van de werkelijkheid afbeelden. Dat is meestal ook de bedoeling. Met dit model, het business domain model, is echter iets bijzonders aan de hand:

1. Het is executable, dat betekent dat het gebouwd is en draait op computers.
2. Het model heeft de pretentie geen informatie weg te laten en een volledige representatie te zijn van de business.
3. De business is ontworpen aan de hand van deze business modellen.
4. Re-engineering van de business, mocht dat nu of in de toekomst nodig zijn, vindt plaats op basis van de modellen.
5. Strategische toekomstscenario’s worden geëvalueerd door deze uit te werken in de modellen. Deze modellen lenen zich daar ook bij uitstek voor.

De wereld van Roger Rabbit

De toepassing van dit basisbeginsel is nog minder wijd verbreid dan dat van de vorige. En zoals al eerder werd aangegeven is het onmogelijk de vruchten van het toepassen van deze beginselen te plukken wanneer ze niet beide worden toegepast. Om het eerste basisbeginsel geaccepteerd te laten worden door de IT is al een hele klus. Diezelfde klus te klaren voor de business is een nog grotere klus. Om het tweede basisbeginsel te laten accepteren is meestal nog veel moeilijker, ondanks het feit dat technisch gezien dit beginsel het minst complex is en de minste eisen stelt in termen van uit te voeren werk en investeringen. Het is veel meer een manier van kijken naar problemen en situaties.

Dat is misschien ook meteen de oorzaak van de moeite die veel mensen hebben met dit beginsel. Iets dat zo simpel is, kan dat zoveel impact hebben op de manier waarop modellen gemaakt worden? Mensen hebben het gevoel dat iets pas waarde kan hebben wanneer je er heel veel geld voor uitgeeft of tijd, dat laatste bijvoorbeeld in lange en dure opleidingen. Voor het tweede basisbeginsel is geen van beide nodig.

De essentie van het tweede basisbeginsel is eenvoudig: laat dát object de dingen doen die gedaan moeten worden die daar het best toe in staat is. Dit wordt ook wel het Expert Pattern (uit de GRASP patterns van Craig Larman) genoemd.

De consequenties van dit pattern zijn echter nogal ingrijpend.

Moet ik bijvoorbeeld een whiteboard stift modelleren, dan kan ik een scenario voorstellen waarin ik wil dat die stift het woord “aap” op het whiteboard schrijft. Hoe kunnen we dit modelleren?

Een aanpak zou kunnen zijn dat ik, me bewust zijnde van het feit dat die stift niets zelf kan, een procesobject ga bouwen dat de stift beetpakt, de dop eraf haalt, naar het bord verplaatst, en daar het woord “aap” schrijft. Dit zou nota bene nog goed aansluiten bij de werkelijke wereld, waarvan OO altijd beweert dat het er zo nauw op aansluit. Dat procesobject zou feitelijk een representatie zijn van mijzelf, de persoon die de stift manipuleert.

Fout.

Waarom fout? Misschien dat de lezer even de tijd kan nemen om te overwegen wat hieraan verkeerd zou kunnen zijn.

Het belangrijkste probleem met deze benadering is dat, in het algemeen gesproken, het procesobject waarover hier gesproken wordt veel te complex zou worden. Alleen al het woordje “aap” op het bord krijgen zou een hels karwij zijn, en je kunt er vergif op innemen dat de klant, wispelturig als zij is, het in haar hoofd haalt nieuwe requirements aan te dragen en voor je het weet zit je een nieuw proces te bouwen om het woordje “noot” op dat verrekte whiteboard te krijgen. Nog afgezien van al die andere processen die er denkbaar zijn is één plaats waar je teveel probeert te doen een slecht idee. Er ontstaan allerlei onverwachte afhankelijkheden, het oplossen van problemen of fouten wordt steeds moeilijker, en elke nieuwe toevoeging van functionaliteit vraagt meer tijd om geïmplementeerd te worden. Klinkt bekend?

OO is gebaseerd op het principe van delegatie en dit is een heel gezond systeemtheoretisch principe, namelijk dat van losse koppeling.

Een betere oplossing zou wellicht zijn het scenario niet door twee objecten (de stift en het procesobject) maar door meerdere objecten te laten uitvoeren. Een kandidaat die zich aandient zou kunnen zijn een Beweger, die de verantwoordelijkheid zou hebben de stift te verplaatsen naar het bord. Het woordje staat er dan nog weliswaar niet op maar we zijn tenminste een eind opgeschoten. Dit is geen slecht idee. We hebben één aspect van het scenario onder handen genomen, namelijk het verplaatsen van de stift, en een object gevonden dat dit aspect onder zijn verantwoordelijkheid kan nemen. Toch is de oplossing nog steeds niet ideaal. Objecten zijn namelijk van nature lui (de populistische versie van onze eerdere constatering dat complexe objecten die teveel verantwoordelijkheden hebben niet aan te raden zijn) en ze dan een naam te geven die afkomstig is van een werkwoord is geen goed idee… Beter zou zijn het object de naam te geven Coördinatenstelsel, en daaraan de verantwoordelijkheid te geven anderen te helpen hun positie in dat coördinatenstelsel te wijzigen.

Bij het bord aangekomen zien we ons voor het probleem gesteld de dop van de stift te verwijderen. Wie kunnen we die verantwoordelijkheid geven? (u ziet, we beginnen de slag al te pakken te krijgen!) Welnu, hoezeer we ook brainstormen, we zien over het hoofd dat er al een object is dat perfect in staat is deze verantwoordelijkheid op zich te nemen.

De dop zelf.

Nu begint wellicht wat duidelijker te worden wat met dit basisbeginsel bedoeld wordt en wat de consequenties zijn van het toepassen ervan. Het is de wereld van Roger Rabbit die we modelleren en niet de “werkelijke” wereld. Het is een wereld waarin geen “dode” objecten bestaan. Passieve objecten bestaan niet in de OO wereld. Objecten zijn actief. Deuren openen zichzelf, kopjes drinken zichzelf leeg, theepotjes huppelen over de tafel en schenken de thee in. De toverfee is langs alle objecten gegaan en heeft ze aangeraakt met haar toverstaf en met het elfenstof alles tot leven gewekt.

Alles wat bij het object hoort, doet het object zélf.

De toepassing van dit basisbeginsel is van ontzettend groot belang. Veel zo niet alle voordelen van OO verdwijnen als sneeuw voor de zon wanneer we dit principe niet of niet correct toepassen. Wat we hier namelijk doen is een truc toepassen die ons in staat stelt complexiteit te reduceren zonder informatie te verliezen. We beelden nog steeds de werkelijke wereld af in de software, maakt u zich geen zorgen. Alleen: we doen dat zonder informatieverlies zodanig dat we in staat zijn complexiteit aanzienlijk te reduceren. Door alles wat bij het object hoort ook daadwerkelijk bij het object te plaatsen gaat geen verantwoordelijkheden verloren maar decomposeren we de werkelijkheid in overzichtelijke brokken. Alles wat van de pen is plaatsen we bij de pen. Daardoor hoeven we dat niet in een onoverzichtelijk en op den duur ononderhoudbaar procesobject te plaatsen maar houden we alles netjes gepartitioneerd. We maken in feite gebruik van een cognitief hulpmiddel waardoor we in staat zijn veel hogere niveaus van complexiteit te bereiken dan wanneer we dit hulpmiddel niet zouden gebruiken.

Referentie model

In deze serie artikelen wil ik een referentiemodel introduceren dat zal dienen als een illustratief voorbeeld van de toepassing van business-centered architecturen. Het voorbeeld is gebaseerd op:

1. Toepassing van Java/JEE voor de technische architectuur en de technische componenten
2. Geïsoleerd business component gebouwd in een andere taal (in ons voorbeeld Smalltalk, maar dit kan in elke programmeertaal, ook Java)
3. Koppeling van bovenstaande onderdelen met behulp van adapter-technologie (ook wel connectoren genoemd)

Een aantal redeneringen liggen ten grondslag aan deze keuzes.

1. Ten eerste is er sprake van een referentiearchitectuur, waar andere eisen gesteld worden aan een aantal keuzes omdat hier het belangrijkste doel is een didactisch effect te bereiken.
2. Ten tweede is het belangrijk om niet alleen een Java implementatie te kiezen omdat dit ons dreigt te binden aan bepaalde leveranciers en oplossingen. Bijvoorbeeld een .NET implementatie van het referentiemodel zou ook mogelijk moeten zijn. Oplossingen in de praktijk zijn ook zelden uniform qua programmeertaal.
3. Ten derde is de keuze van Smalltalk voor de business component niet willekeurig. Programmeertalen zijn niet de alfa en omega van systeemontwikkeling en elke taal heeft zijn voordelen en nadelen. Met name voor de bouw van business componenten heeft Smalltalk een groot aantal eigenschappen die deze taal voor deze toepassing beter geschikt maken dan de meeste andere programmeertalen, inclusief Java.

Wat voor het business component verder van belang is dat we telkens weer ons best zullen moeten doen om iets voor elkaar te krijgen dat met name voor de business component van wezenlijk belang is, namelijk technologie-onafhankelijkheid.

Verder zullen we met dit model pogen een aantal andere winsten te behalen:

• Betere onderbouwing voor outsourcing
• Sterke vereenvoudiging van aan te koppelen standaardsystemen
• Hierdoor een reductie in IT kosten van 50-90%

De argumentatie van deze punten wil ik nog even uitstellen, maar wel is het belangrijk hier op te merken dat dit misschien wel de meest doorslaggevende redenen zijn om deze aanpak te volgen.

Op basis van de bovenstaande overwegingen kunnen we een grove schets maken van de basisstructuur van de architectuur:

Dit diagram illustreert een aantal zaken:

• Business model staat centraal
• Bestaande systemen of shrink-wrapped software koppelen aan via de adapter laag
• Naarmate we meer naar het centrum bewegen worden de componenten meer OO, en meer naar de periferie meer CBD (component-based, reusable building blocks)