From the Mist

1. Introductie

Long Read! (je was gewaarschuwd…!)

Dit document dateert uit 2003. Het is geschreven als achtergrondreferentie voor een bepaalde aanpak van enterprise architectuur. Maar ik ben ervan overtuigd dat op het moment dat je dit leest je meer dan ooit bruikbare handvatten voor de praktijk zult vinden.

De focus van het document ligt op de Information Systems architectuur (TOGAF).

Deze referentie architectuur is grotendeels ontstaan vanuit de praktijk. Het was nodig een integrale aanpak te realiseren waarmee stappen gemaakt konden worden voor het werken onder architectuur.
Dit is een uitgebreid document, waarin verscheidene aspecten die in andere artikelen op deze site staan bij elkaar komen in een coherente aanpak voor enterprise architectuur. De focus van dit artikel ligt op de applicatie architectuur, hoewel de koppelingen met met name de business architectuur, security architectuur en de strategische visie wel degelijk aan bod komen.

2. Samenvatting

Op tijd, binnen budget, volgens functionele specificaties en naar volle klanttevredenheid realiseren en beheren van applicaties en systemen, vereist een proces van werken onder architectuur. Wanneer die systemen dan ook nog besloten en bedrijfszeker moeten zijn speelt architectuur een sleutelrol, evenals in organisaties waar bottlenecks ontstaan in time-to-market, bij mergers, of andere uitdagingen. Hoe die architectuur er uitziet staat beschreven in dit document. Het werken onder deze architectuur waarborgt een minimum vereist niveau van volwassenheid in dienstverlening waar het klantenveld van organisaties steeds meer om vraagt.

Het gaat in dit document om twee zaken:

1. hoe zou een referentiearchitectuur er inhoudelijk uit kunnen zien (een beschrijving van de gereedschapskist)
2. hoe gaat de referentiearchitectuur meerwaarde opleveren voor de organisatie, maar vooral voor zijn klanten, met name gefocust op softwareontwikkeling en –beheer (wat kun je met de gereedschapskist bereiken).

Beide aspecten worden in dit document behandeld. Hoe we dat dan gaan doen (procesaspecten) komt hier niet aan de orde. Dit document is wel te onderscheiden, maar niet te scheiden van dat procesdocument. Ze vormen dan ook een tweeling. Enterprise Architectuur is met name een proces (definitie van de Meta Group, zie [Meta Group, 2002]) en niet in de eerste plaats een verzameling van modellen.

De applicatie referentiearchitectuur ondersteunt de volgende visie-uitgangspunten:

1. Alle (business en software-) ontwikkeling is gebaseerd op hergebruik van modulaire componenten.
2. In softwareontwikkeling staan de bedrijfsprocessen van de klanten centraal — niet alleen met de mond beleden, maar ook expliciet zichtbaar in programmacode door middel van een simulatiemodel van de fysieke wereld.
3. Er is altijd up-to-date inzicht in de huidige functionele status van applicaties en registers, en de te verwachten wensen voor verbeteringen of vernieuwingen.
4. Eigenaarschap, verantwoordelijkheden, escalatielijnen (governance) en technische documentatie zijn voor alle producten, projecten en beheeromgevingen helder en eenvoudig vindbaar ingericht.
5. Ontwikkeling en –beheer gebeurt aan de hand van formeel goedgekeurde richtlijnen en standaarden voor tools, platformen, en andere (technische) middelen. Deze richtlijnen en standaarden worden periodiek ook zelf periodiek heroverwogen en zijn evenals de modulaire componenten genoemd onder punt 1 geplaatst in een toegankelijke repository.

Een referentiearchitectuur voor softwareontwikkeling en –beheer heeft een scope van ongeveer tien jaar. Dat wil zeggen dat wij kunnen verwachten dat software ontwikkeling volgens model driven architecture ongeveer tien jaar relevant kan blijven.

Het invoeren van architectuur, en ook de implementatie van een referentie architectuur, kan het best SMART geformuleerd worden.

Hieronder vind je een voorbeeld van een dergelijke formulering, ter illustratie.

Binnen een jaar:

1. Heeft 80% van alle ontwikkelaars en beheerders een opleiding op het gebied van MDA en CBD (Component Based Development) gedaan en hebben tenminste enige ervaring in tenminste één relevant project opgedaan;
2. Is minimaal 80% van “nieuwe” applicaties opgebouwd volgens het principe van CBD;
3. Is minimaal 40% van de “legacy” applicaties in een migratietraject gekomen voor vernieuwing volgens het MDA principe;
4. Zijn alle keuzes voor standaarden in deze referentiearchitectuur voor 1 jaar bevroren en deze jaarlijkse cyclus herhaalt zich;
5. Wordt 80% van alle software ontwikkelprojecten binnen tijd en budget opgeleverd;
6. Wordt 80% van alle software ontwikkelprojecten pragmatisch (maar wel verplicht) met behulp van Prince II èn UP gedaan;
7. Is van 80% van alle applicaties alle vormen van project– en productdocumentatie (inclusief architectuurbeslissingen) in een standaard formaat op een standaard plaats beschikbaar.

3. Inleiding

Dit document beschrijft die referentiearchitectuur. Het gaat daarbij om twee zaken:

1. hoe ziet de referentiearchitectuur er inhoudelijk uit (een beschrijving van de ‘gereedschapskist’) en
2. hoe gaat de referentiearchitectuur meerwaarde opleveren voor de organisatie wat betreft softwareontwikkeling en –beheer (wat kun je met de gereedschapskist bereiken).

Hoe we dat dan gaan doen (procesaspecten) wordt behandeld in een apart document. Dit document is wel te onderscheiden, maar niet te scheiden van dat procesdocument. Ze vormen dan ook een tweeling.

Opbouw

Het Referentiearchitectuur document is als volgt opgebouwd. Hoofdstuk 4: Algemene uitgangspunten beschrijft de context en algemene uitgangspunten van de Referentiearchitectuur voor Software ontwikkeling en –beheer. Dit hoofdstuk is zo geschreven dat het de lezer een algemeen en compleet beeld geeft van de belangrijkste aspecten van de gehele referentiearchitectuur. Zo worden naast het speelveld ook de visie en het doel van de referentiearchitectuur geschetst, een beschrijving van de doelgroep van het document, en verwijzingen naar gerelateerde documenten gegeven.

Hoofdstuk 5: Business-centred modelleren doet de aftrap voor de invulling van de referentiearchitectuur, door uit te leggen wat de belangrijkste eigenschap is van de architectuur, namelijk de focus op de business en de wijze waarop dat in de architectuur verankerd is.

Hoofdstuk 6: Logische referentie architectuur beschrijft de referentiearchitectuur op logisch niveau. Het gaat hier dus nog niet om de technische invulling, maar om een beschrijving van de belangrijkste concepten die worden gehanteerd binnen software ontwikkeling en beheer en wat dat betekent voor de modelleerwijze, denkwijze en werkwijze van bouwers en beheerders.

Hoofdstuk 7: Technische referentie architectuur beschrijft de referentiearchitectuur zelf (de “gereedschapskist” op technisch niveau). Dit vormt als het ware het hart van de referentiearchitectuur en de daadwerkelijke referentie voor de bouwers en beheerders. Hoofdstuk 8: Deployment gaat dieper in op de raakvlakken met infrastructurele aspecten. Hoofdstuk 9: Bouwen met architectuur gaat in op het “werken met de gereedschapskist”, waarmee aan projecten een handvat wordt aangereikt voor het daadwerkelijk werken onder architectuur.

In Hoofdstuk 10: Model-gedreven Architectuur worden de (theoretische) achtergronden en principes van Model Gedreven Architectuur verklaard. De lezer krijgt zo een globaal maar tegelijkertijd helder beeld van de kracht van Model Gedreven Architectuur en de meerwaarde van het werken onder deze architectuur voor software ontwikkeling en beheer voor de organisatie.

Het document wordt afgesloten met een literatuurlijst, een figurenlijst, en appendices waarin onder meer een begrippenlijst en vraagbaak.

Totstandkoming

Dit document is tot stand gekomen als gevolg van het toepassen in de praktijk van softwareontwikkeling bij verschillende organisaties, o.a. bij de Nederlandse Politie. Maar al te vaak worden de mooiste architecturen bedacht op de tekentafel, ver van de praktijk die bij de toepassing niet in staat blijkt de ideeën vast te houden in de hectiek van de dagelijkse praktijk. Dat is hier niet het geval: de referentiearchitectuur is tot stand gekomen door en in de praktijk. Ook de verdere uitbouw van deze architectuur zal alleen maar levensvatbaar blijken wanneer de in de toepassing getemperde ideeën erin gedestilleerd worden. De basis die de afgelopen jaren gelegd is voor dit document door verschillende projecten, zal voor volgende versies en vervolgen geoogst moeten worden uit de praktijk van volgende projecten. Noodzakelijke uitbreidingen op de architectuur waarvoor nog onvoldoende ervaring in projecten is, zullen parallel moeten lopen met de beproeving ervan in pilot projecten. Investeringen in commissies die architecturen uitdenken en vastleggen zijn weggegooid geld wanneer de binding met de werkvloer onvoldoende is.

Betekenis

Wat is de betekenis van dit document? Voor het overgrote deel is ontwikkelen onder architectuur een mensenzaak. Documenten, hoe uitgebreid ook (en vaak juist door die uitgebreidheid) vormen geen garantie dat er ook daadwerkelijk wat gedaan wordt met de ideeën die erin zijn gegoten. Vaak spelen documenten een politieke rol: het staat daar, dus we doen het ook. Of: dus moet je het zo doen. Maar ontwikkelen onder architectuur is vooral de vaardigheid om de vele goede ideeën vast te houden onder de druk van tijd en geld, en in staat te zijn pragmatische beslissingen te nemen zonder dat men uit koers raakt. Die vaardigheid kan dit document niet (en geen enkel document) aanleren maar is een vaardigheid die sommigen zich aanleren in de loop van jaren vallen en opstaan. Succesvol toepassen van de ideeën in dit document staat of valt met de aanwezigheid van dergelijke personen die in de rol van architect het geweten en de inspiratie voor de verdere ontwikkeling van de enterprise architectuur zouden moeten zijn.

4. Algemene uitgangspunten

Speelveld van de Referentiearchitectuur

Het speelveld van de referentiearchitectuur voor Software ontwikkeling en beheer kan goed geïllustreerd worden aan de hand van het IAF architectuurraamwerk.

Dit model is uitgebreid met twee aandachtsgebieden die zó belangrijk werden geacht dat ze op dit niveau geplaatst worden:

1. beveiligingsarchitectuur
2. beheer architectuur.

Het opzetten en tot stand komen van IT ondersteuning is een proces waarbij actieve participatie van de drie partijen, vraag, aanbod en klant/gebruiker heel erg nodig is. De rollen die de vraag- en aanbodorganisaties spelen dienen duidelijk gedefinieerd te zijn, waarbij de activiteiten in gezamenlijkheid ondernomen worden. De benadering in dit document die heel sterk business-centred is, staat of valt met de mate waarin de organisatie zijn verantwoordelijkheid neemt bij het in kaart brengen van de bedrijfscomponenten en –processen.

Dit document gaat vooral over de rood omlijnde ellips binnen de figuur. De referentiearchitectuur voor software ontwikkeling en beheer gaat dus vooral over het applicatiearchitectuur niveau, maar neemt ook expliciet de raakvlakken met informatiearchitectuur, beveiligingsarchitectuur, infrastructuurarchitectuur en een groot stuk van beheer-architectuur mee. Ook in dit geval geldt dat de behoeften van het klantveld, zoals verwoord in de bedrijfsarchitectuur en informatiearchitectuur, primair uitgangspunt zijn. We zullen zien dat een gehanteerd architectuurconcept, namelijk Model Gedreven Architectuur, hetzelfde uitgangspunt heeft.

De referentiearchitectuur voor software ontwikkeling en beheer ondersteunt zowel beleidsmakers, projectleiders, architecten alsook reguliere projectmedewerkers bij het “onder architectuur” werken aan software ontwikkeling en beheer (op inhoudelijke aspecten). De positionering van de referentiearchitectuur in het groter geheel moet worden gecoördineerd. Hiervoor is het architectenteam, met als inhoudelijk eindverantwoordelijke de Enterprise Architect, verantwoordelijk. Het architectenteam bestaat uit de hoofdarchitecten van de verschillende afdelingen van de organisatie. Het team functioneert op basis van consensus (de Enterprise Architect heeft geen beslissingsfunctie) waarbij escalatie direct op directieniveau beland. De praktijk ook bij andere organisaties heeft geleerd dat succesvol werken onder architectuur alleen maar mogelijk is wanneer de lijn ervan direct doorloopt tot op directieniveau. Er zal dus gewerkt moeten worden aan het realiseren van deze lijnen in de organisatie.

Een artikel dat een uitleg geeft van deze lijnen, en de relatie tussen inhoudelijke (“Responsible” in RACI) en executieve (“Accountable” in RACI) is: De verantwoordelijke architect.

Inhoudelijke visie op bouwen onder architectuur

We beschrijven de situatie rondom ontwikkeling en het beheer van applicaties op een peildatum. Daarmee wordt een visie op softwareontwikkeling en –beheer binnen de organisatie geschetst, die als uitgangspunt kan dienen voor de te stellen doelen om de visie te verwezenlijken. Bijvoorbeeld, op 1 januari van het volgende jaar gelden de volgende visie-uitspraken:

1. Alle (business en software-) ontwikkeling is gebaseerd op hergebruik van modulaire componenten.
2. Deze modulaire componenten worden beheerd door een onderdeel van de organisatie die gebruik, ontwikkeling en onderhoud van deze componenten als doel heeft boven en buiten de lopende projecten om.
3. In software ontwikkeling staan de bedrijfsprocessen van de klanten centraal – niet alleen in woord, maar ook in programmacode. Deze alignment is alleen hierdoor valideerbaar. Dit is één van de hoofdprincipes van Model Gedreven Architectuur. Dit is fysiek verankerd in een simulatiemodel van de werkelijke wereld in de software, dat de repository is van de business processen. Dit model is vooral (maar niet uitsluitend) een demand-chain model en wordt gebruikt als basis voor het engineeren van de bedrijfsprocessen van de klant.
4. Met opdrachtgevers wordt periodiek intensief overlegd over de huidige functionele status van applicaties, en de te verwachten wensen voor verbeteringen of vernieuwingen.
5. Business architecten participeren actief binnen de projecten in de rol van eigenaar van de business modellen die als input dienen voor de applicatieontwikkeling.
6. Eigenaarschap, verantwoordelijkheden, escalatielijnen (governance) en technische documentatie zijn voor alle producten, projecten en beheeromgevingen helder en eenvoudig vindbaar ingericht.
7. Ontwikkeling en –beheer gebeurt aan de hand van formeel goedgekeurde richtlijnen en standaarden voor tools, platformen, en andere (technische) middelen. Deze richtlijnen en standaarden worden periodiek ook zelf heroverwogen.
8. De referentiearchitectuur voor ontwikkeling en –beheer heeft een scope van ongeveer tien jaar. Dat wil zeggen dat kan worden verwacht dat softwareontwikkeling volgens Model Gedreven Architectuur ongeveer tien jaar relevant kan blijven.

Doel van de Referentiearchitectuur

Met het ontwerpen, ontwikkelen en beheren van applicaties volgens deze referentiearchitectuur bereikt de organisatie meetbare doelen. Dit lijstje is bedoeld als voorbeeld van het stellen van doelen en deze zo concreet mogelijk te formuleren. Op 1 januari van het komende jaar zou men bijvoorbeeld kunnen stellen:

1. heeft 80% van alle ontwikkelaars en beheerders een opleiding op het gebied van MDA en CBD gedaan en hebben tenminste enige ervaring in tenminste één relevant project opgedaan;
2. is er maandelijks een overleg van projectarchitecten binnen de organisatie onder voorzitterschap van de enterprise architect;
3. zijn verantwoordelijkheden en escalatielijnen ondubbelzinnig vastgelegd en worden ook gehanteerd;
4. is minimaal 80% van “nieuwe” applicaties opgebouwd volgens het principe van CBD (Component Based Development) op objectgeoriënteerde grondslag;
5. is minimaal 40% van de “legacy” applicaties in een migratietraject gekomen voor vernieuwing volgens het MDA principe;
6. zijn alle keuzes voor standaarden in deze referentiearchitectuur die per 1 januari dit jaar zijn gemaakt, bevroren tot 1 januari van het volgende jaar en deze jaarlijkse cyclus herhaalt zich;
7. wordt 80% van alle ontwikkelprojecten binnen tijd en budget opgeleverd;
8. wordt 80% van alle ontwikkelprojecten pragmatisch (maar wel verplicht) met behulp van Prince II èn UP gedaan;
9. is van 80% van alle applicaties alle vormen van project– en productdocumentatie (inclusief architectuurbeslissingen) in een standaard formaat op een standaard plaats beschikbaar;
10. is er een online, web-based ervaringsbank waar projectervaringen per project in proza beschikbaar worden gesteld als leermoment voor nieuwe projecten;

Doelgroep van de Referentiearchitectuur

De doelgroep voor de referentiearchitectuur voor software ontwikkeling en beheer is breed, te weten:

• Opdrachtgevers van projecten op het gebied van ontwerp, realisatie en beheer van applicaties. Zij zijn het die met de kwaliteit van de geboden oplossingen meerwaarde verwachten in hun primaire werkprocessen zoals verwoord in het Referentiemodel Bedrijfsprocessen.
• (Project) Architecten, inclusief de enterprise architect. De projectarchitecten zijn immers verantwoordelijk voor architectuurbeslissingen rondom de bouw en het beheer van applicaties. Zij moeten als geen ander op de hoogte zijn van eisen, meerwaarde, aandachtspunten / risico’s en prioriteiten rondom de enterprise architectuur. Projectarchitecten moeten daarnaast ook, middels de enterprise architect, steeds van elkaars activiteiten op de hoogte zijn.
• Ontwikkelaars en beheerders. Zij zijn het die uiteindelijk de bedrijfszekere ICT realiseren. Het is voor deze doelgroep dan ook zeer belangrijk dat zij het belang onderkent van deze referentiearchitectuur, en de projectarchitect kan volgen in architectuur­beslissingen.
• Projectmanagers en projectleiders. Hoewel het de verantwoordelijkheid van de projectmanager of projectleider is om een softwareontwikkel– (en beheer–) traject tot een goed einde te brengen, is die in hoge mate afhankelijk van de kwaliteit van (inhoudelijke) architectuurbeslissingen. De projectmanager / projectleider enerzijds en de architect anderzijds moeten dus “sparring partners” zijn om de doelen te kunnen bereiken.
• Management. Het MT is gebaat bij een zo snel mogelijke realisatie van bovengenoemde doelen, en daar is de referentiearchitectuur één van de belangrijkste middelen voor.
• Enterprise Architect(-en). Deze zet een “paraplu” architectuur op voor de dienstverlening; deze referentiearchitectuur maakt daar een belangrijk onderdeel van uit (zie Figuur 1: Vierlagen architectuur). Middels de enterprise architect vindt afstemming plaats met andere onderdelen zodat de dienstverlening als geheel eenduidig wordt opgezet.
• Directie. Zij hebben als belang de reputatie naar klanten / opdrachtgevers, en de financiële resultaten. Juist op het gebied van applicaties wordt de organisatie zichtbaar. Daarom is dit document ook van belang voor hen.

Daarnaast is dit document voor partijen buiten de organisatie van belang om inzicht te verkrijgen in de ontwikkelingen op het gebied van architectuur.

Status van dit document

Op inhoudelijke aspecten gelden de richtlijnen, kaders, standaarden en keuzes die in een referentie architectuur zijn vermeld, als standaard voor ontwikkel– en beheeractiviteiten binnen de organisatie. Het is dan ook de verantwoordelijkheid van de projectarchitect om er op toe te zien dat dit binnen projecten ook als zodanig wordt gehanteerd.

5. Business Centred modelleren

Het grote probleem voor business en IT alignment ligt in de zo verschillende uitdrukkingsvormen. Zoals Richard Hubert het uitdrukt in [Hubert, 2002] pagina 27: “… that to increase business flexibility, the business must be visible in the IT model. If a business needs to be changed, then it had better be visible in the design.”

Dit probleem is oplosbaar, maar niet zonder aan beide partijen eisen te stellen. Welke eisen dat zijn, wordt hieronder uit de doeken gedaan. Ook de kant van de business dient zich te realiseren dat succesvol designen en redesignen van de business alleen plaats kan vinden wanneer er krachtige methodes gebruikt worden om die business te modelleren. Dat die technieken uit de IT afkomstig zijn kan wantrouwen opwekken. Er zijn echter geen andere technieken beschikbaar die in staat zijn met complexiteit om te gaan op de benodigde wijze. Wanneer blijkt dat die technieken de business niet dwingen om zich aan te passen aan de IT (zoals in het verleden) is een belangrijk bezwaar ondervangen. Dat is de garantie die de IT dient te geven: wensen van de business dienen niet meer te stranden op bezwaren van de IT dat “de systemen het niet aankunnen”. Ook aan de kant van de IT moet een drempel genomen worden met betrekking tot het gebruik van OO voor het domein component, waarvoor speciale competenties nodig zijn die niet altijd makkelijk te vinden zijn.

Doelstellingen

Met het onderdeel waarin de bedrijfsfuncties of de business logica geïmplementeerd wordt, het Business Model, moeten de volgende doelen bereikt worden:

• Maximale aansluiting bij de binnen het domein of de business gebruikte terminologie (waardoor validatie mogelijk is en wijzigingen begrijpelijk en valideerbaar zijn). Het model spreekt de taal van de business.
• Ondersteuning voor strategische evaluaties van de business: uitwerking van business scenario’s, optimalisatie van business processen, business (re-) engineering en –design.
• Maximale onafhankelijkheid van leveranciers en technische standaarden.
• Maximale onafhankelijkheid van technische hulpmiddelen zoals hardware, programmeertalen en besturingssystemen.
• Maximale onafhankelijkheid van de “waan van de dag” – de voortdurende veranderingen door nieuwe hypes.

Domain-Centred Architecture

Als een (systeem) architectuur ontwikkeld wordt op basis van een business model, en het business model leidend is voor verdere ontwikkelingen, dan wordt een dergelijke architectuur ook wel een “domain-centred architecture” genoemd (zie [Vens, 2002a] en [Vens, 2002b]).

Wat zijn hiervan de kenmerken?

1. Er is een objectgeoriënteerd (OO) model van de business.
2. Het model is een “Roger Rabbit model” van de business. De essentie van dit beginsel 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 genoemd (zie hiervoor [Larman, 2002] en [Fowler et al., 2002]). Dit leidt tot zgn. actieve objecten in tegenstelling tot passieve data-objecten, waar ook de zojuist genoemde referenties voor waarschuwen.
3. Dit model is geschreven in UML.
4. Het model is logisch één model, voor de hele business (en alle applicaties[2]).
5. Voor de ketenpartners vinden wij in het model de service interfaces inclusief SLA’s beschreven.
6. 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.
7. Het model is een exacte replica van de business en draait als het ware een simulatiemodel van die business.
8. In dit model is expliciet tijd mee gemodelleerd: alle gebeurtenissen zijn events op een tijdlijn.

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 architecten. 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 als zodanig in de boeken van Hammer en Champy[3] zo is uitgelegd. Dit is een wijze van re-engineeren die ontleend is aan engineering praktijken afkomstig uit de IT, maar ook uit de procesindustrie (Boeing, Toyota[4]). Centraal hierin staat de implementatie van bedrijfsprocessen als een twee-richtingen stroom:

1. Supply chain
2. Demand chain

De supply chain is de bekende “hoe kom ik van grondstof tot eindproduct” van veel procesmodellen. De demand-chain is een inverse stroom, vergelijkbaar met resultaatgericht werken. De te leveren functionaliteit geldt als startpunt, het komen tot dat eindresultaat wordt als het ware terugberekend op basis van de beschikbare componenten met hun services.

Wat betekent dit voor de huidige praktijk? Voor bijvoorbeeld fuzzy zoeken in search engines die gebruikt moeten worden bij de uitvoering van recherchewerk, of het electronische dossier zijn demand-chain gegenereerde processen van onschatbare waarde. Bij gestandaardiseerde bedrijfsprocessen of workflows die sterk geformaliseerd zijn zijn demand-chain processen minder nuttig: daar zullen supply-chain procesmodellen beter op zijn plaats zijn. Supply-chain processen zijn forward-chaining, demand-chain processen zijn backward-chaining.

Voorbeeld: Een rechercheur wil beginnen met een zaak. In plaats van, zoals vroeger nodig was, in verschillende systemen uitgebreide speurtochten op te zetten naar alle informatie die mogelijk relevant is voor zijn zaak, zal het nieuwe systeem automatisch informatie pushen naar aanleiding van niets anders dan het invoeren in het systeem van de situatie waar de rechercheur zich nú in bevindt: dit is het voorval, dit zijn de betrokkenen, dit zijn de relevante feiten. Interactie met het systeem heeft uitsluitend tot doel zo snel mogelijk die interne replica van de buitenwereld te synchroniseren met de werkelijke wereld.

Het invoeren van de zaak in het systeem zal de replica van de werkelijke wereld creëren in de software. Deze replica wordt vervolgens gebruikt om uitspraken te doen over de behoeftes van de actieve objecten binnen het model. Er is bijvoorbeeld een moordenaar, die zichzelf dient te identificeren en te arresteren (wellicht ten overvloede: dit is in het model). Vanuit het software model is het dan mogelijk een aantal “automatische” assumpties te doen over de benodigde stappen die genomen moeten worden en de informatie die (vanuit de onoverzichtelijke brei aan beschikbare informatie, inclusies datawarehouses) relevant is voor de recherche. Sleutelbegrip in deze context is dus het modelleren van objecten (bijv. moordenaars) in de vorm van actieve objecten die één doel hebben: zichzelf arresteren. Dit is een demand-chain procesmodel: terugredenerend vanuit de arrestatie (uiteindelijk te bereiken doel) alle noodzakelijke processen uitrollen om het doel te bereiken.

Het is van belang dat de ontwikkeling en beheer van deze domeinmodellen onder verantwoordelijkheid van Enterprise Architectuur komt te vallen. Alleen op die manier kan de garantie van hergebruik van modellen en componenten ook daadwerkelijk gegeven worden. De validatie van de door de gebruiker/opdrachtgever aangeleverde business case dient ook te geschieden aan de hand van de domein modellen waarmee de business analist werkt. Aansluiting op de business kan door de modellen zélf gevalideerd worden. Recente ontwikkelingen op het gebied van business modeling zoals executable UML kunnen hierin worden meegenomen. Objectmodellen moeten in staat zijn de kritische processtromen inzichtelijk te demonstreren, bijvoorbeeld door een flow-diagram te genereren dat door business experts gevalideerd kan worden. De kracht van deze business modellen wordt hier onmiskenbaar in gedemonstreerd.

Eigenschappen van het Business Model

Dit Business Model kan men 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 ook de bedoeling omdat het meestal hulpmiddelen zijn om complexiteit te managen.

Met het Business Model is echter iets bijzonders aan de hand:

1. De componenten in het model bevinden zich op verschillende aggregatieniveau’s (Babushka principe). Dat betekent dat het eenvoudig is delen van het model te vinden die zich lenen voor implementatie als reusable run-time componenten (CBD).
2. De componenten in het model bevatten alleen verantwoordelijkheden. Het is géén datamodel: objecten die geen verantwoordelijkheden (lees: gedrag) hebben komen niet voor.
3. Relaties tussen objecten zijn puur en alleen maar ontstaan omdat objecten voor de realisatie van hun verantwoordelijkheden samen moeten werken met andere objecten. Ook dit is weer geheel anders dan relaties op basis van gegevensrelaties: er zullen daadwerkelijk andere relaties uitkomen.
4. Het is executable, dat betekent dat het gebouwd is en draait op computers. Dus geen papieren document dat na verloop van tijd niet onderhouden is, zodat alleen nog de “code” een correcte weergave is van het systeem.
5. Het model heeft de pretentie geen informatie weg te laten en op den duur een volledige representatie te zijn van de business.
6. De business is mede ontworpen aan de hand van deze business modellen. Het model is geen IT feestje!
7. Re-engineering van de business, mocht dat nu of in de toekomst nodig zijn, vindt plaats op basis van dezelfde modellen.
8. Strategische toekomstscenario’s kunnen worden geëvalueerd door deze uit te werken in de modellen. Deze modellen lenen zich daar ook bij uitstek voor.

De voordelen van de aanpak zijn:

1. De domeinobjecten zijn onafhankelijk van technische implementatie.
2. Kenmerken van en wijzigingen in het business domein kunnen nagenoeg één op één worden overgenomen in de domeinobjecten. De gevolgen van deze wijzigingen zijn direct inzichtelijk. Domeindeskundigen kunnen direct aan de domeinobjecten worden ‘gekoppeld’.
3. De levensduur van domeinclasses wordt niet meer bepaald door de implementatietechniek, maar door de business. Vuistregel hierbij is:
   1. Domeinclasses: 10-20 jaar
   2. Database functionaliteit: 5 jaar
   3. Gebruikersinterface/communicatie: 2 jaar
4. Een ‘live’ domein biedt radicaal nieuwe mogelijkheden, die het werk op heel andere manieren kunnen gaan ondersteunen dan tot nu toe gebruikelijk
5. Technische service componenten zijn middels de eenvoudige interface goed aan te koppelen, dan wel te vervangen (zie hiervoor hoofdstuk 4.5 Services).
6. Ontwikkeling en beheer van de technische service componenten is relatief (t.o.v. de domein component maar ook in vergelijking met traditionele applicaties) eenvoudig en er is een lager competentieniveau nodig van de ontwikkelaars.
7. Domein componenten zijn relatief niet omvangrijk: 5 tot 10% van het gehele systeem. Toch bepalen zij vrijwel volledig de functionaliteit van de gebouwde applicaties.

Mogelijke nadelen zijn:

1. Het invoeren van de MDA aanpak zal gevolgen hebben voor de werkwijze van de ontwikkelorganisatie: vooral het Domein zal objectgeoriënteerd (OO) worden ingericht. Het is bekend dat er speciale vaardigheden vereist zijn om werkelijk goed OO te denken en werken.
2. Door de introductie van meerdere lagen kan de performance van het systeem lager worden, in het bijzonder de response-tijd. Het is van belang zich te realiseren dat dit een gemanaged probleem is waar vele oplossingen voor zijn. De architectuur is zodanig opgezet dat op velerlei plaatsen optimalisaties mogelijk zijn zonder de complexiteit te vergroten. Performance zal hierdoor in de praktijk nooit een probleem hoeven te worden. De architectuur (door de vele adapterlagen die componenten van elkaar scheiden, en het gedistribueerde karakter van de architectuur) is juist gebouwd voor dit soort optimalisaties, in plaats van daar weerstand aan te bieden.
3. Doordat afgedwongen is dat alle business logica in het business component gerealiseerd wordt, kan het voorkomen dat ingekochte of standaardcomponenten dezelfde functionaliteit bevatten (bijvoorbeeld een beveiligingscomponent of een inference engine met business rules). Hierdoor zal enige dubbeling ontstaan. Dit is in de praktijk tot nu toe nooit een probleem gebleken omdat de realisatie in de business domein component vrijwel volledig technologie-onafhankelijk is. Het probleem dient gemanaged te worden door de inzet van deskundigen die het probleem en de oplossing kennen. Strategie is dus: bouw alle business logica die in technische service componenten zit na in het domein. Maar alleen de business logica, niet de technische onderdelen die ermee verweven zijn!
4. De OO metafoor zal in principe in staat zijn alle procesaspecten gedistribueerd op te lossen. Bij de realisatie in runtime componenten (zeker bij ontwikkeling van coarse-grained components[5]) zal misschien een gedeelte niet passen binnen de verzameling componenten. Voor deze situatie wordt de mogelijkheid opengehouden deze te plaatsen binnen aparte procescomponenten. Dit moet zorgvuldig gebeuren omdat het risico bestaat dat mensen die gewend zijn binnen een traditioneel proceskader te denken (bijvoorbeeld functionele decompositie) hier te makkelijk misbruik van gaan maken.
5. Voor technische persistency services worden vaak relationele databases gebruikt. Voor de afbeelding van de objectmodellen in dit soort databases dient een mapping (O-R mapping) plaats te vinden van de objectgeoriënteerde wereld op de relationele wereld. Hiervoor zijn hulpmiddelen beschikbaar. Het blijft echter een complexe materie waarvoor tijd ingepland zal moeten worden binnen de projecten. Het streven moet zijn om het OO model te optimaliseren op flexibiliteit en uitbreidbaarheid, en het ER model op stabiliteit en performance. Hierdoor is het niet wenselijk beide modellen in-sync met elkaar te laten lopen. De hulpmiddelen maken het mogelijk dat deze modellen uit-sync lopen (en ook mogen lopen!) op een beheerste manier.
6. Bij het gebruik van objectgeoriënteerde databases zijn deze problemen niet aanwezig. Het gebruik van OO databases wordt te overwegen naarmate de datastructuren complexer worden, bijvoorbeeld bij gebruik van multimedia. Vaak is onbekend dat objectgeoriënteerde databases een lange en indrukwekkende staat van dienst hebben en minstens even geschikt zijn voor industriële toepassingen. Vooral de performance van OO databases is beter dan die van relationele databases. Veel van deze overwegingen gaan ook op voor NoSQL databases.

6. Logische referentiearchitectuur

Inleiding

De logische applicatie architectuur partitioneert een informatiesysteem in een domein en een aantal generieke services en wordt formeel gemodelleerd in UML. Het domein staat centraal voor zowel de specificatie van de functionaliteit als de realisatie van het systeem (waarbij de generieke services gebruikt zullen worden) en draagt zorg voor de integriteit van het systeem. De generieke services kunnen gebruikt worden ten behoeve van andere domeinen en zijn dus speciaal ingericht voor hergebruik. Door de losse koppeling (met adapters, waarover later meer) kunnen deze generieke services onafhankelijk gespecificeerd en gebouwd worden van de specifieke domein-functionaliteit. De koppeling tussen de services en het domein is configureerbaar, en wordt bepaald door de functionaliteit die op een bepaald moment nodig is. De koppelingen worden gerealiseerd met zgn. adapters.

Met de logische applicatie architectuur worden de volgende doelen bereikt:

1. Hergebruik van domein logica, over verschillende applicaties heen (geen hergebruik van modellen of code, maar van de daadwerkelijke runtime componenten)
2. Optimaal hergebruik van services.
3. Continue consistentie tussen specificatie en implementatie van het domein.
4. Onafhankelijkheid tussen technische realisatie en logische specificatie.

Voor de uitvoering moet worden gekeken naar domeinen en services die de organisatie momenteel biedt of binnen een jaar wil gaan bieden.

Uitgangspunten

De logische applicatie architectuur verdeelt een systeem in een domein en een aantal generieke services, waarbij er een losse koppeling bestaat tussen de services en het domein ten behoeve van een flexibele configuratie van de applicatie. De logische applicatie architectuur stelt domeinlogica centraal en is leidend voor de verdere ontwikkelingen van het systeem, zowel voor wat betreft de services als de technische implementatie. Merk op dat het domein, net als de services, onafhankelijk van de services geïmplementeerd kan (en moet) worden.

De logische modellen worden formeel beschreven met UML. De visie om middels “Model Gedreven Architectuur” de architectuur te realiseren wordt toegepast door het hanteren van duidelijke richtlijnen voor het gebruik van services en het koppelen van services aan het domein.

Met de logische applicatie architectuur worden de volgende doelen bereikt:

1. Hergebruik van domein logica, over verschillende applicaties heen. Voor een bepaalde toepassing is er één logisch referentie domein waar meerdere applicaties gebruik van maken.
2. Het onderkennen van generieke services en raamwerken om hergebruik te bevorderen.
3. Een consistente specificatie van de functionaliteit, ten gevolge van de integriteit tussen specificatie en implementatie van het domein.
4. Onafhankelijkheid tussen technische realisatie en logische specificatie. Deze ontkoppeling geeft de mogelijkheid om technische en niet-functionele wijzigingen door te voeren zonder de functionele integriteit te schenden (daar zorgt het domein voor).
5. Door de ontkoppeling tussen technische realisatie en domein specificatie, kunnen de niet-functionele eisen, zoals schaalbaarheid, performance en beschikbaarheid, belegd worden op de plaats waar ze thuis horen: bij de technische realisatie. Het is natuurlijk niet zo dat functionele eisen geen enkele consequentie hebben voor de niet-functionele requirements, maar de aangeboden aanpak zal alleen de grens een flink stuk verleggen.
6. De mogelijkheid om gerealiseerde servicecomponenten te vervangen door marktproducten, waarbij impact op bestaande systemen geminimaliseerd blijft.

Onderdelen

Een logische applicatie architectuur bestaat uit de volgende onderdelen:

1. Een domein
2. Één of meerdere services
3. Adapters ten behoeve van de koppeling van de services aan het domein
4. Één of meerdere satellieten
5. Een applicatie configuratie

In Figuur 2. Een architectuur zonder satellieten wordt een schets gegeven van de onderdelen en hun logische relatie, zonder de satelliet. Het is niet mogelijk dat domein objecten rechtstreeks met de service componenten communiceren. Adapters functioneren altijd als connectoren tussen domein en buitenwereld. Figuur 3. Een architectuur met satellieten geeft een schets met een satelliet.

Met service componenten worden technische services bedoeld. Applicaties en coarse-grained componenten (bijvoorbeeld Persoon) zullen ook services definiëren. Dit zijn business services. De coarse-grained componenten worden ook wel business components genoemd. Wanneer in dit document over services wordt gesproken worden meestal technische services genoemd.

In de opvolgende hoofdstukken wordt elk onderdeel nader bekeken.

Domein

Definitie

Een domein bevat het business model waarvoor een systeem bedoeld is. Het model is een afspiegeling van die business. Er kunnen dus meerdere domeinen zijn. Een domein is een logische partitionering van de business.

Kenmerken domein model

1. Het business model is platform en technologie onafhankelijk.
2. Het domein is een afspiegeling van de business.
3. Objecten die voorkomen in het domein hebben in veel gevallen een representant in de buitenwereld. Hierbij valt een algemene vuistregel te hanteren dat objecten die in de buitenwereld actief zijn (politiemensen) in het model passief zijn en vice-versa (gestolen goed). Dit heeft te maken met een strategie voor reductie van complexiteit en afleiden van bedrijfsprocessen op basis van hoofddoelen (boef: arresteer jezelf). Het is een resultaat van demand-chain procesmodelleren.
4. Een domein moet objecten bevatten die representatief zijn voor de business.
5. Domein classes hebben geen kennis van objecten buiten het domein, tenzij het algemene technische hulpclasses zijn (voorbeeld: een collection class).
6. Domein objecten communiceren met elkaar enkel en alleen middels boodschappen of berichten (synchrone communicatie)[6].
7. 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’ genoemd. Objecten nemen initiatief, hebben doelen, zijn actief, delegeren en doen alleen dat wat onder hun verantwoordelijkheid valt (zie [Vens, 2002a]).
8. Objecten hebben in principe slechts één verantwoordelijkheid (algemeen principe). Bij toenemende complexiteit worden objecten opgesplitst. Zij delegeren dan de verantwoordelijkheid aan partners.
9. Objecten werken met andere objecten samen maar doen dit niet met teveel anderen. Dat zou de vuistregel “objecten zijn eenvoudig” geweld aandoen.
10. Het domein doet semantische validatie. Syntactische validatie (zoals NULL pointers) mag niet voor problemen zorgen[7].
11. Vanuit het domein mogen geen exceptions afgegeven worden. Als er in het domein een exceptie optreedt, duidt dit op een inconsistente situatie waarbij er geen gecontroleerde voortgang meer mogelijk is (de toestand van het domein is “niet gedefinieerd”).
12. Interactie met het domein vindt plaats volgens een vooraf gedefinieerd model. Bij het gebruik van het adapter model zullen de domein objecten notificaties afgeven aan de services om daarmee aan te geven dat een domein object veranderd is (zie hoofdstuk 4.6 Adapters).

Voor de totstandkoming van het domein model gelden de volgende technieken:

• Er wordt gebruik gemaakt van een referentiemodel voorzover beschikbaar. Dit model bevat een lijst van de gestandaardiseerde begrippen binnen het business domein. Dit referentiemodel beschrijft de begrippen en hun definities. Het wordt gebruikt voor de totstandkoming van de lijst van kandidaat classes. Het gebruik ervan binnen het domein model is puur afhankelijk van de business context van de applicatie en zal dan altijd een subset van dit referentiemodel zijn, vaak ook exclusief de relaties omdat die tot stand komen op basis van verantwoordelijkheden (zie volgende punt).
• Op basis van deze lijst van kandidaat classes worden typische scenario’s uitgekozen voor een reeks van CRC sessies. Voor het uitvoeren van CRC sessies zie o.a. [Bellin et al., 1997]. Deze sessies worden gebruikt om
  • de kandidaat classes te selecteren die van toepassing zijn binnen het project
  • de verantwoordelijkheden te vinden van deze classes
  • de relaties van deze classes op basis van de verantwoordelijkheden (collaborators). Let op: deze relaties zijn niet vergelijkbaar met gegevensrelaties! Objecten hebben relaties met andere objecten omdat ze die objecten nodig hebben voor het realiseren van die verantwoordelijkheden.

Het resultaat is een analysemodel van de applicatie. Een analysemodel heeft de volgende kenmerken:

1. Het bevat geen attributen, of voorzover zij aanwezig zijn, zijn deze slechts bedoeld om zgn. accessors aan te geven: een interface die een weet-verantwoordelijkheid aangeeft. Bijvoorbeeld een persoon heeft een naam. In dit model geeft dit aan dat we hem kunnen vragen om zijn naam. Of dit daadwerkelijk ook in het implementatiemodel tot een attribuut wordt is niet relevant (het zou net zo goed een associatie kunnen zijn).
2. In dit model zijn alle associaties private, en alle boodschappen public.
3. Het model is volledig programmeertaal onafhankelijk.
4. De classes zijn in principe actieve classes. Formeel houdt dit in dat elke class zijn eigen thread-of-control heeft, het behelst in de praktijk dat multithreading niet gedefinieerd hoeft te zijn in analyse modellen.

Services

Met service componenten worden technische services bedoeld: binnen het business domein is ook sprake van services, maar dit zijn functionele of business services.

Definitie

Een (technische) service component is een generieke dienst, noodzakelijk en ondersteunend voor het business model. Een service biedt dus een ondersteuning aan voor het gedrag van het business model, maar kent zelf geen business logica.

Maak een overzicht van de services zoals die binnen de organisatie gelden. Standaard zullen de volgende services vrijwel altijd aanwezig moeten zijn:

• Generieke Logging, voor het uitvoeren van logging
• XML Communicatie, voor het uitwisselen van berichten middels XML over HTTP
• Security, voor het gebruik van een paspoort waarmee autorisatie mogelijk wordt
• Persistency, voor het vastleggen van de objecten

Kenmerken

1. Een service component kent geen business logica van het domein.
2. Een service component heeft kennis van de objecten in het domein.
3. Een service component heeft geen kennis van andere service componenten (alle interacties verlopen via het domein dat in de naaf zit van het wiel, de services zijn de spaken).
4. Een service component is voor elk object in het domein beschikbaar.
5. Een service component heeft een façade die als interface dient met het service component.

Voor zover de service component business logica bevat, is dat zuiver en alleen op basis van een delegatiemodel dat in het business domein is geïmplementeerd. Daar bevinden zich de objecten die bepaalde verantwoordelijkheden hebben. Die verantwoordelijkheden worden echter uitgevoerd door objecten in een service component. Objecten in het domein zullen daartoe relaties hebben met zgn. stubs in het domein, die via adapters communiceren met de componenten in de service component.

Hierdoor kan de situatie ontstaan die al eerder is aangegeven, dat functionaliteit in domein en service component dubbel aanwezig lijkt te zijn. De summiere uitleg hier dient om aan te geven dat dit zeer beperkt is en geen probleem in de praktijk hoeft te zijn. Wel is het aan te raden de wijze waarop de functionaliteit in de service component wordt aangesproken te laten aansturen door het domein. Dit leidt tot realisatie waarbij de structuur van de business logica in het domein gerepliceerd wordt in de service component. Dit noemen we beheerst inzetten van technische service componenten (business domein is leidend).

Adapters

Definitie

Een adapter component realiseert de koppeling tussen het domein component en de verschillende service componenten. Een adapter component bevat verschillende adapters voor zowel de objecten in het domein (de zgn. ‘aspect adapters’) als wel de objecten in de service componenten (de zgn. ‘façade adapters’). Adapters zijn als het ware de stekkers voor de service componenten om zich te verbinden aan het domein. Adapters zijn simpele objecten, die onderdeel uitmaken van het framework. Rechtstreekse koppelingen tussen domein objecten en service componenten zijn nooit toegestaan.

Kenmerken

De berichtenuitwisseling tussen objecten in het domein en de adapters vindt plaats middels (vooralsnog synchrone) ‘messages’ of ‘events’: messages worden gebruikt voor berichten gericht aan domeinobjecten, events worden gebruikt voor berichten naar de adapters.

De reden van deze vorm van berichtenuitwisseling is dat de services (de “buitenwereld”) wèl kennis mogen hebben van de opbouw van het domein, terwijl domeinobjecten géén kennis mogen (en zullen) hebben van de services (en dus alleen middels ‘events’ kunnen communiceren).

De adapters voor de domeinobjecten kennen de specifieke interface van het domein object, zijn slechts bedoeld voor één aspect van het domein object (vandaar de naam ‘aspect adapter’) en bieden een generieke interface aan voor de koppeling met de adapters van de service componenten.

Voorbeeld: Een object Persoon heeft twee aspecten: naam en adres. Een service component GUI is hiermee gekoppeld door middel van twee invoervelden die respectievelijk naam en adres tonen via twee aspect adapters die alleen luisteren naar respectievelijk naam en adres.

Adapters worden ook gebruikt om vendorspecifieke extensies van servicecomponenten aan te spreken, mocht hieraan behoefte zijn. Door deze extensies te isoleren binnen de adapters blijven de consequenties van het gebruik beperkt tot de adapters. Het is niet toegestaan binnen applicaties vendorspecifieke extensies rechtstreeks aan te spreken.

Adapters zijn vrijwel altijd “geketend”, dat wil zeggen dat we vrijwel nooit een situatie tegenkomen waarin een business component via slechts één adapter is gekoppeld met een technische service component. Om de vuistregel te handhaven dat adapters extreem light-weight en simpel zijn, gebruiken we verschillend geconfigureerde adapters die aan elkaar gekoppeld worden, en waarvan elke individuele adapter één aspect “adapt”.

Satelliet

Definitie

In tegenstelling tot de services (die functionaliteit bieden die niet business-specifiek is maar wel noodzakelijk is voor de business) bieden satellieten een functionaliteit die niet noodzakelijk is voor de business. Satellieten mogen geen business logica bevatten die tot de business behoort. Vaak is de business-logica een metamodel van de service.

Kenmerken

Hoewel de (technische) service componenten geen eigen logica kennen, kan het zijn dat er bepaalde logica benodigd is, welke niet direct onderdeel uitmaakt van het domein. Dit soort logica (men zou kunnen spreken van de businesslogica van de service) wordt dan opgenomen in een autonome applicatie – dit is een Satelliet – met een eigen architectuur, welke dan weer middels Service Componenten communiceert met het domein en/of de buitenwereld. In principe maken satellieten geen gebruik van service componenten van het core-domein voor andere doeleinden dan het benaderen van het core-domein.

Deze aanpak garandeert dat ook service componenten dezelfde architectuur hebben. Deze herhaling op verschillende aggregatieniveaus wordt ook wel een fractale architectuur genoemd.

Voorbeeld: Een persistency service component zal de “business-logica” bevatten om met een database te communiceren. Concepten als persistentie, tabel, mapping van attributen op velden, zullen voorkomen in de vorm van objecten in het “business-model” van deze service component. Deze “domein-objecten” zullen geen directe koppeling met andere onderdelen van de persistency service component kennen maar alleen via een event mechanisme daarmee communiceren.

Configuratie van de applicatie

Definitie

De logische applicatie architectuur zegt in principe niets over de technische uitvoering (“executeren”) van een bepaalde functionaliteit. Binnen de architectuur zijn applicatie componenten daarvoor verantwoordelijk. Een applicatie is dus een object dat aanwezig is in de design modellen (niet in de analyse modellen).

Kenmerken

De applicaties zijn de representanten van één of meerdere Use Cases die de gewenste functionaliteit(en) beschrijven. Een applicatie gebruikt (een deel van) het domein en een aantal service componenten. Dit vereist een juiste koppeling tussen het domein en de service componenten middels de adapters.

Toch moet er ergens kennis zijn over de (domein-)objecten en die wordt geplaatst in Applicaties. Dit zijn containers van adapters die de benodigde adapters aanmaken en de parameters (het attribuut van een domein object bij een aspect adapter) instellen. Het koppelen van domein objecten met service componenten wordt dus gedaan door Applicatie objecten, met adapters die zij maken en beheren.

Voorbeeld: Een applicatie genaamd Boef zal de functionaliteit die het veld nodig heeft om met een Boef dingen te kunnen doen beschikbaar stellen. Een boef zal gearresteerd kunnen worden, opgespoord kunnen worden. Wijzigingen aan een boef (bijvoorbeeld zijn verblijfadres) zullen ingevoerd moeten kunnen worden en ook persistent zijn. De applicatie wordt geïnstantieerd en met het domein object (“Boris Boef”) gekoppeld. De applicatie zal zelf de benodigde adapters bouwen, deze configureren om met allerlei aspecten van de boef te communiceren, en de user interface genereren of er contact mee zoeken.

Beveiliging

Gezien de ontwikkelingen van de laatste jaren is het niet verwonderlijk dat groot belang wordt gehecht aan de beveiliging van ontwikkelde software. Dit hoofdstuk vormt een startpunt voor uitgebreide richtlijnen voor ontwikkelaars.

Definitie

Autorisatie is het gehele proces dat het mogelijk maakt de toegang tot beveiligde entiteiten te beperken tot gerechtigde gebruikers. Gebruikers hebben toegekende rechten (veelal gekoppeld aan rollen). Beveiligde entiteiten stellen eisen aan benodigde rechten.

Elke keer als een object aan een ander object iets vraagt (denk in termen van verantwoordelijkheden: ik ben een object dat iets moet doen als gevolg van een verantwoordelijkheid, en dus zal ik alleen een ander object iets vragen omdat ik dat object nodig heb om mij daarbij te helpen), zal in een geautoriseerde context de ontvanger van de boodschap aan de zender vragen: “mag dat?”

Dit is een domeinverantwoordelijkheid. De ontvanger zal het de “mag-dat” verificatie doen door de credentials van de zender te controleren. Dat kan omdat in deze geautoriseerde context voortdurend zogenaamde paspoorten meegestuurd worden waarin de benodigde credentials opgezocht kunnen worden. Omdat het meegestuurde paspoort van de oorspronkelijke vrager is, kunnen de autorisaties van dit object gebruikt worden voor het matching proces. Het paspoort weet voor welke handelingen de eigenaar van het paspoort geautoriseerd is.

Voorbeeld: Een agent vraagt aan een boef: arresteer jezelf. De boef vraagt aan de agent: wie ben jij dat je dit mag vragen? De agent toont vervolgens zijn badge, en de boef stemt in met de arrestatie.

Mocht de arrestant bijvoorbeeld een diplomatieke status hebben dan kan de agent dergelijke handelingen niet verrichten.

Kenmerken

Voor de implementatie van beveiligingscomponenten in applicaties die onder een Enterprise Architectuur ontwikkeld worden geldt hetzelfde als voor allerlei andere functionaliteit die gewenst of noodzakelijk is: hoort het bij het domein waarvoor de applicaties ontwikkeld worden of niet? In dat laatste geval implementeren we de functionaliteit in service componenten, waarvoor echter de vraag op een ander aggregatieniveau weer terugkeert. Immers isolatie van complexiteit in het domein component is een algemene strategie om complexiteit beheersbaar en schaalbaar te maken.

Autorisatie en authenticatie, de twee voornaamste beveiligingscomponenten, bevatten een wezenlijk domein gedrag: beveiliging is een sleutelbegrip, ook los van de techniek. Zo is het voor bepaalde ambtenaren toegestaan om personen te arresteren en in de gevangenis te plaatsen, voor anderen niet. Uitzonderingen als politieke onschendbaarheid maken dit domein ook nog complex, een duidelijke rechtvaardiging om dit te implementeren in de domein component om te voorkomen dat dit onderdeel niet flexibel wordt en door de complexiteit kostbaar om te realiseren.

Doordat beveiliging door allerlei leveranciers beter wordt opgepakt dan in het verleden worden echter steeds meer onderdelen van dit domein overgenomen door de gebruikte producten: databases, applicatieservers, en specifieke producten als autorisatie en authenticatie servers.

Dat wil echter niet zeggen dat dit aspect dan maar geheel uit het domein hoeft te verdwijnen, integendeel juist. De vuistregel gaat ook hier op dat producten zoveel mogelijk de functionaliteit moeten invullen, maar dat de integratie en orkestratie buiten die producten dient te liggen: in het domein component. Door het gebruik van de adapters is het mogelijk elke technische service aan te koppelen waardoor de functionaliteit die binnen het domein is gedefinieerd door de technische component ingevuld kan worden.

Soorten van Autorisatie

Binnen het werkingsgebied van de AAS (Autorisatie en Authenticatie Service) worden twee soorten autorisatie onderscheiden. Ten eerste is er de beveiliging op het niveau van de functionaris: aan de hand van de rechten binnen de applicatie welke hem of haar uit hoofde van zijn/haar functie binnen de organisatie zijn toebedeeld, wordt functionaliteit wel of niet toegankelijk gemaakt. Dit wordt de functieautorisatie genoemd.

Naast de functie van degene die een gegeven wil raadplegen of muteren is ook de aard van de gegevens en de organisatie waarbinnen zij geraadpleegd, gemuteerd of aangeleverd worden bepalend voor het feit of die gegevens wel dan niet geraadpleegd, gemuteerd en of verwijderd mogen worden door deze persoon. Dit noemen we de gegevensautorisatie.

Voorbeeld: een medewerker van de IND kan dezelfde functie-autorisaties krijgen voor het bevragen van personen als een politie-beambte (=functieautorisatie), maar zal toch uitsluitend gegevens ten aanzien van geregistreerde vreemdelingen te zien krijgen, terwijl de agent  nagenoeg alles te zien krijgt: boetes, ontsnapte gevangenen, smokkelaars etc. Gegevensautorisatie maakt hier het onderscheid.

Het is in theorie mogelijk om gegevensautorisatie te implementeren als een vorm van functieautorisatie: er worden dan meerdere sterk op elkaar gelijkende functies gebouwd, die alleen van elkaar verschillen in de wijze waarop de autorisatie op de gegevens wordt uitgevoerd. Dit is echter vanuit een praktisch oogpunt slecht schaalbaar (zowel voor applicatiebeheer, als voor het software onderhoud), en bovendien strijdig met doelstellingen als het toepassen van herbruikbare componenten. In feite leidt het al snel tot het anti-pattern van copy and paste programming. Er is echter waarschijnlijk wel een kantelpunt aan te wijzen, waarop er zoveel context-informatie aan de “mag dat?”-vraag moet worden meegegeven, dat de hier beschreven vorm van gegevensautorisatie niet meer praktisch toepasbaar is.

Loskoppeling Handhaving

Handhaving	Ingang voor het naleven van de in de autorisatieregels opgeslagen eisen aan de beveiliging. De te beveiligen applicatie vraagt de AAS om een beslissing en dient daartoe voldoende context-informatie aan te dragen.
Autorisatie Regels	Concrete weerslag van de eisen uit wetten en reglementen ten aanzien van het gebruik van de te beveiligen applicaties (in de vorm van beveiligde objecten, gebruikers en de bijbehorende rechten)
Beheer	Voorziening om de autorisatieregels te beheren
Controle	De werking en het gebruik van de AAS dient te allen tijde gecontroleerd te (kunnen) worden.

Voor applicatieontwikkeling onder architectuur is de strategie het loskoppelen van de handhavingcomponent van de applicaties, en als gevolg hiervan ook het buiten de scope van softwareprojecten plaatsen van deze component. In Figuur 8. Het HABC van Autorisatie is dat einddoel verwezenlijkt in een infrastructuur die de handhaving heeft overgenomen van alle applicaties.

7. Technische referentiearchitectuur

De hierboven voorgestelde logische architectuur zal gerealiseerd moeten worden met verschillende technologieën, op basis van verschillende platformen. Dit hoofdstuk geeft een overzicht van de al gebruikte platformen en de relatie met de logische architectuur.

Samenvatting

Een technische referentiearchitectuur moet de belangrijkste designprincipes tonen voor het ontwikkelen van systemen. De consequenties voor het doorvoeren van deze designprincipes zijn in twee delen te groeperen:

1. In de eerste plaats heeft de gekozen architectuur technische consequenties voor de te maken systemen. Er kunnen consequenties zijn op het gebied van performance, schaalbaarheid en leverancier– en platformonafhankelijkheid. Dit zijn wezenlijke factoren voor de kwaliteit van een systeem.
2. Het kiezen van een technische referentiearchitectuur heeft naast technische ook organisatorische of methodische consequenties. Voorbeelden hiervan zijn: mogelijkheden van hergebruik, functionele flexibiliteit van de systemen, testbaarheid van de systemen en productiviteit van het ontwikkelproces.

Wanneer verschillende architecturen vergeleken worden blijken de verschillen op het gebied van de technische consequenties zeer minimaal; zo zijn de performance– of schaalbaarheidsverschillen tussen twee zeer verschillende architecturen als J2EE en .NET minimaal. Op het gebied van methodische consequenties blijken alternatieve architecturen veel meer te verschillen. De hier beschreven technische referentiearchitectuur is dan ook vooral gebaseerd op methodische doelstellingen en principes (zie paragraaf 5.3 Uitgangspunten en architectuurprincipes). Naast deze architectuurprincipes zijn een aantal technische randvoorwaarden benoemd (Zie paragraaf 5.4 Technische randvoorwaarden). De keuze voor deze technische randvoorwaarden valt buiten de scope van de technische referentiearchitectuur.

De technische referentiearchitectuur is voor een groot gedeelte gebaseerd op het principe van model-driven-architecture (MDA) zoals dat gedefinieerd is door de Object Management Group (OMG, zie: http://www.omg.org ). MDA is gebaseerd op het genereren van systemen op basis van domeinmodellen. De technieken voor dit genereren zijn momenteel nog niet voldoende volwassen; de beschikbaarheid van hulpmiddelen is snel aan het toenemen.

De hier beschreven technische referentiearchitectuur is een “handmatige” toepassing van MDA. Die is gebaseerd op onderdelen die wel al volwassen zijn en binnen objectgeoriënteerde en component-based software engineering tot de “proven technologies” behoren. Hiermee biedt de technische referentiearchitectuur de mogelijkheid om uit te groeien naar een werkelijke toepassing van MDA. Tegen die tijd kan een beslissing genomen worden over de toolondersteuning. Dit houdt in dat nu nog geen codegeneratie op basis van platform-onafhankelijke modellen plaatsvindt. Dit is typisch een onderdeel dat door tools ondervangen zal kunnen worden. De behoefte bestaat aan tools die round-trip engineering op een zo transparant mogelijke wijze ondersteunen, waarbij modellen en code zelden voortdurend in sync lopen. Bijvoorbeeld de tool Rose van Rational (nu IBM) is hier niet geschikt voor.

De afbeelding van de verschillende modellen op elkaar vindt plaats door formele transformatieregels die ondersteuning met hulpmiddelen mogelijk maken. Transformatie vindt nooit plaats door ad-hoc of handmatige vertalingen (semantische afgrond). Rumbaugh noemt dit “naadloze ontwikkeling” ([Rumbaugh et al., 1991]). Moderne softwareontwikkeltechnieken maken het mogelijk met één uniform model te werken in alle stadia van software ontwikkeling. UML maakt het zelfs mogelijk dezelfde modellen te gebruiken voor de business.

Aansluiting Technische Applicatie Architectuur (TAA)

Dit document zal mede als input dienen voor de totstandkoming van een TAA. Dit hoofdstuk heeft als voorlopig doel om die aansluiting te illustreren en te bewaken. Verschillen met de TAA worden in dit hoofdstuk ook aangegeven, voor zover dit mogelijk is gezien het stadium van de organisatie architectuur. De aansluiting is een doel waar in volgende versies van dit document verder aan gewerkt zal worden.

Uitgangspunten en architectuurprincipes

De technische referentiearchitectuur is tot stand gekomen met de hier onder genoemde uitgangspunten en architectuurprincipes. Deze uitgangspunten en architectuurprincipes zijn daarmee de toetsstenen voor de technische referentiearchitectuur. Voor een deel kunnen de genoemde uitgangspunten tegenstrijdig zijn. Het vinden van een “ideale” technische referentiearchitectuur is het vinden van een optimale combinatie en toepassing van de genoemde uitgangspunten.

1.     Traag veranderende systeemdelen moeten losgekoppeld worden van snel veranderende systeemdelen. Snel veranderende systeemdelen mogen afhankelijk zijn van langzaam veranderende systeemdelen maar langzaam veranderende systeemdelen mogen niet afhankelijk zijn van snel veranderende systeemdelen.

Voorbeeld: (langzaam veranderende) domeinelementen mogen niet “vervuild” worden met (snel veranderende) GUI aspecten. De GUI elementen mogen eventueel wel bekend zijn met domeinelementen.

Voorbeeld: Het domein heeft een “houdbaarheid” van 10 tot 50 jaar. De Interfaces naar de Client of gebruiker hebben een houdbaarheid van 2 tot 5 jaar. De database (het DBMS, niet de data zelf) heeft een houdbaarheid van 5 tot 10 jaar.

2.     Systeemaspecten die altijd gezamenlijk zullen veranderen, moeten in één systeemdeel samengevoegd worden.

Voorbeeld: Proces en data van een systeem zullen altijd samen veranderen (als een procedure verandert gaat dat meestal gepaard met een veranderende databehoefte en andersom). Proces en data mogen dus niet in verschillende delen van het systeem ondergebracht worden.

3.     Het domein is leidend. Wezenlijke (complexe) veranderingen in een systeem zullen altijd voortkomen uit veranderende wensen vanuit de business. Dat betekent dat veranderende domeinaspecten van een systeem eenvoudig vertaald moeten kunnen worden naar veranderingen van andere systeemaspecten.

Voorbeeld: Een verandering in het domein moet eenvoudig vertaald kunnen worden in een verandering in de persistentie (database en bijbehorende systeemaspecten).

4.     De architectuur moet het mogelijk maken om kleine functionele eenheden snel te ontwikkelen (of toe te voegen) en direct de resultaten te kunnen testen. De implementatie van het domein moet tot stand kunnen komen zonder dat overige systeemfunctionaliteit aanwezig hoeft te zijn.

Voorbeeld: het domein moet zelfstandig getest kunnen worden zonder dat er daarvoor (user-) interfaces of persistentie geprogrammeerd hoeft te worden.

5.     Systeemaspecten die gedeeld worden met andere systemen worden generiek gemaakt (of gekocht) voor heel de organisatie. Systeemaspecten die gedeeld worden binnen een systeem worden generiek gemaakt voor alle onderdelen van dat systeem. Specifieke systeemdelen zijn afhankelijk van generieke systeemdelen, nooit andersom.

Voorbeeld: Het mag niet voorkomen dat een systeemaspect als het lezen van XML op een specifieke manier voor een project gemaakt wordt (en al helemaal niet dat het voor een ander project nogmaals gemaakt wordt). Een XML parser moet zodanig gemaakt zijn dat het geen systeemspecifieke delen bevat, systeemspecifieke delen mogen gebruik maken van een generieke XML parser.

6.     De architectuur moet schaalbaarheid ondersteunen, zowel in hardwarevorm als in softwarevorm.

Voorbeeld: De architectuur moet het mogelijk maken om systeemdelen te verdelen over processoren (nodes). Ook moeten systemen in staat zijn om in een geclusterde omgeving te werken.

7.     Aansluiting bij de OMG Model Driven Architecture (MDA).

Voorbeeld: De transitie van het UML domeinmodel naar een (Java) implementatie van het domeinmodel moet zo eenvoudig mogelijk zijn en zo veel mogelijk geautomatiseerd kunnen worden. Veranderingen aan de Java code van het domeinmodel moeten zo eenvoudig mogelijk doorgevoerd kunnen worden in het UML domeinmodel.

Technische randvoorwaarden

Nu volgt een voorbeeld van mogelijke technische randvoorwaarden binnen een organisatie.

De technische referentiearchitectuur is dan bijvoorbeeld ontwikkeld binnen de volgende technische randvoorwaarden:

Programmeertaal	Java
Modelleertaal	UML
Persistentie, transactiemanagement, sessiemanagement	J2EE
Implementatie domeinmodel	Java[8]
Communicatietaal tussen applicaties	XML
Communicatieprotocol tussen applicaties	HTTP 1.1
Communicatie tussen applicaties	Stateless
Database	Oracle X(i)
Applicatieserver	Websphere 4.X
Webserver	IBM Apache
Hardware	{Nog invullen}
Clustering	{Nog invullen}

Java packaging overzicht van de technische architectuur

De illustratie hieronder geeft de generieke packaging structuur weer van applicaties ontwikkeld onder architectuur. Dit model is een momentopname.

In het model valt goed te zien dat de domein package geïsoleerd is van de buitenwereld door de services, die op hun beurt gebruik maken van een aantal frameworks. Deze frameworks zijn vooral de componenten die bedoeld zijn om vervangen te worden door commerciële producten. De strategie is gebaseerd op ROI: valt reeds in een vroeg stadium te voorzien dat de kosten van implementatie van een commercieel product opwegen tegen die van een in-company ontwikkeld framework dan kan vanaf de start gebruik gemaakt worden van het ingekochte product. Meestal echter zijn de baten van een eigen ontwikkeling alleen al groot genoeg om te rechtvaardigen als we kijken naar wat de ervaring oplevert bij overgang van en aanschaf van een commercieel product. In principe is de vuistregel: begin met een simpel framework van eigen makelij, en overweeg aanschaf van een off-the-shelf product wanneer dit vanuit TCO te rechtvaardigen valt.

Uitwerking Domeinmodel

Bij het implementeren (uitprogrammeren) van het domeinmodel gelden de volgende regels:

1. Voor de implementatie van het domein wordt alleen gebruik gemaakt van standaard Java classes (J2SE) en (organisatie-) generieke support en utility classes.
2. Er worden geen J2EE constructies binnen het domein gebruikt (geen Servlets, Session- en Entity Beans). Dat wil niet zeggen dat het domein zélf geen J2EE construct kan zijn. Ook wordt open gehouden op welk niveau van aggregatie van subsystemen van het domein J2EE constructs als Entity of Session Beans wel acceptabel zijn.
3. Het hele domeinmodel (de hele business logica) moet geïmplementeerd worden in het domein. Er bevindt zich geen business logica buiten het domein. Dit impliceert dus dat alle business logica zich op één logische plaats bevindt. Logisch impliceert dat delen van het domein zich in verschillende fysieke stukken software bevinden (“Federated Domain Architecture”) en/of dat (delen van) het domein zich op meerdere plaatsen bevinden (replicatie, caching).
4. Het Service Architecture Framework (SAF) is het enige mechanisme om events vanuit het domein te laten propageren naar services buiten het domein. De enige connectie die de domein component naar de buitenwereld heeft is die van (generieke) events. Events worden gebruikt voor publish-and-subscribe functionaliteit. De implementatie van deze functionaliteit in het framework zal in de toekomst uitgebreid kunnen worden naar alternatieve mechanismen naast het Observer pattern.
5. Classes binnen het domein mogen geen kennis hebben van de aanwezige services.
6. Domeinclasses implementeren ChangingObservable uit SAF. Dit is de technische realisatie van de requirement dat er geen koppeling is. Er zijn meerdere technische realisatie van deze requirement mogelijk. Een voorbeeld is een Event Manager.

In het volgende diagram wordt een mogelijk domeinmodel getoond:

Het domein model wordt opgeleverd in twee hoofdversies:

1. analysemodel (zie 4.4.2 Kenmerken domein model)
2. designmodel

Het domeinmodel:

1. is programmeertaal-afhankelijk
2. bevat attributen
3. bevat onderscheid tussen private en protected velden (attributen en boodschappen)
4. bevat private velden (attributen en boodschappen)
5. bevat utility classes

Constructie Service Component

Voor het implementeren van de services in service componenten gelden de volgende regels:

1. De implementatie van het domein is niet bekend met de beschikbare services
2. Het domein gebruikt SAF (Service Architecture Framework) voor de communicatie met services. Het domein is dus bekend met SAF, niet met de services. Het gebruiken van SAF door de domein component vindt plaats door:
3. Domein classes zijn event sources – dit is momenteel geïmplementeerd doordat zij een subclass zijn van Observable. Andere implementaties zijn mogelijk (Event Registry)
4. Service componenten zijn event sinks (publish-and-subscribe is een implementatie van deze requirement)
5. Rechtstreekse koppeling tussen event sources en event sinks vindt zelden plaats. Regel is dat er één of meerdere adapters tussen zijn geplaatst.
6. De services zijn waar mogelijk uitgesplitst in:
7. Een generiek framework, te gebruiken door meerdere applicaties (domeinen)
8. Een specifieke toepassing van het betreffende framework (de service zelf)
9. De specifieke toepassing van de service kent het framework maar het framework mag niet bekend zijn met de specifieke toepassingen (want dan zou het niet meer generiek zijn)

Er zijn bijvoorbeeld al uitwerkingen van de volgende services en frameworks:

1. Persistentie (het opslaan en muteren van gegevens in een database)
2. Logging
3. Autorisatie en Authenticatie (met AAS als framework)

In het volgende diagram worden de relaties tussen het domein, SAF en een service component getoond:

Het Service Architecture Framework (SAF) is gebaseerd op een aantal design patterns, met name het Observer pattern en het Adapter pattern (zie [Gamma et al., 1995]).

Uitleg SAF

Het SAF Framework is een set van classes die de requirement van losse koppeling tussen domein objecten en de buitenwereld implementeert.

Binnen het framework is de event koppeling momenteel (januari ’03) beschikbaar als een Observable-Observer rol, gecombineerd met het Adapter pattern. Andere technologieën zijn beschikbaar om dezelfde functionaliteit te implementeren en zullen in latere versies van het framework toegevoegd worden.

Een requirement van de Adapter classes is dat zij een generieke Value interface implementeren. IValue is de interface voor alle adapters, waardoor alle adapters de boodschappen getValue() en setValue(…) begrijpen. Omdat deze adapters a.h.w. de lijm vormen tussen de verschillende lagen of componenten, wordt de koppeling tussen deze componenten eenvoudiger: de interface is altijd een Value interface.

In Figuur 15. Adapter pattern in SAF is te zien dat een domein class (Domainclass2) als subclass van Observable in staat is om events af te vuren naar observers. Deze observers zullen altijd adapters zijn.

Het updaten van observers, of het op de hoogte brengen van de service componenten, gebeurd doordat er iets gebeurd met een domein object. Als gevolg van die gebeurtenis stuurt een domein object changed() naar zichzelf. Dat is in het framework geïmplementeerd door een event af te vuren naar alle objecten die zich hebben geabonneerd op veranderingen. Dat zullen altijd adapters zijn, die ervoor zorgen dat de verandering doorgegeven wordt naar de service componenten die van belang zijn.

Een voorbeeld is opslaan in een database. Een domein object veranderd, een persistency service adapter krijgt de update, vraagt vervolgens aan het domein object wat veranderd is, en geeft dit door aan de database. Dat laatste zal veelal via een reeks van adapters gaan om database onafhankelijkheid te vergroten. Uiteindelijk zal het resulteren in het opzetten van een database transactie.

Adapters

Adapters vormen de universele lijm waarmee componenten aan elkaar gekoppeld worden. De communicatie tussen de adapters kan op allerlei manieren plaatsvinden:

• Rechtstreekse method call
• Via messaging queues (bijv. via MQSeries)
• RMI of andere remote calls

Van belang is dat in het bijzonder de koppeling van de domein component met de service componenten plaatsvindt via adapters:

Een adapter ontvangt events van de domein component. Dit zijn genaamde events (voorbeeld: changed(“name”) – hiermee wordt aangegeven dat een domein object is veranderd in zijn name aspect. Het kan zijn dat er meerdere adapters aan elkaar gekoppeld zijn om het doel van losse koppeling beter te bereiken.

Een service component gelijkt in zoverre op een adapter dat het dezelfde event interface heeft (en dus in staat is zich te subscriben op events van andere componenten). De koppeling van componenten wordt sterk vereenvoudigd doordat elke adapter dezelfde interface (IValue) heeft.

Adapters bevatten in principe minimale functionaliteit (ze implementeren slechts de IValue interface, en zijn te parametriseren met get en set methodes). Het is echter niet noodzakelijk die functionaliteit daartoe beperkt te houden. Extra activiteiten zouden ook toegevoegd kunnen worden aan de uitvoering van de get en set methoden (pre– en postprocessing, autorisatie enz.).

Een rol die adapters ook spelen is het isoleren van vendorspecifieke extensies. Het is bijvoorbeeld niet aan te raden om gebruik te maken van stored procedures in de database. Mochten er echter argumenten zijn om dit wel te doen op bepaalde nauwkeurig afgebakende gebieden, dan kan dat door gebruik te maken van speciale adapters die het gebruik van deze extensies afschermen voor de andere componenten. De adapter functioneert dan als een zgn. wrapper om de database connectie heen die stored procedures aanroept.

Hierdoor kan de richtlijn voor het gebruik van vendorspecifieke extensies worden geformuleerd als: in principe wordt geen gebruik gemaakt van vendorspecifieke extensies; bijvoorbeeld om redenen van performance kan hiervan afgeweken worden mits het gebruik van deze extensies geïsoleerd wordt door adapters. De architect moet hiervoor zijn toestemming hebben gegeven.

Beveiliging

Dit hoofdstuk bevat de richtlijnen voor de technische realisatie van beveiligingseigenschappen van applicaties.

Dit hoofdstuk is momenteel (februari ’03) nog rudimentair.

SMI

De Security Middleware Interface SMI is ontwikkeld als standaard voor de wijze waarop applicaties aankoppelen aan autorisatie en authenticatie componenten. Deze interface heeft vooral tot doel deze loskoppeling op een beheerste en eenvoudige wijze te realiseren die onafhankelijk is van de gebruikte componenten (zelf ontwikkeld of aangekocht).

SMI biedt:

• Authenticatie
• Functie autorisatie
• Gegevens autorisatie
• Logging

Het gebruik van SMI zal leiden tot hergebruik van ontwerp, uniformiteit in werkwijze en leverancieronafhankelijkheid.

AAS (Autorisatie en Authenticatie Server)

De AAS en applicaties die draaien op één of meerdere applicatieservers vormen een groep binnen de firewalls die met elkaar samen werken. De AAS is een technische service component die middels adapters gekoppeld is aan de applicaties, met name de domein component daarbinnen. De ingang via SMI loopt door de in het domein aanwezige paspoorten die op elk moment autorisaties kunnen controleren.

Producten

J2EE

J2EE is een standaard op het gebied van enterprise systemen. Het biedt een platform aan waarmee voldaan kan worden aan verschillende niet-functionele eisen, o.a. schaalbaarheid.

Voor J2EE zijn er de volgende argumenten:

• Stabiliteit en schaalbaarheid van het platform
• Er zijn meerdere leveranciers van produkten die J2EE ondersteunen
• Acceptatie snelheid van J2EE in de markt
• Grote vrijheid in keuze van operating systemen en hardware

Het gebruik van J2EE is aan de volgende beperkingen onderworpen:

• Het onderscheid tussen entity beans en session beans wordt niet gebruikt om data en functies te scheiden.
• Entity beans zijn J2EE constructies om de persistency service te implementeren binnen het MDA framework. Niet meer dan dat.

XML, SOAP

Koppeling van de verschillende componenten dient op een zodanige wijze te gebeuren dat de afhankelijkheid zo klein mogelijk is. Hoge cohesie en lage koppeling kenmerken succesvolle gedistribueerde systemen.

XML is een standaard die zich uitermate goed leent voor het implementeren van de “messaging” metafoor die los gekoppelde systemen kenmerkt.

• Alle componenten die gedistribueerd aangesproken dienen te worden, doen dit middels een XML interface. Dat houdt in dat de component in staat is berichten te ontvangen (wat evident is), maar daarnaast dat het formaat van die berichten XML is.
• Gedistribueerd aanspreekbare componenten dienen voorzien te zijn van een XML service component die het formaat van de boodschap interface abstraheert van het component. Dit zal gebeuren in de vorm van een façade pattern.
• Het formaat van de XML berichten is niet vrij maar aan standaarden onderworpen. Het beheer van deze standaarden in de vorm van een berichtenboek, naast richtlijnen voor de structuur van nog te definiëren berichten (geen functionele berichten bijvoorbeeld, berichten moeten geen of zo weinig mogelijk assumpties bevatten over de implementatie van de componenten waar ze naar gestuurd worden), moeten nog geregeld worden.

Momenteel (januari ’03) is deze interface puur op XML gebaseerd. Omdat SOAP een open standaard biedt voor het implementeren van de XML façade (in feite een remote function call mogelijk maakt) zal dit in de nabije toekomst een beter alternatief bieden voor het XML berichtenboek.

Java

Java is een programmeertaal.

In principe is de programmeertaal waar de verschillende componenten in geschreven zijn Java. Het is niet de bedoeling hier een in beton gegoten wet van te maken. Meer en meer zal applicatieontwikkeling plaatsvinden met codegeneratie tools. Java komt met nieuwe versies. Nieuwe programmeertalen zullen zich aanbieden. Door modelgedreven te werken realiseren wij maximale onafhankelijkheid van programmeertalen.

• Op basis van onderbouwde argumenten zal het gebruik van andere programmeertalen toegestaan kunnen worden door de architect.
• De gemaakte analysemodellen in UML zijn volledig onafhankelijk van programmeertalen.
• Design modellen dienen als zodanig herkenbaar te zijn – deze zullen programmeertaal en class library afhankelijke notaties bevatten (en ook moeten bevatten). Bijvoorbeeld types van attributen zullen aangegeven worden in de vorm van standaard Java classes als String.

Oracle

Een standaard voor data opslag zou bijvoorbeeld Oracle kunnen zijn als relationeel DBMS. Dit is een relationele database. Andere technieken als objectgeoriënteerde databases zijn moeten op basis van specifieke eisen gerechtvaardigd worden.

Het gebruik van een relationele database is binnen de modelgedreven ontwikkelmethode aan strengere beperkingen onderworpen dan gebruikelijk. Let wel: onderstaande restricties gelden voor de nieuwe architectuur. Het gebruik van stored procedures bijvoorbeeld voor de aansturing van legacy applicaties kan wel toegestaan worden onder bepaalde voorwaarden.

• Het gebruik van stored procedures is niet toegestaan. Alle functionaliteit voorzover te maken met business logica dient in de business component geplaatst te worden.
• Het gebruik van triggers is beperkt toegestaan. Omdat alle wijzigingen van velden in de database plaatsvindt als gevolg van wijzigingen in het domein (database is volgend) worden events in het domein gegenereerd. Er zullen echter ook andere applicaties gebruik kunnen maken van dezelfde databases die wel een vorm van notificatie nodig hebben. Voor deze applicaties kunnen triggers gebruikt worden, mits geïsoleerd in speciale adapters.
• Het database schema kan maximaal geoptimaliseerd worden onafhankelijk van de structuur van het objectenmodel. Hiervoor is een mapping nodig tussen het datamodel en het OO model. Voor deze mapping is een OO domeinmodel zeer geschikt, naast een framework dat de functionaliteit van deze mapping moet realiseren.
• De mapping tussen OO en relationele wereld wordt momenteel (januari ’03) gerealiseerd middels een eenvoudige OR mapping in het persistency framework. Dit framework kan vervangen worden door commercieel verkrijgbare tools. Het framework is in dit document niet uitgewerkt.

WebSphere

Een standaard voor applicatieservers zou kunnen zijn WebSphere van IBM.

Voor de toepassing van deze applicatieserver zijn de volgende regels van belang:

• Vendorspecifieke extensies voor de koppeling met databases en OR mappings zijn niet toegestaan. Omdat dit met een apart framework en in de nabije toekomst met commerciële tools zal moeten gebeuren is dit een harde regel.
• Vendorspecifieke extensies op J2EE zijn niet toegestaan. Alleen die onderdelen die in de J2EE standaard (afhankelijk van de versie van J2EE die in gebruik is) zijn gespecificeerd zijn toelaatbaar.

8. Deployment

Inleiding

De infrastructuur architectuur bestaat uit de verschillende computer systemen en de netwerk verbindingen. In dit hoofdstuk wordt een globaal overzicht gegeven van de technische architectuur. Het doel van het hoofdstuk is niet zozeer de infrastructuur architectuur zélf te beschrijven, maar vooral de interface van de applicatiearchitectuur.

Infrastructurele aspecten referentiearchitectuur

Uitgangspunten

De beheerbaarheid is het belangrijkste uitgangspunt voor de technische infrastructuur. Dit is vooral van belang omdat voor een goede beschikbaarheid van de applicatie niet alleen de onderliggende infrastructuur goed moet zijn, maar met name ook de inrichting van het beheer van de systemen. Verdere uitgangspunten voor technische infrastructuur zijn onder andere kostenbeheersing en schaalbaarheid.

Realisatie

Om aan de gestelde eisen te kunnen voldoen gelden een aantal zaken, die ook voor bijv. een applicatie gelden, zoals standaardisatie, het gebruik van beheertools e.d. Daarom wordt nu ingegaan op de onderliggende techniek, omdat die specifiek geldt voor dit onderdeel van een architectuur.

De beschikbaarheid kan in de eerste plaats worden verkregen door goede hardware en bijbehorende (systeem) software te gebruiken van een bekende leverancier. Omdat hardware niet onfeilbaar is, wordt alles dubbel uitgevoerd, zodat bij uitval van een component, de functionaliteit niet verloren gaat.

Voor een extra hoge beschikbaarheid is het mogelijk om de dubbel uitgevoerde systemen over meerdere locaties te verdelen, zodat bij een ernstige calamiteit op een locatie, de dienstverlening kan worden voortgezet.

Software

Ook de gebruikte software moet volledig zijn ingericht op het concept van een dubbel uitgevoerd rekencentrum. De systeemsoftware is, bij een juiste keuze, goed geschikt. De applicatiesoftware dient rekening te houden met dubbele uitvoering van de hardware. Zo moet bijvoorbeeld in het geval van WebSphere “clusters” hiermee bij het bouwen rekening worden gehouden. In een testomgeving is het wenselijk deze werking op een dubbel uitgevoerd systeem te kunnen controleren.

Netwerktoegang

De netwerktoegang dient onafhankelijk van de gebruikte systemen te zijn, waarbij de gebruiker automatisch naar een bepaalde applicatie wordt doorverwezen op basis van een netwerknaam. Bij uitval van een component dient de verwijzing automatisch te worden bijgesteld.

Verder is van belang dat ook hier het functioneren van het netwerk niet afhankelijk mag zijn van de goede werking van slechts een component. Bij het verder optimaliseren van het dubbele rekencentrum dient dit goed te worden geregeld.

Testomgeving

Voor een werkelijk professionele organisatie is het noodzakelijk een testomgeving te hebben, die min of meer een kopie is van de productieomgeving. Hierin kunnen de consequenties van invoering van nieuwe of gewijzigde componenten worden onderzocht. Tevens kan het rekencentrum (of een centrale testvoorziening) hier een acceptatietest met deze componenten uitvoeren. Op deze manier kunnen verstoringen in de productieomgeving door onderlinge beïnvloeding van componenten zoveel mogelijk worden uitgesloten.

Hier kan bijvoorbeeld een testfabriek voor worden ingericht, die hiervoor geschikt gemaakt kan worden.

Wel is het uiteraard noodzakelijk om over voorzieningen te beschikken ten behoeve van de ontwikkeling van software, die binnen de afdeling applicaties aanwezig moeten zijn.

Standaarden

Men zou bijvoorbeeld kunnen komen tot een volgende inventarisatie van huidige standaarden:

Hardware database servers	HP Alpha
Operating systeem van de database servers	HP tru64 Unix
Database manager (RDBMS)	Oracle 9i met RAC
Applicatielaag	Sun
Operating systeem applicatielaag	Sun Solaris
Applicatie server	WebSphere, met clustering door WebSphere
Beheer software	BMC patrol
Back-up software	Legato

Verantwoordelijkheden.

De verantwoordelijkheden en het escalatiepad dienen nader te worden bepaald. Voor een goede werking van de applicaties is de aanschaf van een hoeveelheid hardware niet voldoende. De wijze waarop het beheer wordt ingericht en hoe de dagelijkse gang van zaken is bepalen in hoge mate de beschikbaarheid van de informatiesystemen.

9. Bouwen met de architectuur

Naast het neerzetten van een architectuurplatform is het van groot belang zorg te dragen dat deze architectuur ook goed in de organisatie landt. Het neerzetten van een architectuur is één maar het bouwen onder architectuur is iets anders. Een referentie architectuur zal gebruikt worden voor de realisatie van een breed scala aan toepassingen. Daartoe zal de wijze waarop de bouw plaats vindt gestructureerd moeten worden. Dit uit zich in gebruikte methodieken en ontwikkelprocessen, al dan niet ondersteund met gereedschappen (tools).

Complexiteitsreductie, versnelde systeemontwikkeling, nieuwe technologieën / technieken en toekomstgerichtheid zijn waarschijnlijk de belangrijkste drijfveren om te gaan bouwen onder architectuur. Hier zal waarschijnlijk iedereen zich in kunnen vinden. Maar belangrijk is dat iedereen zijn rol en bijbehorende verantwoordelijkheden kent.

Het gaan werken onder architectuur heeft in meer of mindere mate consequenties op alle OPAFIT[9] aspecten. Zo zullen medewerkers nieuwe technieken moeten aanleren. Er zullen nieuwe rollen moeten komen omdat bepaalde verantwoordelijkheden niet meer te beleggen zijn. Bestaande werkprocessen, zoals change-management zullen mogelijk moeten worden aangepast. Dit zijn slechts voorbeelden en is zeker geen volledige opsomming. Het geeft wel aan dat er het nodige bij komt kijken voordat onder architectuur gebouwd kan gaan worden.

Het introduceren van een architectuur zal voor een groot aantal personen binnen de organisatie consequenties hebben. Sommigen zullen dit zien als een professionalisering waar ze aan toe waren. Anderen zien het misschien nog als een bedreiging. Feit is dat iedereen, van management tot ontwikkelaar zijn bijdrage zal moeten leveren om de architectuur tot een succes te maken. Het management zal de voorwaarden moeten scheppen en de middelen ter beschikking moeten stellen. Medewerkers zullen naast het leren van nieuwe technieken ook andere werkwijzen moeten adopteren. Front Office of Account Management zal op een andere wijze de opdrachtgever en klant bij het proces gaan betrekken. De architectuur zal anders nooit het beoogde resultaat kunnen waarmaken.

In dit document zal niet verder worden ingegaan op het laten landen van de architectuur binnen de organisatie. Het kan zijn dat er inmiddels al wel de nodige inspanning is geleverd om een breed draagvlak te krijgen voor de architectuur. Maar uit bovenstaande pleidooi mag worden bepaald of hier nog extra energie in moet worden gestoken.

Methodieken

Een ontwikkelmethode bestaat uit een aantal componenten die hieronder in een UML diagram worden weergegeven.

Zoals in de figuur is te zien, bestaat een methode naast een modelleertaal (UML), ook uit een metamodel, enz. Dit document beperkt zich tot de modelleertaal en tools & techniques.

Projectmanagement

Veel organisaties gebruiken Prince2 als projectmanagement methode. Bij de toepassing van Prince2 is het van belang deze te combineren met een proces. In de praktijk komt Prince2 vaak voor naast IAD, JAD, DSDM en UP.

De toepassing van Prince2 wordt hier verder niet uitgewerkt.

Tasks repository

Bij het ontwikkelproces wordt geput uit een reeks van technieken. Dit hoofdstuk bevat een opsomming van de mogelijke technieken. In de verschillende disciplines van UP is het van belang te overwegen welke van de technieken toegepast moeten worden om binnen tijd en budget tot een acceptabele deliverable te komen.

Ook worden de taken gebruikt voor het bijhouden van ontwikkelmetrieken die nodig zijn om het schatten, plannen en voortgang bewaken in de loop van de tijd steeds beter te laten verlopen.

Voor een lijst van taken, zie appendix 1.2 (Lijst van taken).

Ontwikkelproces

Voor de inrichting van het proces dat gepaard aan de architectuur het werken onder architectuur tot een succes maakt is het belangrijk ons te realiseren dat een proces altijd een op maat gemaakt proces is voor een bepaalde organisatie, voor bepaalde toepassingen, voor een bepaalde markt[10]. Het is niet mogelijk een proces uit een boek te adopteren, in tegenstelling tot bijvoorbeeld een modelleertaal. Ook RUP is geen proces – Jacobson waarschuwt zelf regelmatig voor het rücksichtslos toepassen van RUP. RUP is een framework of een metamodel van een proces, waaruit de organisaties die ermee willen werken zelf een instantiatie moeten destilleren.

Projecten die uitgevoerd worden met de aanpak zoals hieronder beschreven hoeven niet moeilijker zijn te plannen dan traditionele watervalmethode projecten. We moeten ons daarnaast realiseren dat de volgende constateringen gedaan moeten worden op basis van de marktervaringen[11]:

• Ook projecten gedaan volgens de watervalmethode kennen een groot (>50%) percentage falen (in tijd en/of budget), met een te groot aantal forse problemen (>20% gefaald).
• Projecten met modernere methodes zijn nauwelijks beter beheersbaar dan de waterval projecten.
• Projecten met J2EE en/of .NET hebben momenteel (december ’02) een gemiddeld mislukkingpercentage van 70% [49 – Feiman 2002 Leading Languages fo…].

Bovenstaande constateringen dienen aangevuld te worden met ervaringscijfers op basis van de kenmerken van de projecten in beide categorieën. Wat zijn de factoren die hebben bijgedragen aan het succes of falen? Uit de literatuur kunnen de volgende zaken worden gevonden:

1. hoe groter een project, hoe groter de kans tot falen. Omdat dit exponentieel toeneemt, is het afgezien van de methode van belang te komen tot zo klein mogelijke projecten. Het streven moet zijn om in nauw overleg met de klant te komen tot projecten van enkele weken tot maanden. Binnen deze periode is er sprake van een volledig traject dat een stuk business ondersteuning m.b.v. IT ter beschikking stelt van de gebruiker.
2. omdat kleinere projecten succesvoller zijn, is het te adviseren om gebruik te maken van technieken uit die methodes die incrementeel werken ondersteunen.

Op basis van de hierboven genoemde overwegingen kan er voor gekozen worden om gebruik te maken van het Unified Process (de OMG definitie ervan). Dit is dus een proces, dat volgens de definitie in Figuur 21 een onderdeel uitmaakt van een methode. Binnen het UP is er ruimte om het proces in te vullen vanaf min of meer watervalmethode tot agile. De voorkeur voor projecten is om aan de agile kant van het spectrum te opereren. Dit is echter ook afhankelijk van de aard van het project:

• toenemende complexiteit van het domein → toenemende agiliteit
• toenemende onduidelijkheid van requirements → toenemende agiliteit

Projecten die binnen een overzichtelijke probleemstelling opereren kunnen dus met een aanpak die meer aan de watervalkant van het UP spectrum zit uitgevoerd worden. De architectuur legt hier geen dwingende randvoorwaarden aan.

Dit op maat maken van een proces vereist dat binnen één of meerdere projecten ervaring is opgedaan met het bouwen van systemen volgens een bepaalde aanpak. Deze ervaringen kunnen vervolgens worden gebruikt om de metrieken die bijvoorbeeld planning en voortgangsbewaking ondersteunen, te fine-tunen.

Hiervoor is het belangrijk vanaf het begin te meten hoelang de taken die men onderneemt duren. Gebruik hiervoor de repository van taken[12] en geef bij elke taak die uitgevoerd wordt aan hoeveel tijd is gespendeerd aan welke resultaten (deliverables) van die taak.

De verzamelde metrieken kunnen gebruikt worden om na een periode van enkele maanden tot een jaar een begin te maken met het vertalen van deze metrieken. Het eerste werk dat mogelijke metrieken grondig in kaart heeft gebracht is [Champeaux, 1997]. Deze kunnen dan gebruikt worden in de planning en voortgangsbewaking. In hoofdstuk 7.1.3.1 Planning en voortgangsbewaking wordt hier dieper op ingegaan.

UP is een proces dat de volgende hoofdkenmerken heeft:

• Use-case driven
• Architecture centric
• Iteratief – incrementeel
• Component based

Onderstaande illustratie geeft de basisstructuur weer waarbij enkele disciplines (vroeger workflows genoemd) zijn getekend. Een project zal uit meerdere disciplines bestaan die (en hier zit een belangrijk verschil met de watervalmethode!) parallel worden uitgevoerd binnen elke iteratie.

De fasen die binnen UP wél bestaan zijn geënt op het incrementele ontwikkelproces, en beschrijven de stadia die een projectteam doorloopt tot in productie nemen bij de gebruiker: inceptie, elaboratie, constructie en transitie. Deze macrocyclus kan zich daarenboven nog meerdere malen herhalen. Elke iteratie levert één of meer artefacten op. Het streven is om, ook in de beginfase van een project, iteraties van maximaal enkele weken te definiëren, waarbij ook die eerste iteraties een draaiend systeem opleveren. Iteraties van enkele maanden zijn te lang.

Planning en voortgangsbewaking

Planning van moderne UP projecten is niet moeilijker dan die van traditionele projecten. Integendeel: bij een integrale aanpak waarbij allerlei zaken als offertetraject, projectmanagement, teamsamenstelling, en klantbetrokkenheid worden meegenomen, zou de planning juist eenvoudiger moeten worden. Er zijn allerlei metrieken waaruit men zou kunnen concluderen dat projecten uitgevoerd met de watervalmethode juist moeilijker beheersbaar zijn dan UP projecten.

Voor deze vereenvoudiging (we willen immers goedkoper en sneller dan vroeger …!) is het wel nodig software ontwikkeling niet geïsoleerd te beschouwen. Alleen een geïntegreerde aanpak zal vruchten afwerpen. De gehele organisatie zal meegenomen moeten worden.

Voor de planning is het nodig in veel kortere incrementen te gaan werken dan in traditionele methodes gangbaar was. Hierdoor zullen zaken als risicomanagement anders ingevuld moeten worden. Bij wekelijkse of tweewekelijkse releases van functionaliteit voor de eindgebruiker, waarbij telkens weer opnieuw bekeken wordt of en hoe verder gegaan wordt, is er sprake van een andere relatie tussen dienstenleverancier en –afnemer. Er is veel meer sprake van een structurele relatie in plaats van een incidentele.

Voor de planning en voortgangsbewaking van projecten die naar de beweeglijke kant van het spectrum bewegen zijn traditionele planningstechnieken niet meer geschikt. Op basis van use cases en domein modellen schattingen opstellen is veel effectiever gebleken[13]. Omdat daarnaast deze schattingen voortdurend bijgesteld worden en teruggekoppeld met de opdrachtgever kan er sprake zijn van een beheerst project ook al weet men aan het begin van het project niet waar men over 2 jaar zal zijn.

Tools

Dit hoofdstuk bevat een inventarisatie van tools die gebruikt mogen worden bij de ontwikkeling onder architectuur. Dit zou er zo uit kunnen zien:

Modellering	Visio
Rose
XDE
Software ontwikkeling	VisualAge
WebSphere Studio
Testen	UnitTest
JUnit

10. Model Gedreven Architectuur

We geven hier een globaal overzicht van de aanpak van Model Gedreven Architectuur (MDA) voor ontwikkeling van applicaties. We gaan niet diep in op de methodische aspecten van MDA. Uitgebreide informatie over MDA is te vinden op de website van de Object Management Group [OMG, 2003] en de artikelen [Soley, OMG Staff Strategy Group, 2002], [DSouza, 2002]. In [Harmon, 2002] is een uitgebreid overzicht te vinden van de leveranciers die MDA hulpmiddelen leveren of aangekondigd hebben dit te gaan doen.

Achtergrond

De term “Model Driven Architecture” is voortgekomen uit ontwikkelingen binnen de Object Management Group (OMG). Meer informatie over OMG is te vinden op http://www.omg.org. In het algemeen behelst de aanpak het ontwikkelen van software op basis van verschillende modellen, waarbij het produceren van code niet meer op de eerste plaats staat. In plaats daarvan zijn modellen de primaire deliverables. Code komt tot stand door middel van code generatie. MDA is een open standaard voor alle lagen van de architectuur (in tegenstelling tot andere standaarden; bijvoorbeeld het TOGAF standaard beschrijft vooral de infrastructuur architectuur) die breed gedragen wordt in de industrie en waarvoor steeds meer hulpmiddelen op de markt komen(zie hiervoor ook [Harmon, 2002]).

De inspanningen rond het tot stand komen van MDA weerspiegelen het algemene gevoel dat de ontwikkeling van het vakgebied van software engineering een kritisch niveau van rijpheid heeft bereikt waardoor ambities realiseerbaar worden die in het verleden vaak vastliepen op de beperkingen van de stand van de techniek. Er wordt gesproken over een aantal “enablers” waaronder UML die een nieuwe situatie creëren.

Methodiek

Model Driven Architecture (MDA) is een formele methode voor het ontwerpen en realiseren van software systemen waarbij onderscheid gemaakt wordt tussen de business logica en de technologie waarin het gerealiseerd wordt.

Modellering en transformaties tussen modellen staan centraal. De modellering vindt plaats middels een platformonafhankelijke taal, de Unified Modelling Language (UML). Het is een formeel model, waarmee ook het gedrag gemodelleerd is. UML zal daartoe worden uitgebreid met zogenoemde. “Execution semantics” die voor OMG leden is in te zien op [OMG, 2001]

De aanpak is leverancieronafhankelijk en biedt de mogelijkheid om middels modelleringstandaarden zoals Unified Modelling Language (UML), Meta-Object Facility (MOF) en Common Warehouse Meta-Model (CWM) modellen uit te wisselen op verschillende platformen. In dit document zal niet ingegaan worden op UML, MOF, of CWM.

De huidige status van de modeltransformatie is dat veel nog handmatig wordt omgezet (lees “geprogrammeerd door de programmeur”). Ook zijn er nog niet voor alle technologieën platform specifieke modellen beschikbaar. Binnen de OMG wordt daar aan gewerkt. Dit leidt tot een steeds betere ondersteuning door hulpmiddelen die op de markt verkrijgbaar zijn.

Er zijn twee soorten modellen:

1. Een platform onafhankelijk model, ook wel PIM genoemd (Platform Independent Model), waarin technologieonafhankelijke functionaliteit gespecificeerd wordt.
2. Een platform afhankelijk model, ook wel PSM genoemd (Platform Specific Model), waarin de technologie afhankelijkheden gemodelleerd worden. Voor elk platform zal er een model zijn waarin het gedrag van het platform staat gespecificeerd.

Een belangrijke eigenschap van deze aanpak is dat het platformonafhankelijke model (de PIM) niet gevoelig is voor de technologische veranderingen en zijn waarde voor de langere termijn behoudt. De PIM is dus te allen tijde leidend voor de realisatie, ongeacht de technologische veranderingen. Een CORBA PIM had en overgang naar J2EE en/of .NET pijnloos moeten kunnen verdragen, om een voorbeeld te noemen. De nieuwste hype is geen bedreiging meer.

Business Model

De business functionaliteit wordt uitgedrukt in een Platform Independent Model, ook wel het Business Model genoemd, en is dus onafhankelijk van de technologie waarin het gerealiseerd wordt (zoals CORBA, Java, .NET, XMI / XML, of J2EE). Het zal duidelijk zijn dat de voordelen van de PIM ook voor het Business Model gelden. In sectie ??? wordt dieper ingegaan op het belang van de modellering van de business.

Services

Bij de modellering van de business functionaliteit wordt al gauw duidelijk dat een aantal soorten functionaliteit niet businessspecifiek is, maar wel noodzakelijk. Voorbeelden zijn beveiliging (zoals authenticatie en autorisatie), logging, communicatie en presentatie (GUI). Binnen MDA wordt dan gesproken over Services die alom tegenwoordig zijn (ook wel “Pervasive Services”) en niet zichtbaar zijn in het Business Model. Er is dus geen afhankelijkheid tussen het Business Model en de realisatie van dergelijke “Pervasive Services”.

Figuur 23 MDA poogt hier een uitdrukking aan te geven. De uitgaande pijlen geven de verticale marktsegmenten weer waarvoor het framework toepassingen mogelijk maakt. Dit geeft weer dat essentiële enablers als UML, MOF en CWM (Unified Modeling Language, Meta Object Facility en Common Warehouse Model) gebruikt worden in verschillende platforms als .NET en J2EE om service georiënteerde architecturen (SOA) te realiseren voor verschillende verticale marktsegmenten.

Merk op dat hoewel de “Pervasive Services” soms als een spaak in een wagenwiel getekend zijn, er geen specifieke interface zichtbaar is in het business model voor die services. Om de volledige onafhankelijkheid van de business component te garanderen is dit ook niet toegestaan. Het komt veeleer tot uitdrukking in het veronderstelde gedrag van de objecten in het Business Model.

Model transformaties

MDA vereist dat de modellen op een formele wijze in elkaar omgezet worden: er vinden formele transformaties plaats tussen de modellen. Geen “informele” vertalingen dus van het ene model naar het andere. De formele transformatie wordt ook weer uitgedrukt in formele transformatieregels.

Omdat de (Platform Independent) Business Model uiteindelijk getransformeerd moet worden naar een Platform Specific Model (PSM), wordt van de Pervasive Services ook een PIM gemaakt. Middels formele transformaties worden er koppelingen gemaakt tussen (de PIM van) het Business Model en (de PIM van) de Pervasive Services. De resulterende PIM dient dan als uitgangspunt voor de transformatie naar (de PSM van) de technologie platformen.

Voorbeeld

De transformatie heeft tot doel om wijzigingen van attributen van domein classes algemeen bekend te maken zodat eventuele services op de wijziging kunnen reageren. Services zullen zich moeten “abonneren” op wijzigingen die in het domein optreden. Dit mechanisme wordt “publish-and-subscribe” genoemd. Ter illustratie wordt een domein class gepresenteerd, met een klein stukje code, zoals die er uitziet voor en na de transformatie.

Het onderstaande figuur presenteert twee modellen:

1. het domein model dat het business model bevat,
2. het service model van een bepaalde service (hier is niets specifieks verondersteld).

De twee modellen zijn alleen aan elkaar gerelateerd met betrekking tot de kennis die de service heeft van de domeinclasses (aangegeven met de pijl met stippellijn, in UML een dependency). Er is nog geen sprake van een specifieke koppeling tussen de twee modellen.

De transformatie maakt gebruik van een eigen model, genaamd “Adapters”. Het modelleert het vereiste gedrag van het aangeven van wijzigingen van domein attributen en het kunnen reageren op deze wijzigingen door de service. Na de transformatie zijn er dus drie modellen. Het onderstaande figuur geeft de afhankelijkheden aan tussen deze drie modellen.

Als illustratie wordt de domein class Persoonsnaam gebruikt. De class heeft een attribuut achternaam en een methode om aan dit attribuut een waarde toe te kennen: setAchternaam.

De transformatie zorgt er voor dat de domein classes het gedrag kunnen gaan vertonen dat vereist is, namelijk het bekend maken van wijzigingen. De domein classes worden daartoe afgeleid van de class ChangingObservable (van het Adapters model). De code van de methode setAchternaam wordt aangepast: de aanroep van setChanged draagt zorg voor het notificeren van wijzingen in de achternaam van de class Persoonsnaam.

11. Index

AAS                                                     25, 33

accessors                                                   19

Adapter pattern                                         33

analysemodel                                            19

anti-pattern                                                25

applicatie                                                  23

Applicaties                                                23

aspect adapters                                         21

authenticatie                                             24

Autorisatie                                                 23

Business Model                                       50

change-management                                44

CORBA                                                      50

CWM                                                         50

demand-chain                                           18

designmodel                                             32

disciplines                                                 47

Enterprise Architectuur                                3

Event Manager                                          32

event sink                                                  32

façade adapters                                        21

Federated Domain Architecture                31

formele transformaties                             50

fractale architectuur                                   22

Functie autorisatie                                    37

functieautorisatie                                     25

Gegevens autorisatie                                 37

gegevensautorisatie                                25

handhaving                                               25

ISMI                                                          16

Meta Group                                                 3

Model Driven Architecture Zie Model Gedreven Architectuur

Model Gedreven Architectuur 4, 6, 7, 8, 9, 16, 30, 49, 58

MOF                                                          50

objectgeoriënteerde databases Zie OO databases

Observer                                                    31

OO databases                                            14

OPAFIT                                                     44

O-R mapping                                             14

Pervasive Services                                    50

PIM            Zie Platform Independent Model

Platform Independent Model                    49

Platform Specific Model                           49

POJO                                                        30

PSM                 Zie Platform Specific Model

publish-and-subscribe                               31

Technische Applicatie Architectuur ISC   28

Unified Process                                         46

Use Cases                                                  23

workflows                                                  47

12. Literatuurlijst

Gerelateerde documenten

Deze lijst bevat de bibliografische gegevens van de referenties in de tekst. De verwijzingen in de tekst zijn op naam, jaartal. Bij meerdere publicaties van dezelfde auteur in één jaar wordt een letter toegevoegd (bijv. [VENS, 2002a]).

1. [BELLIN ET AL., 1997] Bellin, David, Simone; Susan Suchman, , and Susan Suchman, , The CRC Card Book (Addison-Wesley, Reading, MA, 1997).
2. [CARBONE, SANTUCCI, 2002] Carbone, Massimo, and Santucci, Giuseppe, Fast&Serious: a UML based metric for effort estimation (Universita’ degli studi di Roma “La Sapienza”, Rome, 2002).
3. [CHAMPEAUX, 1997] Champeaux, Dennis de, Object-Oriented Development; Process and Metrics (Prentice-Hall, New York, 1997).
4. [DSOUZA, 2002] DSouza, Desmond, Model-Driven Architecture and Integration – Opportunities and Challenges ftp://ftp.omg.org/pub/docs/ab/01-03-02.pdf, 2002).
5. [FOWLER ET AL., 2002] Fowler, Martin, Rice, David, Foemmel, Matthew, Hieatt, Edward, Mee, Robert, and Stafford, Randy, Patterns of Enterprise Application Architecture (Addison Wesley Professional, 2002).
6. [GAMMA ET AL., 1995] Gamma, Erich, Helm, Richard, Johnson, Ralph, and Vlissides, John, Design Patterns. Elements of Reusable Object-Oriented Software (Addison Wesley, Reading, 1995).
7. [GELS, ABCOUWER, 1996] Gels, H.J., and Abcouwer, A.W., Informatiebeleid (Academic Service, Schoonhoven, 1996).
8. [HAMMER, CHAMPY, 2002] Hammer, Michael, and Champy, James. A., Reengineering the Corporation: A Manifesto for Business Revolution (HarperBusiness, 2002).
9. [HARMON, 2002] Harmon, Paul, The OMG’s Model Driven Architecture, XII (Cutter, 2002).
10. [HEINCKIENS, 2002] Heinckiens, Peter, in Landelijk Architectuur Congres; Zeist, 2002), .
11. [HUBERT, 2002] Hubert, Richard, Convergent Architecture (John Wiley & Sons, 2002).
12. [JACOBSON ET AL., 1997] Jacobson, Ivar, Griss, Martin, and Jonsson, Patrik, Software reuse: architecture, process and organization for business success (ACM Press/Addison-Wesley Publishing Co., 1997).
13. [JOHNSON ET AL., 2001] Johnson, Jim, Boucher, Karen J., Connors Kyle; Robinson, , and Robinson, James, Collaboration: Development & Management. Collaborating on Project Success https://web.archive.org/web/20101222071952/http://www.softwaremag.com:80/archive/2001feb/CollaborativeMgt.html, 2001).
14. [LARMAN, 2002] Larman, Craig, Applying UML and Patterns. An introduction to Object-Oriented Analysis and Design and the Unified Process (Prentice Hall, New York, 2002).
15. [META GROUP, 2002] Meta Group, Enterprise Architecture Desk Reference (Meta Group, 2002).
16. [OMG, 2001] OMG, Action Semantics for the UML http://www.omg.org/techprocess/meetings/schedule/Action_Semantics_for_UML_RFP.html, 2001).
17. [OMG, 2003] OMG, MDA. the Architecture of Choice for a Changing Worldhttp://www.omg.org/mda/, 2003).
18. [RUMBAUGH ET AL., 1991] Rumbaugh, James, Blaha, Michael, Premerlani, William, Eddy, Frederick,and Lorensen, William, Object-Oriented Modeling and Design (Prentice-Hall International Editions, New York, NY, 1991).
19. [RUMBAUGH, 1997] Rumbaugh, James, Journal of Object Oriented Programming 11, 5-9 (1997).
20. [SARFERAZ, HESSE, 2001] Sarferaz, Siar, and Hesse, Wolfgang, in International Workshop on Software Measurement (IWSM2000); edited by Dumke, R., and Abran, (Springer Publishers, 2001), pp.29-43.
21. [SOLEY, OMG STAFF STRATEGY GROUP, 2002] Soley, Richard, and OMG Staff Strategy Group, , Model Driven Architectureftp://ftp.omg.org/pub/docs/omg/00-11-05.pdf, 2002).
22. [VENS, 2002A] Vens, Rob, Referentiemodel voor een business-centered architectuur. Deel 1: Motivatie en basisprincipes, 1 (Cibit, Utrecht, 2002). (a)
23. [VENS, 2002B] Vens, Rob, Referentiemodel voor een business-centered architectuur. Deel 2: Business domein component, 2 (Cibit, Utrecht, 2002). (b)

Volledige literatuurlijst

Hieronder volgt een leeswijzer.

1. P. Allen, and S. Frost, Component-Based Development for Enterprise Systems (Cambridge University Press, Cambridge, 1998).
2. M. Carbone, and G. Santucci, Fast&&Serious: a UML based metric for effort estimation (Universita’ degli studi di Roma “La Sapienza”, Rome, 2002).
3. D. d. Champeaux, Object-Oriented Development; Process and Metrics (Prentice-Hall, New York, 1997).
4. A. Cockburn, Surviving Object-Oriented Projects: A Manager’s Guide (Addison-Wesley, 1998).
5. D. DSouza, and A. C. Wills, Objects, Components, and Frameworks with UML (Addison Wesley, Reading, 1999).
6. D. DSouza, Model-Driven Architecture and Integration – Opportunities and Challenges (ftp://ftp.omg.org/pub/docs/ab/01-03-02.pdf, 2002).
7. M. Fayad, and M. Laitinen, Transition to Object-Oriented Software Development (John Wiley & Sons, 1998).
8. M. Fowler, Refactoring. Improving the Design of Existing Code (Addison Wesley, Reading, 1999).
9. M. Fowler, D. Rice, M. Foemmel, E. Hieatt, R. Mee, and R. Stafford, Patterns of Enterprise Application Architecture (Addison Wesley Professional, 2002).
10. E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns. Elements of Reusable Object-Oriented Software (Addison Wesley, Reading, 1995).
11. H. Gels, and A. Abcouwer, Informatiebeleid (Academic Service, Schoonhoven, 1996).
12. I. Graham, B. Henderson-Sellers, and Younessi Houman, The OPEN Process Specification (Addison-Wesley, Harlow, 1997).
13. M. Hammer, and J. A. Champy, Reengineering the Corporation: A Manifesto for Business Revolution (HarperBusiness, 2002).
14. P. Harmon, The OMG’s Model Driven Architecture (http://www.cutter.com/research/2002/edge020611.html, 2002).
15. P. Harmon, The OMG’s Model Driven Architecture, XII (Cutter, 2002).
16. P. Heinckiens, in Landelijk Architectuur Congres; Zeist, 2002), .
17. B. Henderson-Sellers, and B. Unhelkar, OPEN Modeling with UML (Addison-Wesley, Harlow, 2000).
18. Henderson-Sellers; Brian, Object-oriented metrics: measures of complexity (Prentice Hall, New York, 1996).
19. R. Hubert, Convergent Architecture (John Wiley & Sons, 2002).
20. J. Johnson, K. J. Boucher, Connors Kyle; Robinson, and J. Robinson, Collaboration: Development & Management. Collaborating on Project Success https://web.archive.org/web/20101222071952/http://www.softwaremag.com:80/archive/2001feb/CollaborativeMgt.html, 2001).
21. C. Larman, Applying UML and Patterns. An introduction to Object-Oriented Analysis and Design and the Unified Process (Prentice Hall, New York, 2002).
22. M. Lorenz, and J. Kidd, Object-oriented metrics: a practical guide (Prentice Hall, New Yorn, 1994).
23. Meta Group, Enterprise Architecture Desk Reference (Meta Group, 2002).
24. OMG, Action Semantics for the UML (http://www.omg.org/techprocess/meetings/schedule/Action_Semantics_for_UML_RFP.html, 2001).
25. OMG, MDA. the Architecture of Choice for a Changing World (http://www.omg.org/mda/, 2003).
26. T. Rowlet, The Object-Oriented Development Process: Developing and Managing a Robust Process for Object-Oriented Development (Pearson Education, 2000).
27. J. Rumbaugh, Journal of Object Oriented Programming 11, 5-9 (1997).
28. S. Sarferaz, and W. Hesse, in International Workshop on Software Measurement (IWSM2000); edited by R. Dumke, and Abran (Springer Publishers, 2001), pp.29-43.
29. R. Soley, and OMG Staff Strategy Group, Model Driven Architecture (ftp://ftp.omg.org/pub/docs/omg/00-11-05.pdf, 2002).
30. R. Vens, Referentiemodel voor een business-centered architectuur. Deel 1: Motivatie en basisprincipes.
31. R. Vens, Referentiemodel voor een business-centered architectuur. Deel 2: Business domein component.

13. Lijst van figuren

• Figuur 1: Vierlagen architectuur
• Figuur 2. Een architectuur zonder satellieten
• Figuur 3. Een architectuur met satellieten
• Figuur 4. Service Component
• Figuur 5. Events en messages
• Figuur 6. Persoon met adapters
• Figuur 7. De kern van autorisatie
• Figuur 8. Het HABC van Autorisatie
• Figuur 9. Domeinmodel autorisatieregels
• Figuur 10. Model afbeeldingen (mappings)
• Figuur 11. Java packaging technische architectuur
• Figuur 12. Voorbeeld van een domein model
• Figuur 13. Relatie Domein-SAF-Service
• Figuur 14. Observer pattern in SAF
• Figuur 15. Adapter pattern in SAF
• Figuur 16. Sequence diagram van een update
• Figuur 17. Koppeling domein met services
• Figuur 18. SMI als uniforme interface
• Figuur 19. Componenten AAS productieomgeving
• Figuur 20. Streefsituatie
• Figuur 21. UML model van een methode
• Figuur 22. Fasen en disciplines in UP (Unified Process)
• Figuur 23. MDA
• Figuur 24. Koppeling tussen services en domein
• Figuur 25. Adapters
• Figuur 26. Domein class vóór transformatie
• Figuur 27. Domein class ná transformatie

14. Appendices

Begrippenlijst

Begrip	Definitie
Applicatie architectuur	ICT Applicatiestructuur
Architectuur	Een architectuur is een modelmatige weergave van de werkelijkheid. De belangrijkste functie is het faciliteren van strategische en tactische besturing op basis van een éénduidige visie. Architectuur ondersteunt het besturings- en planvormingsproces.
Berichtenboek	Bundeling van berichten met hun specificatie. Hierin moet ook de ‘flow’ staan van berichten. Een goed uitgangspunt is het Bar berichtenboek van de RDW.
Beveiligingsarchitectuur	De beveiligingsarchitectuur laat zien op welke wijze de betrouwbaarheid van de informatie wordt zekergesteld.
Gegevensmodel	Het gegevensmodel beschrijft de samenhang tussen gegevens die voor de uitvoering van alle bedrijfsprocessen noodzakelijk zijn.
Informatie architectuur	De informatievoorziening van de organisatie
Infrastructuur architectuur	ICT-infrastructuur; hieronder vallen data management, platform en netwerk
Logische applicatie architectuur	De logische samenhang tussen applicaties en producten en hun onderliggende componenten.
Model Driven Architecture (MDA)	Model Driven Architecture (MDA) is een formele methode voor het ontwerpen en realiseren van software systemen waarbij onderscheid gemaakt wordt tussen de business logica en de technologie waarin het gerealiseerd wordt.
Platform Independent Model (PIM)	Een platform onafhankelijk model waarin technologie onafhankelijke functionaliteit gespecificeerd wordt.
Platform Specific Model (PSM)	Een platform afhankelijk model waarin de technologie afhankelijkheden gemodelleerd worden. Voor elk platform zal er een model zijn waarin het gedrag van het platform staat gespecificeerd.
Portal	Met behulp van converters ontsluiten van legacy en nieuwe technologieën
Publieke interface	Services die aangeboden worden aan de buitenwereld.
Referentie architectuur	Bestaat uit een conceptueel, logisch en technisch model.
Technische applicatie architectuur	Technische componenten in de infrastructuur

Lijst van taken

Afleveren product bij klant/opdrachtgever
Analyseren user requirements
Architectuur ontwerp	Ontwikkel lagen ontwerp Stel de systeemstrategie voor distributie vast Selecteer database/opslag strategie
Coderen
Constructie object model
Design en implementatie fysieke database	Design distributie/replicatie Operationeel en performance ontwerp
Design user interface
Doen haalbaarheids studie
Doen in-process review
Doen post-implementatie review
Doen usability ontwerp
Evalueren kwaliteit	Analyseren metrieken Evalueren usability Review documentatie
Identificeren bronnen van requirements
Identificeren classes, interfaces, responsibilities (CIR)	Opbouwen lijst van kandidaat classes Vaststellen persistente classes Identificeren rollen Verfijnen class lijst
Identificeren context
Identificeren user requirements	Definieer probleem en leg missie en doelstellingen vast Stel de user requirements vast voor gedistribueerde systemen Stel de database requirements voor de gebruiker vast
Maken of identificeren herbruikbare componenten	Constructie frameworks Optimaliseren voor hergebruik
Managen van de library van herbruikbare componenten
Mappen logisch database schema
Mappen van rollen op classes
Modelleren en re-engineeren business processen	Bouw context (m.a.w. business proces) model Bouw taken object model Zet taken model om in business object model Train de gebruikers
Onderhouden trace tussen requirements en design
Ontwikkelen business model (BOM)
Ontwikkelen en implementeren resource allocatie plan	Keuze hardware Keuze project team Keuze toolset Decompositie programma’s in project Ontwikkeling opleidings- en trainingsplan Ontwikkelen iteratieplan Ontwikkelen timebox plan Identificeren projectrollen en verantwoordelijkheden Managen van packages/subsystemen Opzetten verzamelingen metrieken Vaststellen van individuele doelen Vastleggen kwaliteitsdoelen Op basis van afhankelijkheden in business model maken van de eerste opzet voor project plan
Ontwikkelen software development context plannen en strategieën	Opzetten capaciteitsplan Opzetten contingency plan Opzetten security plan Vaststellen strategie voor change-management Vaststellen strategie voor gegevensvastlegging Integreer met bestaande, niet OO systemen Lifecycle proces op maat maken
Optimaliseren hergebruik
Optimaliseren van het design
Schrijven handboeken en andere documentatie
Testen	Doe acceptatie test Doe class test Doe package/cluster test Doe regressie test
Verkrijgen goedkeuring van de business
Hoofdtaak	Subtaak

15. Voetnoten

[1] De definitie van besloten behelst het hele beveiligingsvraagstuk, technisch en bedrijfsmatig.

[2] Dit logische model is niet te vergelijken met een generiek datamodel of andere complexe en onoverzichtelijke modellen. Dat komt niet omdat het model niet onoverzichtelijk zou zijn. Integendeel: alle pogingen om complexiteit te reduceren door eenvoudiger modellen te gebruiken zijn gedoemd te mislukken omdat essentiële informatie weggelaten blijkt te zijn, validatie onmogelijk is, of wijzigingen in het model niet door te rekenen zijn. De wereld is nu eenmaal complex. De strategie die dit model wél manageable maakt is gebaseerd op het objectgeoriënteerde karakter ervan: het model is dynamisch en executable, kan zichzelf valideren, dient in staat te zijn procesmodellen te genereren ter validatie, enz. Kortom: het model is groot, complex, en onoverzichtelijk, en móet dat ook zijn om in de buurt te komen van de functionaliteit die het moet ondersteunen. De gebruiker van het model heeft echter een batterij aan tools om dit te managen.

[3] [Hammer, Champy, 2002]

[4] [Heinckiens 2002]

[5] De huidige stand van component-based ontwikkeling leidt tot redelijk grote componenten. De verwachting is dat naarmate deze technologie volwassener wordt deze componenten steeds kleiner kunnen worden. Dit is met name een beheerprobleem. De meeste organisaties hebben (als zij dat al hebben!) een onvoldoende ingevuld componentenbeheerproces. Zie hiervoor ook: [Jacobson et al., 1997].

[6] In principe is er geen reden waarom asynchrone communicatie binnen een component (business component zowel als service component) niet toegestaan zou worden. Om problemen met multiprocessing te voorkomen is vooralsnog echter deze beperking gekozen. Het is geen beperking van de architectuur. Het probleem speelt alleen binnen min of meer monolithische applicaties. Bij ketensystemen e.d. is asynchrone communicatie niet te vermijden.

[7] Een speciaal voorbeeld van syntactische validatie is het formaat van tekst in invoervelden. De vraag binnen deze architectuur is: is dit een domein verantwoordelijkheid of niet? Het antwoord is: dat er een datum staat in een veld met een bepaalde representatie die bijvoorbeeld afhankelijk is van lokalisatie en stijl, is een business verantwoordelijkheid en past dus binnen het domein. Om die validatie echter door het domein te laten doen op het moment van invoer is onzinnig. In plaats daarvan wordt het parametriseren van het invoerscherm gedaan bij de start, op basis van de domein informatie. Houdt het domein verantwoordelijk!

[8] J2EE wordt niet toegepast voor het implementeren van het domeinmodel vanwege de onvolwassen en beperkende technologie – hiervoor worden “gewone” Java beans gebruikt, of Java classes (zgn. POJO objecten: Plain Old Java Objects)

[9] De OPAFIT-inrichtingsaspecten zijn:

• O(rganisatie)
• P(ersoneel)
• A(dministratieve organisatie)
• F(inancieën)
• I(nformatie)
• T(echniek)

Daarnaast worden ook vaak C(ommercie), J(uridisch) en H(uisvesting) genoemd. Afkomstig uit [Gels, Abcouwer, 1996].

[10] [Rumbaugh, 1997]

[11] Gartner en vele andere marktonderzoekers spreken elkaar voortdurend tegen dus de genoemde cijfers zijn een gemiddelde. Voor criteria bij dit soort cijfers zie o.a. [Johnson et al., 2001]

[12] Gebruik hiervoor appendix 1.2 Lijst van taken

[13] zie ondermeer: [Carbone, Santucci, 2002] en [Sarferaz, Hesse, 2001]