Architectuur in de digitale wereld/2007-08

Inleiding

In dit project vindt u een analyse van een verzameling literatuur. Hoewel de onderwerpen van de teksten divers zijn, hebben zij tenminste één aspect gemeen, zij gaan allen over Digitale Architectuur. In deze cursus Inleiding Informatiearchitectuur hebben wij ons met name gericht op literatuur van Daan Rijsenbrij en Erik Proper, maar Digitale Architectuur (of gerelateerde vakgebieden) heeft de aandacht van meer personen en organisaties in deze wereld. Begrijpelijkerwijs is er dus ook meer interessante en kwalitatieve literatuur voorhanden welke een completer begrip geven het vakgebied Digitale Architectuur. In dit project hebben wij verschillende literatuurstukken geanalyseerd en presenteren wij u de belangrijkste punten. Er is voor gekozen een viertal insteken te nemen op het onderwerp Digitale Architectuur, namelijk architectuur in theorie, architectuur in de praktijk, de menselijke maat en tenslotte Enterprise Architecture (EA).

Om u als lezer zoveel mogelijk houvast te bieden en de verbanden tussen deze verschillende aspecten van Digitale Architectuur zo goed mogelijk te verhelderen beginnen wij dit project met een korte inleiding op de verschillende onderwerpen welke aan bod zullen komen.

Architectuur is een term die wij op veel plaatsen tegenkomen. Allereerst natuurlijk binnen de bouwkunde maar ook binnen de ICT zien we de term architectuur regelmatig terug komen in een keur van betekenissen. Zo komen we het begrip bijvoorbeeld tegen wanneer we het hebben over fysieke infrastructuur, maar ook als een verzameling normen. Hoofdstuk 1 Architectuur in theorie biedt u een overzicht van de verschillende betekenissen wat het woord "architectuur" in de ICT en verhelderd wat Digitale Architectuur wel is, en wat het niet is.

Nadat wij u een duidelijker beeld hebben gegeven van wat architectuur nu precies is, zijn we gaan kijken naar architectuur in de praktijk. Immers uiteindelijk is Digitale Architectuur toch een pragmatisch vakgebied, ondanks haar conceptuele en abstracte karakter. De rapportage biedt u in hoofdstuk 2 Architectuur in de praktijk inzicht in onderwerpen als wie is nu eigenlijk de architect, wat is de meerwaarde van Digitale Architectuur, waar de architect rekening mee dient te houden bij het opstellen van een digitale architectuur en waarom Digitale Architectuur in de praktijk niet werkt. Dit hoofdstuk wordt afgesloten met een casestudy.

Vervolgens gaan we ons met het project verdiepen in twee "deelgebieden" en richten wij onze aandacht specifiek op twee deelgebieden van de Digitale Architectuur, namelijk De menselijke maat en Enterprise Architecture.

De menselijke maat komt aan bod in de lessen Inleiding Informatiearchitectuur. Maar er zijn natuurlijk meer auteurs welke hun visie uitdrukken over de menselijke maat in de ICT. Ondanks het grote belang van de menselijke maat is dit aspect van digitalisering vaak een ondergeschoven kindje. In hoofdstuk 3 De menselijke maat in Informatie Architectuur tonen wij u met enkele literatuurstukken hoe architectuur, en spelers binnen de ICT, de menselijke maat een waardige rol kunnen laten spelen.

ICT is niet enkel een technische aangelegenheid. ICT is er voor de business en de business speelt dan ook een hoofdrol/belangrijke rol binnen ICT, of dient dit te doen in een ideaal situatie. Het is dan ook interessant onze blik eens te richten op een vakgebied welke prima past binnen Digitale Architectuur als paraplubegrip, namelijk Enterprise Architecture. Enterprise Architecture richt zich namelijk op business/ICT alignment. Hoofdstuk 4 Enterprise Architecture voert u in op dit onderwerp aan de hand van een aantal teksten over Enterprise Architecture of direct gerelateerde onderwerpen.

Tenslotte willen wij u graag nog onze belangrijkste conclusie voorleggen voordat u begint aan het verder verkennen van het vakgebied Digitale Architectuur. Hoewel Enterprise Architecture veel meerwaarde kan bieden in een complexe digitale wereld en er vele interessante ontwikkelingen bezig zijn, is er nog een lange weg te gaan voordat Digitale Architectuur ook in de praktijk bij draagt aan een overzichtelijke, beheersbare en beter doordachte digitale wereld.

Architectuur in theorie

Het woord architectuur wordt in de praktijk voor een grote verscheidenheid aan ontwerpen en ontwerpbeslissingen gebruikt. Iedereen heeft wel enig idee wat de betekenis van het woord is. Jaap van Rees heeft jarenlange ervaring in het vakgebied, en is gekomen tot een gedetailleerde beschrijving van wat 'architectuur' volgens hem in theorie inhoudt.

Het begrip architectuur

_{Vrij naar Het architectuurbegrip}

In de bouwkunde is architectuur onverbrekelijk verbonden met cultuur. De architectuur van een gebouw is een uitdrukking van de cultuur in de tijd dat het werd gebouwd. De normen en waarden van de opdrachtgever en de bouwer komen tot uiting in de constructie. Het boeiende is dat dit meestal deels expliciet door hen is besproken en besloten en deels impliciet in de ontwerpbeslissingen is meegenomen. Dat laatste omdat het nu eenmaal zo was; traditie, gewoonte, vanzelfsprekend.
Architectuur wordt ook op die manier ervaren. Je kunt je daarvan bewust worden door bij gebouwen de vraag te stellen "welk soort organisatie zou ik in dat gebouw verwachten en welke juist niet?". De constructie vertelt dus iets over de bewoner. De vraag is nu of dit voor constructies in de informatievoorziening ook het geval is. Het antwoord is: JA! Het is een kwestie van leren kijken. Zoals dat bij gebouwen ook moet gebeuren, kan je door het stellen van de goede vragen de informatie-architectuur van systemen gaan zien. De informatische constructie vertelt wat de opdrachtgever en de ontwerper impliciet en expliciet belangrijk vonden of vinden en is daarmee een afspiegeling van de cultuur van een organisatie. Een informatie-architect helpt een opdrachtgever echter ook bij het vormen van een beeld van de wijze waarop de organisatie en de informatietechnologie samen een toekomst opbouwen. Een informatie-architect baseert zijn ontwerp dus op twee pijlers: de mogelijkheden van de IT aan de ene kant en de kenmerken van de organisatie aan de andere kant. De informatie-architect moet dus van beide verstand hebben om de juiste synthese te kunnen ontwerpen.

De verschillende betekenissen van het begrip 'architectuur' in de ICT

_{Vrij naar Architectuur, hoe bedoelt u?}

Architectuur als metafoor

Soms ontbreken ons de juiste woorden om iets uit te drukken. In dat geval lenen we termen uit een ander vakgebied. We gebruiken dan die term als metafoor. Dat gebeurt met de termen architect en architectuur steeds vaker. We zeggen bijvoorbeeld dat Vermeend de architect is van het nieuwe belastingstelsel.

Architectuur als informatieplan

Deze opvatting sluit aan bij de manier van denken van automatiseerders. Een computerprogramma is een samenhangend geheel, anders werkt het niet correct. Een informatiesysteem moet ook een samenhangend geheel zijn van programma's en bestanden. Het is een logische stap om alle informatiesystemen van een organisatie te beschouwen als samenhangend geheel.
In veel organisaties is, als gevolg van lokale automatisering, een lappendeken aan systemen ontstaan. Deze systemen zijn elk op zichzelf ontwikkeld met eigen codestelsels en definities en kunnen daardoor niet met elkaar communiceren. Vaak overlapt de functionaliteit van de systemen, met als gevolg dat het management uit verschillende systemen informatie ontvangt die niet overeenkomt. Door inconsistenties in de beleidsinformatie gaat het vertrouwen in de informatieverwerking verloren. Dit moeten wij in de toekomst voorkomen. Daartoe maken we een informatieplan, waarin de gewenste situatie staat beschreven, samen met de stappen die moeten worden genomen om die te realiseren. Alle systemen die de komende jaren worden gebouwd, vloeien voort uit het informatieplan.
Elk informatieplan is echter gebaseerd op veronderstellingen over de organisatie als geheel. Typerend voor deze opvatting is een uitspraak als "de informatie-architectuur is een globale, abstracte beschrijving van alle systemen".

Architectuur als plattegrond

De kern van een informatieplan was een plaatje waarin de gewenste onderverdeling van de informatievoorziening stond beschreven. Zo'n plaatje noem ik tegenwoordig de plattegrond. Vroeger heette dat wel de informatische structuur. Maar ik ben ook termen tegengekomen als 'de indeling in informatiedomeinen' of 'de informatiesystemenlandschapskaart'. Duidelijk een geval van behoefte aan een geschikte term. En als er dan een woord als architectuur in de lucht hangt, dan is het verleidelijk om dat woord te plakken op het plaatje waarin de samenhang wordt beschreven. "We hebben een architectuur gemaakt" of "Geef mij de architectuur even aan" of "De architectuur stond op het bord, maar iemand heeft het uitgeveegd" zijn uitdrukkingen die in deze opvatting heel normaal zijn. Architectuur is de naam van het plaatje geworden.

Architectuur als de criteria voor de indeling

Een van de problemen met de informatieplannen was de interpretatie van de plattegrond. Voor de medewerkers van het projectteam, die maanden over de plattegrond hadden gediscussieerd, leek het uiteindelijke resultaat een eenduidige weergave van hun beeld van de toekomstige situatie. Zodra anderen na de goedkeuring met die plattegrond verder gingen bleek dat er verschillende interpretaties mogelijk waren. Daaruit zijn twee belangrijke lessen te trekken. Ten eerste: het plaatje roept het bedoelde beeld op bij diegenen die het beeldvormingsproces gezamenlijk hebben doorlopen, maar voor anderen geldt dit niet. Ten tweede: de indeling, die met de plattegrond wordt beschreven, moet expliciet in ondubbelzinnige termen worden beschreven. Die beschrijving heeft het karakter van de verkeersregels voor de informatieverwerking. De verzameling van indelingscriteria of ordeningscriteria kunnen we de architectuurprincipes noemen. Sommigen noemen die verzameling gewoon 'de architectuur'.

Architectuur als een verzameling regels

Een volgende stap is daaraan ook andersoortige regels toe te voegen. Zoals beschrijvingen van interfaces, regels voor toe te passen standaards, constructieprincipes voor het bewaken van de kwaliteit van de constructies tot en met onze design patterns waarin alle mogelijke ervaringsfeiten worden opgenomen over constructies in programma's, databases, maar ook over de aanpak van projecten en het organiseren van het testen. Deze totale verzameling van regels noemen we dan onze architectuur. Architectuur krijgt dan veel meer de betekenis van normen, zoals die in andere vakgebieden in NEN's worden beschreven.

Architectuur als infrastructuur

Deze opvatting lijkt ook voort te komen uit het oorspronkelijke probleem van de informatieplannen. De overlappende systemen hadden niet alleen redundante data, maar ook de codes en de interfaces waren redundant. Dezelfde berekening kwam op verschillende plaatsen in de programmatuur voor. Bij wijzigingen van de rekenregels moest dat dus op al die plaatsen worden aangepast en bij gebrek aan overzicht werd er weleens een vergeten, met nog meer inconsistenties als gevolg. Dat leidde tot het inzicht dat bij een planmatige aanpak dezelfde functie op verschillende plaatsen kan worden gebruikt. Het deel van de code dat voor algemeen gebruik beschikbaar kwam werd de infrastructuur genoemd. Het plaatje waarin dat werd beschreven, werd architectuur genoemd en ik heb het vermoeden dat soms de term architectuur wordt gebruikt voor het infrastructurele deel van de informatieverwerking. Een opvatting die we ook in de technische automatisering tegenkomen, waar de architectuur van een familie van chips bijvoorbeeld wordt gedefinieerd als de elementen die alle leden van de familie gemeenschappelijk hebben.

Architectuur als ontwerp

Omdat het begrip architectuur moeilijk te definiëren blijkt kunnen we terugvallen op het begrip architect en van daaruit architectuur definiëren als 'architectuur is alles wat door een architect wordt geproduceerd'. Wanneer iemand zich dus database-architect noemt dan heet het ontwerp van de database dat hij maakt de database-architectuur. Architectuur is dan synoniem voor ontwerp.

Architectuur als synoniem voor structuur

We kunnen de indeling van een gebouw, de onderverdeling van de ruimte en de verbindingen tussen de ruimten, waarnemen door door het gebouw heen te lopen. Daarvoor hebben we geen tekening nodig. Bij de informatievoorziening is dat moeilijker, maar de gebruiker ervaart wel iets dat vergelijkbaar is. Bijvoorbeeld welke andere gebruikers toegang hebben tot dezelfde gegevens. De structuur kunnen we dus waarnemen, ervaren, door naar de informatieverwerking zelf te kijken. Daarvoor hebben we geen tekening nodig. Deze structuur kunnen we de architectuur noemen.

Architectuur als aspect

Het architectuuraspect van de informatieverwerking is wat we, door naar de informatieverwerking te kijken, te weten komen over de cultuur van degenen die de ontwerpbeslissingen hebben genomen. Dit aspect wordt door gebruikers meestal onbewust ervaren, zoals we het architectuur aspect van de ruimte waarin wij ons bevinden meestal ook onbewust ervaren. Toch beïnvloedt het ons gedrag en onze stemming.
In de grammatica kent men de begrippen syntax en semantiek. De syntax betreft de regels voor de spelling. De semantiek betreft de betekenis die we aan woorden toekennen. Deze begrippen kunnen we ook toepassen op de informatieverwerking. De syntax gaat dan over de constructieregels. Zit de constructie technisch gezien goed in elkaar? De semantiek gaat over de betekenis die we aan de vormgeving van de informatievoorziening toekennen. Architectuur is de semantiek van de constructie.

Architectuur in de praktijk

De informatievoorziening van een bedrijf is nooit af. In een bedrijvige organisatie worden nieuwe activiteiten ontplooid en worden steeds nieuwe eisen aan de ondersteuning gesteld, zowel in functioneel opzicht als uit prestatieoogpunt. Min of meer staat continu de informatievoorziening in de steigers en het is dus zaak de veranderingen ordelijk in te passen terwijl de bestaande voorzieningen, die aan het verdienvermogen bijdragen, goed blijven functioneren. Het beheersbaar houden van de informatievoorziening en het veranderbaar houden is een opgave waar architectuur een antwoord op moet geven. De architectuuragenda bestaat niet alleen uit 'business requirements' maar ook uit een aantal 'non-functionele requirements' zoals: consistente bouwpatronen, capaciteitsbereik van componenten en beheersbaarheid van werkende systemen.

De organisatie die er rondom een architectuurproject is, hoeft niet eindeloos voort te bestaan. Maar men moet beseffen dat er systemen onder architectuur worden gebouwd en opgeleverd, en dat die systemen zullen moeten worden onderhouden en regelmatig aangepast. Dan moet er over de consequenties van aanpassingen kunnen worden gesproken om uitbreidbaarheid, stabiliteit en exploitatiekosten te beoordelen en zullen waarschijnlijk dezelfde "stakeholders" ter besluitvorming aan de tafel moeten zitten als tijdens het architectuurproject.

De kwaliteit van een architectuur is niet eenvoudig vast te stellen. Voor een deel zit die kwaliteit in het architectuurproces en in de relaties met de 'stakeholders' die daadwerkelijk betrokken zijn. Voor een ander deel zit die kwaliteit in het architectuurvermogen dat is ingebracht. Dan gaat het om kwaliteit van de vertalingen van business-wensen en van ICT-mogelijkheden, om de materiaalkennis die daarbij is ingezet en om de structurele eigenschappen die in de loop der tijd het architectuur gelijk moet bewijzen. Uiteindelijk gaat het de uitspraak op:"aan de vruchten ken je de booom". Een architect zal die vereiste kwaliteiten waarschijnlijk niet in zich verenigen. Zijn kwaliteiten als teamspeler en als bindende kracht zijn dan ook bepalend. (Working paper Series, Universiteit van Amsterdam, Mr. Meint Post, Jan Truijens, Oktober 2005)

Het begrip digitale architectuur

Wanneer je aan architectuur denkt, denk je vaak aan een ontwerp, vooral in de digitale omgeving. Maar dit klopt niet, want eigenlijk maakt architectuur een goed en betrouwbaar ontwerp mogelijk. Architectuur is de weerslag van een door de 'stakeholders' gedeelde visie in de vorm van een beschrijving van componenten, hun onderlinge relaties en hun afzonderlijke en gezamenlijke prestaties. Een architectuur is geslaagd als de systemen die onder die architectuur tot stand gekomen zijn naar wens en naar behoren werken. Architectuur is niet (uitsluitend) een ontwerp maar (ook) een stelsel van richtlijnen en standaarden.

In de praktijk kent de term 'digitale architectuur' 2 interpretaties: 1. de prescriptieve: een verzameling ontwerpprincipes die de operationele concretisering zijn van algemene eisen en wensen. 2. de descriptieve: het globale ontwerp van een systeem dat is opgesteld volgens de ontwerp principes die gelden voor de klasse waartoe het systeem behoort.

De architect

Een architect bemoeit zich met de PR rond 'zijn' architectuur maar heeft ook bemoeienis met de concretisering in de ontwerp- en bouwfasen. Aldus werkt hij in twee richtingen: op de lijn tussen wensen en mogelijkheden en op de lijn van conceptie naar concrete producten. Het mooie van architectenwerk is dat er geen compromissen gesloten mogen worden, niet met de gebruikers, niet met de opdrachtgevers en niet met de bouwers. Tegenstrijdige eisen en wensen zullen vroegtijdig moeten worden opgespoord, prestatie-eisen dienen gegarandeerd te kunnen worden, kostenschattingen mogen geen 'slag in de lucht' zijn en onderzekerheden moeten in pilots worden uitgebannen voordat ze de architectuur kunnen infecteren.

Een architect werkt bij de ontwikkeling van de informatievoorziening met 2 perspectieven: het realisatie perspectief en het ondersteuningsperspectief, en deze twee perspectieven zijn onlosmakelijk met elkaar verbonden:

• Het realisatieperspectief loopt van de eerste architectuurschetsen tot en met het ingebruik nemen van de systemen die onder zijn architectuur zijn beschouwd.
• Het ondersteuningsperspectief betreft de business-wensen en de ICT-mogelijkheden tot en met de gekozen implementatie.

De architect moet zijn business-domein kennen om gesprekspartner met de business te zijn en te blijven en daarnaast moet hij zijn technologie-domein kennen om maakbaarheid te kunnen beoordelen en architectuurconformiteit daadwerkelijk te kunnen toetsen.

Architectuur is meer dan plaatjes, principes en papieren tijgers en daarom moet de architectuurbemoeienis in realisatieprojecten reiken. Om zeker te zijn dat precies wordt geboud hetgeen is beoogd en dat de prestaties aan de uitgangspunten voldoen, zullen kritieke componenten tevoren moeten worden beproefd, zodat zekerheid omtrent de gekozen constructieprincipes worden verkregen. Dan blijkt de vakkennis van de architect. (Working paper Series, Universiteit van Amsterdam, Mr. Meint Post, Jan Truijens, Oktober 2005)

Principes, regels, richtlijnen en standaarden

Principes beïnvloeden de wijze waarop ict wordt ingezet. De nadere concretersering van principes in regels, richtlijnen en standaarden zorgt voor verduidelijking. Principes geven namelijk aan wat er beperkt wordt binnen de ontwerpruimte en regels, richtlijnen en standaarden geven aan hoe de ontwerpruimte beperkt wordt. Regels zijn verplichtend binnen de organisatie, standaarden zijn vereiste voor de communicatie zowel intern als met de buitenwereld en voor het gebruik van gekochten componenten. Richtlijnen hebben wat meer interpretatievrijheid ten opzichte van regels, het zijn in feite 'best practices'. (Digitale Architectuur en de netwerkorganisatie: onlosmakelijk verbonden, Dr. ing. Sietse Overbeek)

Het opstellen van architectuur

Bij het opstellen van een architectuur dient de architect rekening te houden met de volgende punten:

• de gewenste rol en plaats binnen het ecosysteem
• de plaats van de onderhavige onderneming in de bedrijfstypologie
• de ontwikkelingen in het assortiment van producten en diensten van de onderneming, mede in relatie tot haar omgeving/bedrijfstak
• de interne beschouwingswijze van de onderneming en de managementstijl
• het mensbeeld binnen de onderneming (zowel individueel psychologische factoren als de medewerker gezien in zijn rol als mens in de werkomgeving)
• de bedrijfscultuur
• het automatiseringsstadium van de onderneming

Het opstellen van een architectuur is een continu proces. Architectuur is nooit geheel klaar en wordt daarom beschouwd als een groeimodel. Op 5 abstractieniveau's dienen er architecturen dienen te worden ontwikkeld die elkaar onderling zullen beinvloeden namelijk: de onderneming in zijn geheel, de domeinen, de applicaties, de technische infrastructuur en uiteindelijk de digitale werkruimtes.

Architectuur wordt steeds vaker een verbijzondering van een bepaald algemeen aanvaarde referentiearchitecturen. Een groot aantal van de principes, regels, richtlijnen en standaarden komt elke keer weer terug in bepaalde probleemsituaties. Daarvoor worden referentiearchitecturen, als een soort superpattern gebruikt. Het is dan de uitdaging en de creatieve kracht van de architect om de referentiearchitectuur te verbijzonderen naar iets eigens voor de onderhavige ondernemingen. Voorbeelden hiervan zijn architecturen voor de inrichting van kantoorautomatisering, architecturen voor het gebruik van mobiele flexibele werkplekomgevingen. In een goede referentiearchitectuur is de kennis van jarenlange ervaring van architecten samengevat. Gelouterd door het gebruik. (prof. dr. Daan Rijsenbrij)

De meerwaarde van architectuur

De meerwaarde van architectuur zou moeten zijn:

• Architectuur moet ordenen: zonder duidelijke structuur is elke uitbereiding een avontuur.
• Architectuur moet regels en richtlijnen geven: zonder deze is elke verandering ook erosie.
• Architectuur moet ondersteunen bij innovatie: voorstellen moeten op hun consequenties kunnen worden beoordeeld en de resulterende vernieuwing moet mogelijk zijn zonder aantasting van continuïteit.
• Architectuur moet, garanties bieden: voorgestelde veranderingen moeten kunnen werken en moeten voldoende vlot kunnen worden verwacht.

Waarom architectuur in praktijk niet werkt

Projectleiders sturen ontwikkelingstrajecten op tijd, kosten en kwaliteit. In de praktijk blijken tijd en kosten belangrijker dan kwaliteit. Conformeren aan de architectuur, met name voor die aspecten die pas relevant zijn na afloop van het project, wordt daarom makkelijk en 'goed gemotiveerd' over boord gezet. Projecten zullen niet of beperkt bijdragen aan kwaliteit, met beperkte levensduur en hoge onderhoudskosten als gevolg. Het probleem wordt verergerd doordat kosten en baten van architectuur op andere afdelingen in de organisatie vallen. De kosten van slechte functionaliteit vallen bij de uiteindelijke gebruiker, de baten van op tijd opleveren bij de projectleider. De kosten van negeren van de architectuur komen te liggen bij Beheer in de vorm van hoger beheersinspanningen en -kosten.

tweetal impliciete en onjuiste aannames over een projectgewijze invulling van architectuur:

• De eerste onjuiste aanname is dat de meeste IT projecten nieuwbouw zijn. In praktijk is echter 80 a 90% van de projecten geen nieuwbouw maar verbouw. Het kenmerk van verbouw is dat de originele architectuur grotendeels in takt blijft en er slechts op een beperkte schaal delen conform de nieuwe architectuur zullen worden ingevuld. Kortom, 80 tot 90% van de projecten draagt bij aan het verminken van de oude en nieuwe architectuur.

• De tweede onjuiste aanname is dat projecten willen bijdragen aan de realisatie van de architectuur. Elk project doet haar best, echter vanuit de beperkte blik van het project. Elk project zal dat stukje van de architectuur realiseren die het best voor het project is. Projecten dragen dus een min of meer willekeurige lappendeken van architectonische verantwoorde en onverantwoorde architectuurelementen aan. Kortom de projectorganisatie is geen overkoepelend orgaan die de totale verantwoordelijkheid kan nemen voor de realisatie van de architectuur.

(Architectuur en beheer, een natuurlijk partnership, George Kuijper, Pim Grooff en Eric Onderdelinden)

Praktijkvoorbeelden

Valkuil technologische ontwikkelingen

Nieuwe technologische ontwikkelingen hebben een grote impact op architecturen zowel in de fysieke wereld als in de digitale wereld en maakt totaal nieuwe architecturen mogelijk. De bouw van wolkenkrabbers werd pas mogelijk door de uitvinding van de personenlift, het is immers ondoenlijk om mensen vijftig verdiepingen te laten lopen. De toepassing van gewapend beton als constructiemateriaal stelde ons in staat om veel grotere ruimtes te overspannen. Technologie biedt ruimte voor nieuwe business activiteiten. Maar business activiteiten kunnen slechts bestaan bij de gratie van bijbehorende informatiestromen. Daarom is een goede architectuur voor het informatie- en kennisgebied belangrijker dan de onderliggende technologie. dus technologie is uitermate belangrijk om nieuwere architecturen te realiseren, maar technologie moet in de dienende rol blijven.

Veel high-tech ondernemingen hebben in hun eigen bedrijfsvoering een overdaad aan technologie ingezet. Dit komt door de aard van die onderneming en de vaak slagvaardige houding van haar medewerkers. Bij dergelijke ondernemingen is er altijd veel ruimte voor decentraal initiatief, hetgeen voor de eigen informatievoorziening vaak leidt tot een grote mate van wildgroei. en omdat technologie redelijk goedkoop is en de benodigde vakbekwaamheid in huis is, is de verleiding groot om snel oplossingen in elkaar te zetten. Dit resulteert meestal tot een soort Efelingachtige informatievoorziening: veel belangrijke (locale) attracties met een uitermate laag onderling verband en elk met hun eigen (beheer)personeel.

Voorts is het de gewoonte dat bij bedrijfsfusies die applicaties en infrastructuren worden geselecteerd die als het beste van de aanwezige mogelijkheden worden beschouwd. Door de vaak grote haast gaat men hier dan zogenaamd pragmatisch mee om en is er geen gelegenheid tot een fundamentele herbezinning op de architectuur van de nieuwe onderneming. (Architectuur en beheer, een natuurlijk partnership, George Kuijper, Pim Grooff en Eric Onderdelinden)

Rabobank.nl

De vernieuwing van de 'populaire' site "rabobank.nl" was niet alleen uit business-belang maar ook vanwege bedrijfsvoeringskwesties ondernomen. Als gevolg van het vroege begin van de internetactiviteiten liet de flexibiliteit te wensen over en dreigde de wet op de remmende voorsprong bewaarheid te worden. De kosten groeiden met de populariteit van de site. Het betrokken management wilde dan ook een nieuwe architectuur zodat de wetten van de complexiteit tijdig konden worden gekeerd. Op ondernemingsniveau wordt in de regel een (groot) aantal domeinen benoemd om tot minder complexe modellen te komen en de interactie met de 'stakeholders' van dat domein effectiever te doen verlopen. De beslissing binnen Rabobank Nederland de kanalen als een apart domein te behandelen heeft te maken met de overeenkomsten in marketing, in verkoopambitie en in klantgerichte orientatie. Daarnaast zijn natuurlijk de vereiste beveiliging van transacties, de bescherming van privacy van klanten en allerlei andere bestaande en verwachte multi-channelkwesties van belang. De hernieuwde aandacht voor CRM is in dit verband natuurlijk een in het oog springend voorbeeld. Het benoemen van een domein CRM betekent bij Rabobank Nederland dat de klantinformatie, klantcontacten, klantgerichte dienstverlening en klantgerichte commerciele activiteiten als een samenhangende bundel activiteiten en informatiebronnen kan worden beschouwd. Maar de CRM-gerichte activiteiten staan in de regel niet op zichzelf omdat ze veelal onderdeel zijn van commerciele of administratieve of bedrijfsvoeringsprocessen. Bij veel financiele instellingen, zo ook bij Rabobank Nederland, is Beveiliging een apart domein dat de gehele stapel, van gebruikersfuncties tot en met technische maatregelen, sluitend moet omvatten. Door dat security-domein worden ongeveer alle bancaire voorzieningen en handelingen beinvloed. Beveiliging is daarom niet alleen een vak dat veel specialistische kennis vereist maar ook een domein dat een grote actieradius heeft, van Mobile Banking en Internetbankieren tot en met aanlogkaarten voor PC's en procedures voor het vullen van geldautomaten. Alle detaillerings- en ontwikkelingsactiviteiten binnen een domein vergen dan ook een toets aan de regels en richtlijnen van het overkoepelende beveiligingsdomein. De beslissing bij Rabobank Nederland de kanalen als een apart domein te behandelen, heeft te maken met de overeenkomsten in marketing, in verkoopambitie en in klantgerichte orientatie, naast natuurlijk beveiliging van transacties en bescherming van persoonlijke aspecten. Binnen de architectuur voor het internetkanaal is gekozen voor een strikte scheiding van klant en niet-klantgedeelte. Het niet-klantgedeelte kent geen enkele vorm van klantherkenning (dus geen enkele vorm van authenticatie), in tegenstelling tot eerdere realisaties die voor klantherkenning een technisch foefje hadden. Door deze sterke vereenvoudiging kan met een simpele technologie worden gewerkt die lagere kosten meebrengt. Aantasting van dit vereenvoudigingsprincipe betekent aantasting van de gekozen technologie en daarmee van de bovenliggende business-case en de bijpassende architectuur. In de regel komt in Rabobank-architecturen geen capaciteitsoverweging voor omdat strikt genomen capaciteit en prestatie geen direct verband met functionaliteit hebben. Maar een architectuur die de (vervolg-)ontwikkeling richt en ordent moet ook de beschikbaarheid en de performance van passende componenten en de bruikbaarheid van het geassembleerde resultaat onder bedrijfsomstandigheden garanderen. Het heeft geen zin met abstracties te blijven werken op weg naar realisatie en integratie. Bij het opstellen van de internetarchitectuur hebben prestatie-overwegingen van meet af aan meegespeeld. De verschillende onderdelen van www.rabobank.nl dienen het aanbod (intertijd meer dan 200.000 bezoekers en meer dan 2 miljoen 'page views' per dag), het piekpatroon daarin en de beveiligingseisen te kunnen verwerken alsook de geprojecteerde aantallen en verwerkingseisen daarvan. Directe confrontie van het oplossingsstramien en de business-eisen is nodig, op straffe van luchtfietserij. Als verandering een gegeven is, kan de architectuur op een ander beschouwingsniveau worden ontwikkeld. In softwaretermen moet men denken aan een 'framework' dat voor een langere periode het ontwikkelingsraamwerk fixeert en regels en richtlijnen daaromtrent uitvaardigt. De in de architectuur Beveiliging, ContentManagement, Pagina-opmaak en Browsergebruik nauwkeurig vast te leggen kunnen toekomstige functies, hoe ook geimplementeerd, toch worden beveiligd, van informatie worden voorzien en effecient worden opgemaakt en gedistribueerd. Met de vereiste interfacespecificaties wordt zo uitbreiding zonder architectuuraanpassing mogelijk en, nog belangrijker, kan er min of meer 'in flight' worden gewijzigd en uitgebreid zonder schokgolven in de programmatuur en de service. Voorwaarde is een ijzeren discipline in het handhaven van het 'framework' dat als een meta-ontwerp onderdeel van de architectuur uitmaakt. Bij het samenstellen van het internet-architectuurteam werd een marketeerster annex communicatiedeskundige aangezocht om de business-visie te verwoorden. In eerste instantie was er enige huiver deel te nemen aan een 'mannenteam' van technische signatuur -"Ik wil jullie excuus-truus niet zijn" - maar al snel bleek dat we veel aan elkaar hadden. Allerlei marktonderzoeken kwamen los die zeer relevant bleken bij het opsporen en honoreren van flexibiliteitsfactoren. Bovendien werkte de voortdurende noodzaak van bepleiten en uitleggen van technische opties, hun business-mogelijkheden en hun bijkomende kosten zeer heilzaam. Voor de ICT-ers werd het een voortdurende oefening in bescheidenheid. In het kader van de nieuwe architectuur www.rabobank.nl is in een groot aantal Europese landen een aantal sites van financiele dienstverleners bezocht, beproefd en beoordeeld op business-proposities, 'look-and-feel' en technische eigenschappen. Met de gevonden mogelijkheden en eigenschappen zijn Rabobanks business-wensen alsook de huidige gebruikskenmerken geconfronteerd. De resultaten van een flinke impuls aan de vernieuwingsdrang van de business-units en aan de flexibiliteitseisen die aan de architectuur werd gesteld. De door de business gewenste personalisatie van www.rabobank.nl, vergde niet slechts een ongelukkige kanaalspecifieke administratie maar maakte feitelijk iedere pagina richting klant-browser uniek, waardoor 'caching' bij voorbaat werd uitgesloten. Dat zou tot enorme kostenverhoging in de exploitatie leiden. Diverse onderzoeken hadden inmiddels uitgewezen dat klanten slechts in uitzonderlijke gevallen en dan nog zeer beperkt van personalisatiemogelijkheden gebruik maken (minder dan 5% van de gebruikers van www.rabobank.nl). Gecombineerd met de hoge kosten leide dit tot het besluit af te zien van personalisatie voor www.rabobank.nl Bij de architectuurontwikkeling voor www.rabobank.nl waren enkele ICT-professionals ongeveer full-time geboekt maar slecht part-time ingeroosterd. Zij besteedden volgens plan een flink deel van hun tijd in lopende bouwprojecten en hadden daar intensief overleg met bouwteams. Aldus onstond een welomlijnd beeld van de mogelijkheden, voorkeuren en vakkenis van de ontwikkelaars alsook draagvlak voor nieuwe methoden en hulpmiddelen. Deze inspanningen bleken bij het vervolg van onschatbare waarde te zijn: Rabobank's internetbouwbedrijf was koersvast, ook in hoogste versnelling! Bij de Rabobank was een paar jaar eerder een hoeveelheid software aangekocht en aangepast. Er was nogal wat druk om die software via het internetarchitectuurtraject nieuw leven in te blazen om een desinvestering af te wenden. Het viel niet mee om dit 'nog even' buiten de deur te houden en eerst een behoorlijke concurrentie- en requirementsanalyse uit te voeren. Gaandeweg werd geaccepteerd dat het beter was het verlies te nemen dan van de vernieuwingsopdracht een overbepaald probleem te maken. Een eerder voorbeeld vervolgend: personalisatie vanaf het eerste scherm zou tot blijvend hogere exploitatie kosten leiden, terwijl de business een kostenverlaging van 50% wilde bereiken! Die kostenreductie vergde juist stroomlijnen van 'pagina-assemblage', eenvoud en snelheid in de 'paginamotor' en goedkope en goed werkende beveiligingscomponenten. De exploitatiekosten van de bestaande site van Rabobank waren niet eenvoudig vast te stellen vanwege de van oudsher over verschillende business-units gespreide voorzieningen en ondersteuningsteams. De programmacode was bovendien geheel volgens de "wet van de remmende voorsprong!" niet bepaald modulair voor belangrijke onderdelen zoals content management en internettransport en de transactieomgeving leerde het een en ander over de beveiligingskosten. Uiteindelijk koos het management uit een aantal varianten voor die achitectuur die op kosten en flexibiliteit onderscheidend was. De exploitatiekosten van die architectuur was overigens redelijk te schatten vanwege de modulariteit en de bekendheid met een aantal componenten, zoals 'zoek & vubd', contentmangement, formulierenmanagement, 'banners', 'statitistics' en FAQ. Rabobank beschikt inmiddels over de nodige exploitatie-ervaring op en op internetgebied zijn de prestaties van bekende componenten min of meer openbaar. Bij de samenstelling van het team is(natuurlijk niet toevallig) de ervaring met de (kleinschaleriger) ontwikkelin van www.rabobank.be de Rabosite in buurland Belgie ingebracht. Zelfs na pilots kunnen verassingen optreden, zeker als er fouten geconstateerd zijn. Overleg met ontwikkelaars moet dan tot bijstelling van gemaakte keuzes leiden. De eenvoudigste wijze om deze discussiete laten plaatsvinden is door fysiek aanwezig te zijn in het project en discussies aan te moedigen. Door deze aanpak werd al vroeg in de bouwfase van www.rabobank.nl duidelijk dat er in een pilot een misser was geslopen. Dat was tijdig genoeg om zonder veel verlies van code een nieuwe route in te slaan. Verassingen blijven... In de beginfase van het www.rabobank.nl-project zijn in overleg tussen architecten en productmanagement schattingen gemaakt over het jaarlijkse exploitatiebudget. Acht maanden verder in het project , vlak voor exploitatie blijkt deze budgetinschatting correct te zijn met een afwijking van 4% ten opzichte van de originele schatting. (Working paper Series, Universiteit van Amsterdam, Mr. Meint Post, Jan Truijens, Oktober 2005)

De Menselijke maat in Informatie Architectuur

Dit onderwerp is door vele auteurs beschreven en daarom interessant om te bekijken welke exacte betekenissen de verschillende auteurs voor gerelateerde begrippen er op na houden. Hier volgen een aantal korte samenvattingen van een aantal artikelen, gevolgd door een begrippenlijst met hierbij de gehanteerde betekenissen van dit begrip.

De menselijke maat door architectuur, Rob Kruijk: HP Services. 20 september, 2002.

Volgens Kruijk voegt de mens zich naar de informatievoorziening in de ICT en wordt het tijd dat dit eens andersom wordt. De menselijke maat wordt volgens hem op deze manier uit het oog verloren, doordat de ‘technology push’ de drijvende kracht is achter de ontwikkelingen in de ICT. Het intreden van een nieuw ‘tijdperk’, zoals nu dus het informatietijdperk gaat volgens Kruijk is vier fases. In de eerste fase is daar de technologische impuls, een nieuwe techniek doet zich aan. Hierop volgt de fase waarin de infrastructuur verandert, zodat deze nieuwe technologie tot zijn recht komt. In de derde fase, de fase van de business transformatie, gaat de vrije markt gebruik maken van de technologie. In de laatste fase vindt pas de sociale transformatie plaats. De mensen wennen aan het nieuwe tijdperk. Door deze grote verandering is het mogelijk dat de menselijke maat overschreden wordt en het is belangrijk dit dus in de gaten te houden. In het informatietijdperk uit dit zich in de afbreuk van privacy, schaalvergroting en fraudering. Kruijk stelt dat we op dit moment in de overgang van fase 2 naar fase 3 zitten, met de beginselen van fase 4 als extra trekkende kracht. Architectuur zou de menselijke maat in de gaten moeten houden en zou het herstel van de menselijke maat in kunnen luiden. Architecten moeten dan rekening gaan houden met de belangen, de aanwezige kennis en kunde en de wensen van alle betrokkenen. De architectuur biedt maat door beheersbaarheid van granulariteit. Dit maakt beslissingen door de tijd heen transparanter. Voor ieder van de vier fasen wijst Kruijk hoofdverantwoordelijken aan. Voor de laatste fase, de sociale transformatie zijn dit de filosofen. Hij stelt daarom dat het belangrijk is dat ieder werkzaam in de ICT de situatie een beetje als filosoof zou moeten kunnen benaderen.

Granulariteit

De letterlijke betekenis van granulair is korrelig. Met granulariteit in de architectuur wordt bedoeld dat er van grof naar fijn wordt gewerkt, dat wil zeggen, eerst de grote lijnen, dan de details. Door te werken met beheersbaarheid van de granulariteit, biedt de architectuur maat, want er ontstaat een vermogen om beslissingen transparanter te maken, ook door de tijd heen.

Menselijke maat

De menselijke maat heeft te maken met de emotie – vreugde, verdriet, medelijden, trots, woede, verveling, eerzucht, hebzucht, haat, schaamte, etc. Al deze emoties hebben recht van bestaan, als ze ten minste maat houden. Maar uit zichzelf zijn ze tiranniek en willen een hele situatie beheersen. Discipline is een nuttig hulpmiddel tegen de mateloosheid. Het helpt maat te houden en de innerlijke rust en orde te herstellen en te bewaren als we onder invloed van emoties uit het evenwicht zijn geraakt. Toegepast op de ICT levert dat een aantal knelpunten op. Zo is het in veel gevallen nog zo dat de mens zich moet schikken naar de ICT en niet omgekeerd. Er is nog steeds moeite van te voren in te schatten wat een ICT project gaat kosten en hoeveel tijd het kost. De schittering van te techniek leidt te veel af van datgene waar het omdraait: Wat moet het doen en waarom? En tot slot is er nog geen goed inzicht in de afhankelijkheden tussen business en ICT.

Architectuur

Architectuur is in de ICT een instrument om d.m.v. ordening alle betrokkenen het hunne te geven en het gebruik hiervan kan een rol spelen bij het hanteren van de menselijke maat. Deze ordening kan aangebracht worden door een duidelijke scope af te bakenen, te werken met granulariteit, verschillende invalshoeken te beschouwen, principes op te stellen als uitgangspunt en door een communicatie-instrument te creëren voor complexe zaken en als opslagplaats van hoogwaardige kennis. Dit alles valt onder het begrip ‘architectuur’, toegepast op de ICT. Architectuur bestaat dus uit principes, modellen en standaards. Dit geeft de mogelijkheid om in het spanningsveld van de ICT op een redelijke manier met elkaar om te gaan. De methodiek van de architectuur wordt beheerst door architecten.

Architect

De architect is de belangrijkste schakel voor de Business transformatie. Voor deze transformatie is naast de technische integratie, ook de business integratie een noodzakelijke voorwaarde en hiervoor is de architect nodig. De architect staat voor conceptuele integriteit van begin tot einde, van idee tot de gerealiseerde vruchten van de oplossing. De architect is de agent van de sponsor van het ICT-project, hij modelleert de behoeften van de gebruikers, geeft constructieprincipes over aan de bouwers en heeft de verantwoordelijkheid zijn creatieve oor te luister te leggen bij de exploitant wanneer dit nodig is.

De opgave van de IT-architect, Gerrit Muller et al.: Werkgroep “Menselijke maat in IT”. 2004.

In dit artikel wordt uitgelegd van welk hout de hedendaagse IT-architect gesneden moet zijn. De IT-architect vervult een belangrijke rol bij het ontwerp van IT-oplossingen en onderscheid zich van andere IT-ers. In dit artikel wordt benadrukt dat hij in zowel de wereld van de mens als de wereld van de techniek thuis moet zijn. Inzicht in enerzijds wat willen mensen, welke relatie hebben ze met het systeem en anderzijds welke technieken zijn er voorhanden, zodat hij hier in zijn oplossing optimaal gebruik van kan maken. De vereiste eigenschappen van een goede IT-architect zijn daarom tweeledig: Ervaring op het gebied van bedrijfsprocessen en het bezit van een aantal persoonlijke vaardigheden. Volgens Muller et al. Heeft de ervaring hierin nog vaak een te hoge prioriteit en zijn juist die persoonlijke vaardigheden van doorslaggevend belang voor succes.

IT-oplossing

Een IT-oplossing is een technische toepassing die een oplossing voor een probleem uit de wereld moet zijn. Vanuit de wereld ontstaat er een vraag voor een oplossing van een probleem. Requirements Engineers brengen dit probleem zo goed mogelijk in kaart, waarna de IT-architect een IT- architectuur zal bedenken die dit probleem op kan lossen. Applicatiespecialisten zullen dit ontwerp in technische zin creëren. Het product dat dit uiteindelijk oplevert, noemt men de IT-oplossing.

IT-architect

Een IT-architect is diegene die op zoek gaat naar passende IT-oplossing voor allerhande problemen die in de wereld voorkomen om zo het resultaat te behalen dat mensen met behulp van deze IT-oplossing het probleem willen oplossen. Hij moet enerzijds een goed gevoel hebben voor wat de mensen wensen te krijgen en anderzijds inzicht hebben in de technieken die voor handen zijn, zodat hij de optimale IT-oplossing aan die mensen kan geven. Dit kan wanneer hij beschikt over brede ervaring op het gebied van bedrijfsprocessen, bedrijfscultuur, informatietechnologie, methoden en technieken, en persoonlijke vaardigheden als communicatieve vaardigheid, analytische vermogen en inlevingsvermogen. De IT-architect kan weer ingedeeld worden in subcategorieën, aflopend van dicht bij de mens naar dicht op de techniek: business-, informatie-, applicatie- en infrastructuurarchitect.

Gebruikersbeleving en de menselijke maat in ICT, Hans Oesterholt-Dijkema. 2007.

Oesterholt-Dijkema legt een actueel probleem voor, dat bij de Nederlandse Belastingdienst op het moment speelt. De belastingdienst heeft steeds meer taken erbij gekregen en heeft steeds meer moeite om in de veranderende context ICT projecten tot een kwalitatief goed einde te brengen. En dat terwijl het steeds duidelijker wordt dat het voor de medewerkers steeds moeilijker wordt om zonder ICT de toenemende complexiteit te behappen. In dit artikel oppert hij een tweetal onderzoeksvragen, dat interessant zou zijn om uit te voeren. Hoe kan de menselijke maat worden gewaarborgd in bij toenemende samenhang en integratie van de ICT en in wat voor manier zou ICT ontwikkeld moeten worden om dit probleem op te lossen? Hoe dit te onderzoeken is laat hij in het midden.

ICT

Bij ICT gaat het in beginsel om het begrip van zaken krijgen. Hoe werken processen, welke begrippen worden gehanteerd en welke wetgeving? Deze begrippen worden gebruikt om ICT-ondersteuning te ontwikkelen met als doel het handelen van gebruikers te ondersteunen. Tijdens deze ontwikkeling worden de processen, begrippen en wetgeving uitgeprogrammeerd. Door het belang van samenhang wordt het steeds belangrijker voor mensen om niet alleen hun eigen deel te begrijpen, maar over de grenzen van hun domein heen te kijken. Door alles met elkaar te verbinden wordt de wereld wel complexer. De ICT, als geabstraheerde spiegel van de wereld zal deze complexiteit moeten weerspiegelen en dat maakt de gebruikersbeleving essentieel.

Gebruikersbeleving

Voor een goede gebruikersbeleving moet de menselijke maat worden gewaarborgd.

Virtueel informatienetwerk

Een netwerk waar mensen en organisaties deel van uit maken, waarbij iedereen verantwoordelijk is voor een deel van het geheel. Een voorbeeld hiervan wordt gecreëerd door de Nederlandse overheid. Zij sturen er op aan d.m.v. de DigiD, dat verschillende overheidsorganisaties geen eigen basisregistraties kunnen bijhouden, maar de informatie moeten ophalen bij de bron. Dit levert een complexe samenhang op, waar moeilijk in te werken valt.

‘De menselijke maat’ – software ontwikkeling in breder perspectief, Erik Philippus. 2005.

Philippus richt zich op drie verschillende betekenissen van maat. Maat als grootheid waarmee je iets kan meten, maat als ritme zoals in de muziek en maat in de betekenis van vriend. Deze drie betekenissen zijn volgens hem samengevoegd tot de menselijke maat, zoals die zijn invloeden heeft op de software ontwikkeling. Niet alleen de eindgebruikers, maar ook ontwikkelteams hebben te maken met de menselijke maat. Natuurlijk is de basis voor een software product of dienst altijd het vakmanschap van de makers, maar de praktijk leert dat een uitstekende technische oplossing geen garantie is voor een succesvol ontwikkeltraject. Uiteraard zal het onderkennen van de relevantie van de menselijke maat die garantie ook niet geven, maar het zal het succesvol afronden van een software project zeker dichterbij brengen, zo stelt Philippus. De menselijke maat blijkt vooral naar voren te komen in de samenhang tussen software architectuur en product kwaliteit. De software architect speelt een belangrijke rol in het ‘vertalen’ van de menselijke maat in belangrijke architecturale beslissingen (en vice versa), en heeft daarnaast ook een invloedrijke positie in de aansturing van het ontwikkelteam en de contacten met de diverse stakeholders. Overigens is daarmee niet gezegd dat het vraagstuk van de menselijke maat alleen op het bord van de architect zou liggen. Ook haalt Philippus het VRAPS-model aan, dat een brug slaat tussen de wereld van de techniek en invloedrijke procesmatige en organisatorische aspecten. Het model geeft een praktisch handvat om de menselijke maat een plek te kunnen geven in het ontwikkelproces. Een software ontwikkeltraject dat de menselijke aspecten in acht neemt is een belangrijke voorwaarde om tot een eindproduct te komen waarvan de gebruikers het gevoel hebben dat het op de menselijke maat geschoeid is.

Menselijke maat</b>

Menselijke maat in software ontwikkeling is er om zoveel mogelijk tegemoet te komen aan de wensen van de opdrachtgever en de verwachtingen van de gebruikers. Heden ten dage kennen we drie voor de hand liggende betekenissen voor het woord maat: afmeting, ritme en vriend. Voor een hoge kwaliteit software, zijn al deze drie betekenissen van belang. Deze verschillende betekenissen wijzen op een relatie tussen de menselijke maat en kwaliteit.

Software architectuur

Software architectuur is een bruikbare invalshoek om de invloed van menselijke maat te onderkennen en mee te nemen in het software ontwikkelproces, met als doel tot een gunstigere prijs/prestatie verhouding te komen. Het vergelijk van software architectuur met het begrip architectuur uit de bouwwereld kan in sommige gevallen verhelderend werken. Een viertal aspecten waaraan zij moeten voldoen is gelijk: Functioneel, stevig, orde en harmonie en schoonheid. Die laatste lijkt op het eerst oog geen hoge prioriteit te hebben, zoals in de bouwwereld, maar er wordt gesteld dat wanneer de eerste drie aspecten genoemd goed met elkaar in balans is, en wanneer je kunt spreken van het hierdoor tot uitdrukking laten komen van een hoger ideaal, de schoonheid ontstaat.

Kwaliteit in software

Kwaliteit ontstaat niet uit zichzelf of iets dat vlak voor de release aan de software toegevoegd kan worden. Uiteindelijk zijn het de mensen in het project die bepalend zijn voor de kwaliteit van het eindproduct. Hun afwegingen en beslissingen, hun kennis, vakmanschap en gereedschap, maar ook de wijze van samenwerking en communicatie vormen de basis voor het behalen van de vereiste kwaliteit. De ervaring leert dat er een scala aan factoren is, die invloed heeft op het welslagen van een softwareproject en het zijn niet alleen rationele en technische factoren die hierbij maatgevend zijn.

Software architect

De rol van de software architect is bepalend voor het tot uitdrukking komen van de menselijke maat in zowel het ontwikkeltraject als het product. Een architect dient hiervoor te participeren op een niveau dat verder gaat dan alleen het uitvoerende werk. Net als in de bouwwereld zal de architect een andere rol vervullen dan de aannemer. De architect werkt niet alleen met mensen maar ook voor mensen. De software architect behoort betrokken te worden bij het maken van afwegingen tussen vernieuwingen en kwaliteit wanneer afnemers met onverwachte eisen komen. De architect dient hierom communicatief vaardig te zijn. Hij moet in staat zijn om in een constructieve relatie met alle belanghebbenden organisatorische en procesmatige aspecten mee te wegen in belangrijke architecturale beslissingen. Dit doet een beroep op de kunst van het luisteren.

VRAPS-model

Het VRAPS(Visie, Ritme, Anticipatie, Partnering, Simplificatie)-model bevat met elkaar samenhangende principes, die een indicatie geven of een organisatie in staat is om onderarchitectuur software te kunnen bouwen. Deze principes worden duidelijk gemaakt door middel van een groot aantal herkenbare patterns en anti-patterns. Het model geeft een kapstok voor het zichtbaar maken van de interactie tussen een technische architectuur, de processen gebruikt voor de ontwikkeling en het onderhoud ervan, en de invloed van allerlei eigenschappen van het ontwikkelteam en de organisatie. Deze communicatie over en weer maakt nog eens te meer duidelijk, dat een architect in staat moet zijn om zowel technische als sociale complexiteit te hanteren.

Enterprise Architecture

Enterprise Architecture (EA) kan men kunnen uitleggen als business/IT-alginment. Het heeft dan ook een duidelijke rol binnen digitale architectuur, met name op het het gebied van strategische beslissingen en conceptuele analyses. EA draait dan ook om zaken als lagen (business, applicatie etc.), concepten enz. De kennis uit de teksten wordt gebracht als samenvattingen omdat de dit het beste past bij de aard van de teksten.

De kracht van Enterprise Architectuur

Bron:
Via Nova Arhcitectura (http://www.via-nova-architectura.org/magazine/magazine/de-kracht-van-enterprise-architectuur.html)
Datum publicatie:
maart 2007
Auteurs:
Dr. Ir. Henry M. Franken, Partner BiZZdesign
Dr. Harmen van den Berg, Partner BiZZdesign
Dr. ir. Harm Bakker, Hoofd tooolontwikkeling BiZZdesign
Drs. Remco Blom, Consultant BPM en EA BiZZdesign

Samenvatting

Waarom enterpise architectuur?
Waarom krijgt Enterprise Architectuur (EA) zoveel aandacht?

• Organisaties blijken steeds meer moeite te hebben om slagvaardig te veranderen omdat “alles met elkaar verbonden is”. Inzicht in die samenhang ontbreekt.
• Organisaties zijn zoekende naar een verantwoordelijke manier om het gedeeltelijk overlappende applicatielandschap te rationaliseren.
• Investeringen in nieuwe IT zijn moeilijk te motiveren omdat alignement met de business zoek is en het positieve effect op de strategie en bedrijfsvoering niet kan worden aangetoond.
• ‘Geoutsourceste’ processen blijken in de praktijk moeilijk aanstuurbaar. De knip blijkt over meerdere bedrijfs- en IT-aspecten te liggen, met bedrijfsprocessen als primaire schakelpunt, dit leidt tot onduidelijkheid. Inzicht en beheersing ontbreekt.
• De zoektocht en implementatie van Service Oriented Architecture (SOA).

Organisaties zoeken naar richtlijnen, principes en hulpmiddelen om dit soort vraagstukken te helpen oplossen.
Hiervoor zijn bedoeld:

• EA voor het niveau van het richten van de organisatie en de beoogde veranderingen.
• Business Process Improvement en Management op het inrichten, implementeren en besturen van de bedrijfsvoering.

Veranderprogramma’s
Veranderprogramma’s, welke vaak complex veranderingen aansturen, zijn gebaat bij een blauwdruk van de bedrijfsplanologie met bijbehorende principes en richtlijnen. Deze “blauwdruk” geeft de streefsituatie weer van de meest essentiële bedrijfsaspecten in fases in de tijd. Het is vaak een lange-termijn ambitie van strategie, processen, structuren en IT waarbinnen kortere termijn projecten dienen te passen. Principes en richtlijnen zijn leidend. Het op deze manier planologisch omgaan met veranderingen wordt ook wel architectuurdenken genoemd. Architecturen doen uitspraken over wat al dan niet gewenst is en leggen deze uitspraken vast in modellen, kaders & randvoorwaarden en principes & richtlijnen. Dergelijke architecturen worden zowel voor de (middel)lange termijn als voor de kortere termijn opgesteld. Veranderingen in organisaties krijgen in belangrijke mate vorm door veranderingen in bedrijfsprocessen, hierbij dienen architecturen een bepalende rol te spelen. Business Process Improvement en Management gaat over het doelgericht ontwerpen, verbeteren en inrichten van bedrijfsprocessen en –systemen, mede op basis van architecturen.

Van EA tot procesmanagement
Bij veranderen spelen verschillende architectuurdomeinen een rol, mede ook afhankelijk van het belang dat gehecht wordt aan een bepaald aspect van de organisatie. Sommige van deze domeinen lenen zich goed voor weergave in termen van modellen (overzichten van applicaties, processen, infrastructuur), in andere domein gaat het (naast modellen) ook over uitgangspunten, architectuurprincipes en architectuurrichtlijnen die gehanteerd moeten worden.
Veranderen en ontwikkelen onder architectuur werkt als een drietrapsraket die structuur geeft aan het ontwerptraject: richten, inrichten en verrichten. Architecturen zijn de koersbepalend op elk niveau.

• Richten, concretiseren van de bedrijfs- en IT-strategie en Kritieke Succes Factoren en het bepalen van acties om deze strategie te implementeren. EA kan hiermee bijdragen door het afwegen van de impacts-of-change en analyseren van de alignement van de bedrijfs- en IT-strategie, en het meegeven van kaders en richtlijnen voor de inrichting van de organisatie vanuit de globale waardeketen kan de strategieconcretisatie en implementatie plaatsvinden.
• Inrichten, ontwerpen van de bedrijfsvoering binnen de gestelde architectuurkaders, met behulp van modellen waarin op verschillende niveaus van detail (processen, deelprocessen, procedures) het ontwerp van de bedrijfsvoering staat beschreven. Met deze modellen kunnen analyses worden uitgevoerd op key performance en risk indicators en waarmee verbetervoorstellen kunnen worden voorbereid. Deze voorstellen leiden tot change management en implementatiemanagement.
• Verrichten, betreft het uitvoeren van processen en procesmanagement.

De implementatie vindt van boven naar beneden plaats. Vanuit richten worden kaders en richtlijnen meegegeven. Vanuit inrichting worden concrete ontwerpen meegegeven. Uiteraard is controle op de verandering ook van belang. Architectuurgezichtspunten

(de verdere inhoud van deze paragraaf is vooral te vinden onder de kop Begrippen)

Visualisatie van samenhang
Om communicatie, planning en besluitvorming daadwerkelijk vorm te geven is inzicht in en visualisatie van de samenhang van groot belang.

Begrippen

• Architectuur

Architectuur ontstaan in een afweging van belangen (concerns) van allerlei belanghebbenden (stakeholders).

• Gezichtspunt

Een architectuurgezichtspunt past bij de belangen van een belanghebbende, die vaak een bepaald bedrijfsdomein of een aspect vertegenwoordig en daarin een regierol voert. Een gezichtspunt beschrijft welke architectuurdomeinen relevant zijn voor de betreffende belanghebbende, en hoe deze gevisualiseerd dienen te worden. Een gezichtspunt kan betrekking hebben op één architectuurdomein of op een dwarsdoorsnede door meerdere domeinen ten aanzien van een bepaald aspect.

• Views

Door vanuit een gezichtspunt naar de EA te kijken ontstaan zogenaamde views, visualisaties van (een deel van) de architectuur conform een gezichtspunt.

• Enterprise Architecture

Een EA is een samenhangende beschrijving van onder meer producten, diensten, processen, organisatie, gegevens, applicaties en technologie, met achterliggende uitgangspunten en principes. In een EA worden bedrijfsaspecten (missie, doelstellingen en strategie, product, bedrijfsobjecten, organisatie , proces) en IT-aspecten (applicaties, technologie, gegevens) geïntegreerd.

Ook al zijn views en architectuurmodellen gescheiden naar domeinen en dwarsdoorsneden, deze hebben toch duidelijk onderlinge relaties, en de resultaten dienen in samenhang te worden gepresenteerd. Alleen op een geheel van de analyse en impact-of-change op alle domeinen kan men besluiten nemen. De gezichtspunten op basis van domeinen en/of eventuele dwarsdoorsneden dienen belangrijk genoeg te zijn om onafhankelijk van andere gezichtspunten te worden beheerst en beheerd. De (in de tijd gefaseerde plateau’s van deze) architecturen zijn richtinggevend in de 'verbeteringslevenscycli' van de bedrijfsvoering. De architecturen zijn mede bepalend voor wat mogelijk is in lijn met de strategie, missie en doelstellingen van het bedrijf, geven duidelijk de relatie met afgesproken ontwerpprincipes weer en bepalen voor een belangrijk deel ook hoe de impact-of-change kan worde ingeschat en gemanaged. De auteurs onderscheiden de volgende domeinen:

• Producten en diensten
• Bedrijfsfuncties (w.o. klantgroepen en kanalen)
• Processen
• Organisaties en rollen
• Gegevens
• Applicaties en systemen
• Technologie
• Doelstellingen, principes en richtlijnen
• Programma’s en projecten

Eenvoud is een complexe zaak - Architectuur en de beheersing van complexiteit

Bron
Via Nova Architectura (http://www.via-nova-architectura.org/magazine/reviewed/eenvoud-is-een-complexe-zaak-architectuur-en-de-beheersing-van-complex.html)

Datum
oktober 2006

Auteur(s)
Serge Bouwens

Samenvatting

Een opmerking vooraf
Deze tekst is niet exclusief gerelateerd aan digitale architectuur, maar complexiteit en de beheersing hiervan is een kerngedachte van digitale architectuur.

Complexiteit is een groot probleem voor organisaties, een business probleem wel te verstaan. En de complexiteit neemt alsmaar toe met een omgeving waarin alsmaar meer klanten, regels, relaties, uitzonderingen enz. komen.

Complexiteit en architectuur
Vaak wordt complexiteit pas opgemerkt als het al reeds te laat is, als men het overzicht al kwijt is. Architecten moeten een idee hebben van het soort probleem welke ze in handen hebben. Is het een zogenaamd ‘gemeen’ probleem, waarvan je pas achteraf weet of de oplossing echt werkt, of is het een ‘tam’ probleem. Complexiteit wordt veroorzaakt door drie dingen: de aard van het probleem, de aard van de oplossing en de aard van de organisatie die ermee kampt. Het oplossen van complexiteit is hiermee ook een sociaal proces. Om op een effectieve manier met (organisatorische of architectuur) problemen om te kunnen gaan is het belangrijk te kunnen analyseren waar de complexiteit uit voort komt. Er bestaat dan ook een behoefte aan tools en technieken om analyse te ondersteunen.

Architecten zijn goed in abstract denken, maar trappen in de vuilkuil het belang van praktische problemen weg te wuiven of over het hoofd te zien, waardoor architectuur bijdraagt aan de complexiteit. Ook hebben zij het overzicht terwijl anderen al reeds de weg kwijt zijn, en daardoor afhaken.

Twee instrumenten om grip te krijgen op de complexiteit zijn architectuurprincipes en patronen.

Architectuurprincipes
Principes zijn een krachtig instrument, zij kunnen vorm geven aan de bedrijfsvisie zonder dat het nodig is om die geheel in modellen uit te werken. Echter de architect moet wel opletten dat de principes niet juist complexiteit in de hand werken en moet weten het principe op het juiste moment los te laten. Zij moeten worden toegepast in een context. Aanvullingen bij de invulling hoeven dan ook niet verkeerd te zijn.

Patronen
Patronen komen bijna altijd gaandeweg bovendrijven of worden gekozen uit een bredere set. Het is de kunst ze zo vroeg mogelijk als essentieel te herkenen. Hiervoor moet men niet zozeer naar de specifieke situatie kijken maar naar patronen welke aangeven hoe men met dergelijke complexiteit om kan gaan.

Problemen hebben vaak een onderliggende structuur welke een hoge mate van overeenkomst vertoont met andere gelijksoortige problemen.

De auteur onderkent verschillende basispatronen om met complexiteit om te gaan, namelijk:

• Meer (uniformeren en ordenen)
• Minder (abstraheren (weglaten van niet relevante informatie), delegeren, afbakenen , faseren, stoppen)
• Anders (paradigma veranderen (fundamentele veranderingen van hoe we het probleem zien), taak veranderen)

De auteur merkt op dat complexiteit vaker verplaatst dan dat het verdwijnt. Het is daarom van belang te weten waar de complexiteit de bedrijfsdoelstellingen het meest frustreert.

De auteur benadrukt dat complexiteit niet ten alle tijden vermeden moet worden, maar wel dat een oriëntatie op kosten of effectiviteit niet de juiste focus is.

The Systemic Enterprise Architecture Methodology (SEAM)

Bron
http://citeseer.ist.psu.edu/cache/papers/cs/31226/http:zSzzSzicwww.epfl.chzSzpublicationszSzdocumentszSzIC_TECH_REPORT_200265.pdf/wegmann03systemic.pdf

Datum
Onbekend

Auteur(s)
Prof. Alain Wegmann

Samenvatting

1 Introductie
Met SEAM wil het team achter het ‘initiatief’ EA volwassenen maken. Het huidige gebruik van EA leunt op het gebruik van patronen (patterns), welke voortkomen uit de ervaringen welke de architect in zijn of haar eerdere projecten heeft opgedaan, maar een verdere theoretische basis ontbreekt.

2 EA en zijn uitdagingen
EA is volgens de auteur de discipline die draait om de organisatie van bedrijfsmiddelen. Het doel van een EA project is het definiëren en implementeren van strategieën die de organisatie sturen in haar evolutie. EA projecten hebben te maken met de organisatie in al haar aspecten. Het team achter een dergelijk project is dan ook multidisciplinair. De architect bindt de resultaten van de andere teamleden (de specialisten). Het verschil tussen EA projecten en andersoortige multidisciplinaire projecten is dat bij de andersoortige projecten de specialisten eigen modellen gebruiken en dat maakt het lastig te controleren of het project leidt tot een geïntegreerde oplossing. De oplossingen van verschillende gaten in verschillende lagen kunnen niet los van elkaar staan (zie ook de definities onderaan deze samenvatting), het gaat immers om dezelfde onderneming. Bovendien kunnen oplossingen in één laag dus ook gevolgen hebben voor andere lagen. De in één level te kiezen oplossingen, moet uitvoerbaar en praktisch zijn en bijdragen aan het gemeenschappelijke doel van de onderneming. Er zijn drie belangrijke problemen die de auteur en zijn team heeft gevonden in de praktijk: het is lastig om in de EA frameworks de tracebility (verbindingen) tussen de verschillende levels vast te leggen en te onderhouden, waardoor deze frameworks lastig te onderwijzen en gebruiken zijn, er zijn geen tools beschikbaar voor het gebruik van EA en tenslotte is het lastig een aansluiting te vinden met het veelgebruikte UML, waardoor de specialisten (ook business, waar UML steeds meer gebruikt wordt) EA eerder links laten liggen.

3 Systemic paradigma & SEAM paradigma
3.1 SEAM filosofie
3.1.1 SEAM Epistemologie
De auteur typeert een enterprise als een systeem in welke de componenten de bedrijfsmiddelen zijn. Hierdoor kan EA verankert worden op de systeem wetenschap, welke de theoretische basis biedt voor SEAM. Hierdoor kunnen systemen worden ingedeeld in gecompliceerde systemen en complexe systemen (zie definities onderaan deze samenvatting). De uitdaging van EA is het samen bestaan van deze twee verschillende systemen. De rest van dit hoofdstuk licht SEAM toe, te beginnen met de SEAM epistemologie. Epistemologie is de studie van de natuur van kennis en rechtvaardiging. Epistemologie definieert de epistemologie principes welke bruikbaar zijn voor het begrijpen van de relatie tussen realiteit en het model. Een van de belangrijkste principes is dat kennis relatief is aan de waarnemer, en dus ook de kennis over de realiteit. Dit rechtvaardigt ook het onderkennen van verschillende lagen binnen SEAM, specialisten hebben een verschillende blik op systemen ontwikkeld om deze te kunnen bevatten. Overigens wordt opgemerkt dat het vaak nuttig is meer realiteitslagen te onderscheiden.

3.1.2 SEAM Ontologie
Ontologie definieert, in computer wetenschappen, een set van concepten en hun relaties. De ontologie die SEAM gebruikt is gebaseerd op RM-ODP, welke geformaliseerd is in de een specificatie taal welke Alloy heet. De model elementen worden gedefinieerd door twee karakteristieken: de basis modellering karakteristieken (object, actie, status, locatie in tijd, locatie in ruimte) en twee specificatie karakteristieken (type en instantie). Dit samen definieert het model element. Het bestaan van deze ontologie maakt het mogelijk ieder systeem te modeleren, en een CAD-tool te ontwikkelen om het gebruik van deze taal te ondersteunen.

3.1.3 SEAM Ethiek
Er zijn verschillende blikken mogelijk op een realiteit. Het resulteerde model, welke volgt uit de analyse van de realiteit, kan dus ook verschillenen van een model welke voortkomt uit een andere analyse. Men zal moeten kiezen. Dit is weliswaar niet formeel vast te leggen, maar door de ethiek toch te benoemen onderscheid men duidelijk wat formeel is en wat subjectief. En het vangt ook de fundamentele business en sociale waarden van de onderneming, waarden die het project beïnvloeden.

3.2 SEAM Methode
SEAM staat een iteratieve methode voor, dit omdat een bedrijf continue verandert. Dit maakt het mogelijk het model aan te passen aan de veranderingen en maakt het voor hen mogelijk het model te testen en valideren op echte mensen in de omgeving. De interacties hebben drie soorten van ontwikkel activiteiten:

• Multi-laag modeleren

Het maken van een nieuwe model van de organisatie of het aanpassen van een bestaand model van de organisatie. Het is belangrijk dat de teamleden regelmatig afspreken welke organisatorische lagen gebruikt worden. Hiermee wordt ook gekozen voor een gezamenlijke blik op doelen, processen en infrastructuur.

• Muilti-laag ontwerp

Hier wordt het geconstateerde gat opgelost. Hierbij worden daarmee nieuwe processen en bedrijfsmodellen ontwikkelen en ingezet.

• Multi-laag inzet

In deze interactie stap wordt de organisatorische lagen zoals beschreven in de to-be situatie omgezet in artefacten die kunnen worden begrepen , door mens of computers. Deze artefacten kunnen plannen zijn of dingen die direct kunnen worden uitgevoerd. Dit wil echter nog niet zeggen dat de artefacten ook zullen worden gebruikt in de praktijk, mensen in organisatie kunnen besluiten deze ‘links’ te laten liggen. Daarom worden dit soort motivatie punten expliciet meegenomen worden in het organisatiemodel.

Deze interacties kunnen zowel sequentieel als parallel uitgevoerd worden.

4 Case studie en 5 conclusie Deze zijn niet opgenomen in de samenvatting om de samenvatting compact te houden. Ik verwijs u hiervoor dan ook door naar de orginele tekst.

Begrippen

• EA model

Model om te redeneren en te communiceren. Representeert de bedrijfsmiddelen welke gevonden zijn in het bedrijf en haar omgeving, samen met de processen waarin deze participeren, welke relevant zijn voor het betreffende project. Het is gestructureerd in organisatorische lagen.

• Organisatorische laag

Is een onderdeel van een organisatie model welke de organisatie beschrijft vanuit de viewpoint van één of meer specialisten. Traditioneel beschouwen EA methoden drie organisatorische lagen: business laag (de organisatie en haar partners), operationele laag (de mensen en systemen waaruit de organisatie bestaat) en het technologie laag (de technische infrastructuur waaruit de systemen bestaan). Elke laag beschrijft ofwel wat het is (as-is) of wat het zou moeten zijn (to-be). De lagen zijn verbonden, zo kunnen resources verschillende rollen spelen in de diverse lagen. De business laag geeft doorgaans de doelen aan, de operationele en technologische laag hoe dit bereikt wordt.

• Tracebility

Is de mogelijkheid tot het expliciet maken van de relaties tussen gerelateerde model elementen. De auteur noemt dit begrip essentieel, omdat het begrip het EA team mogelijk maak te benoemen hoe de integratie tussen de lagen wordt gerealiseerd.

• EA methoden

Definiëren de ontwikkel activiteiten in een EA project.

• Gap (gat)

Wat veranderd moet worden om van de as-is situatie te komen tot de to-be situatie.

• Framework

Biedt richtlijnen hoe het EA model te maken.

• Systeem

Een set componenten welke interacties hebben.

• Gecompliceerde en complexe systemen

Systemen waar het gedrag van kan worden voorspeld door het analyseren van de interactie van de componenten. Het zijn deterministische systemen, een typisch voorbeeld is een computer. Complexe systemen zijn systemen waarvan het gedrag niet kan worden voorspeld door een dergelijke analyse en zijn non-deterministisch. Systemen met mensen zijn typische complexe systemen.

Towards a Language for Coherent Enterprise Architecture Description

Bron
Volgende tekst te verkrijgen via Web of Knowledge

Datum:
2003

Auteurs:
Zie de originele tekst, deze lijst is namelijk erg groot van omvang.

Samenvatting

Abstract
De voordelen van een coherente beschrijving van architectuur:

• Biedt inzicht
• Maakt communicatie tussen verschillende belanghebbenden mogelijk
• Stuurt complexe veranderingsprocessen

Er bestaat echter nog geen taal voor architectuur beschrijving welke mensen volledig in staat stelt geïntegreerde enterprise modellen te produceren. In deze paper focussen de auteurs op de vereisten van en het ontwerp van een dergelijke taal.

1 Introductie
Architecten hebben instrumenten nodig om op uniforme wijze architecturen te produceren. Er zijn nu voor alle domeinen die onderscheiden worden afzonderlijke technieken.

Belangrijke elementen van een dergelijk poging omvatten:

• De ontwikkeling van een coherente enterprise modeleertaal

Dit kan Babylonische verwarring voorkomen.

• De taal moet de ontwikkeling van gespecialiseerde views en visualisatie technieken toestaan om inzicht te bieden aan de verschillende stakeholders

Er moeten views worden ontwikkeld welke afgestemd zijn op de specifieke stakeholder, immers architecturen zijn de concepten met welke de architect communiceert met de stakeholders.

• De ontwikkeling van analyse technieken die helpen in het begrijpen van de complexe modellen

Dit biedt de mogelijkheid de eigenschappen van een geïntegreerd model tot in details te bestuderen, en het vereiste inzicht en overzicht te krijgen.

De auteurs erkennen dat er nooit slechts één taal zal bestaan. De flexibiliteit van het gebruik van andere talen wordt mogelijk gemaakt door de specialisatie/generalisatie eis van de taal waar de auteurs een aanzet toe willen maken. Volgens de auteurs vormt de taal de kern van een dergelijke architectuur aanpak. De focus ligt op het identificeren van specifieke relatie concepten en definities van grensoverschrijdende domein relaties.

2 Gerelateerd werk Er zijn talen zowel op het gebied van organisatie en proces modellering alsmede op het gebied van applicatie en technologie modellering. Er is wel een trend gaande de relatie vast te leggen tussen de domein organisatorische processen, informatie systemen en applicaties die deze ondersteunen (business/IT alignement), maar talen om deze relatie echt uit te drukken bestaan nog nauwelijks.

3 Taal vereisten en principes
3.1 Metamodel flexibiliteit
Een centrale uitdaging in de ontwikkeling van een generiek metamodel is het vinden van een balans tussen het specifieke van concepten welke gebruik worden in organisaties en een erg generieke set van architectuur concepten welke een systeem reflecteert als een set van verbonden entiteiten.

Dit heeft geresulteerd in het volgende plaatje:

Het metamodel welke de auteurs voorstellen bevindt zich in de tweede laag, tussen de twee extremen. Deze concepten kunnen worden ingezet voor de beschrijving van de EA van iedere informatie intensieve organisatie, en indien nodig kunnen de concepten verder worden gespecialiseerd of samengevoegd voor meer specifieke contexten. Ook kunnen de concepten worden gebruikt voor de integratie met meer specifieke modellen in andere talen. De concepten in de tweede laag van de piramide zouden kunnen worden gezien als specialisaties of composities van de concepten in de bovenste laag.

3.2 Integratie van heterogene modellen
Zoals reeds gezegd heeft ieder domein zijn eigen talen, technieken enz.. Een van de belangrijkste doelen van het metamodel is het gat te overbruggen tussen deze domeinen door te voorzien in een gemeenschappelijk conceptuele fundering voor architectuur beschrijvingen. Het voorgestelde metamodel dient het op twee manieren mogelijk te maken bestaande talen te integreren:

• Concepten uit andere talen beschrijven in de generieke termen van deze taal, vertalen dus

Voordeel: analyse en visualisatie technieken kunnen worden gebruikt op het gehele model.

• Beschrijvingen in andere talen associëren met de objecten in het metamodel

Voordeel: beschrijvingen van de andere talen kunnen in zijn geheel worden hergebruik, in een vorm die nog steeds herkenbaar is voor de originele ontwerper.

3.3 Meerdere views en visualisaties
Een architectuur beschrijving kan uitgedrukt worden in verschillende views, views die enkel die dingen presenteren die relevant zijn voor de stakeholder. Deze views worden samengesteld uit dezelfde concepten, of een subset daarvan, als welke gebruikt worden voor de beschrijving van de complete architectuur. Ook worden formele definitie en representatie van elkaar gescheiden. De notatie mag dan ook gekozen worden afhankelijk van bijvoorbeeld view of organisatievoorkeuren.

4. Het metamodel 4.1 Framework
Door bestudering van bestaande frameworks en eigen ervaringen zijn de volgende architectuur domeinen onderscheiden:

Product
Producten of diensten die organisatie biedt aan klanten. Organisatie
Actoren en de rollen die zij mogelijk vervullen, samen werkende in processen om producten te leveren. Proces
Beschrijft business processen of business functies welke producten of services bieden. Informatie
Beschrijft informatie die relevant is vanuit een bepaald business perspectief. Data
Beschrijft informatie welke geschikt is voor automatische verwerking. Applicatie
Beschrijft software applicaties welke business processen of functies beschrijven. Technische infrastructuur
Hardware platformen en technische communicatie infrastructuur noodzakelijk om de applicaties te ondersteunen.

Een systeem, in de brede zins des woords, bestaat primair uit een verzameling actoren. Actoren hebben een structuur (kunnen samengesteld zijn uit andere actoren), deze beschrijft de statische eigenschappen van een actor. Actoren vertonen gedrag (behaviour) en wisselen waarschijnlijk informatie uit.

Na de identificatie van deze aspecten, deelt men een systeem op in een business, applicatie en technologie laag (layer). Deze aspecten en lagen vormen samen een framework, zoals te zien is in bovenstaande afbeelding. Voor verdere verduidelijking worden ook de architectuur domeinen weergegeven. Het framework is vooral bedoeld voor het ontwerp van het metamodel. Let op dat het niet mogelijk en ongewenst is concepten, welke de cellen vullen, sterk af te grenzen. Deze linken de lagen en aspecten aan elkaar.

4.2 Relaties
Het doel is de relatie tussen bestaande concepten te beschrijven of het definiëren van specifieke relaties tussen concepten om de gewenste coherentie te bereiken. Inter-domein metamodellen zijn nodig om de relationele concepten tussen twee of meer domeinen te definiëren.

4.3 Concepten en metamodel
Het is de aanname van de auteurs dat, in principe, dezelfde generieke concepten kunnen worden gebruik om structuur, gedrag en informatieve aspecten van systemen in alle drie de lagen, zoals deze beschreven zijn in paragraaf 4.1, te beschrijven. Maar ook laag specifieke concepten zijn waardevol om te definiëren, deze zijn herkenbaar voor de stakeholders maar vooral zijn ze nodig om de relatie tussen lagen specifiek te maken.

Het sterkt komt de relaties tussen lagen naar voren in het gedrag (zie ook de definities).

5 Voorbeeld
Het voorbeeld zal niet worden opgenomen in deze samenvatting, daarvoor verwijs ik u naar de originele tekst.

6 Conclusie en toekomstig werk
Ook deze paragraaf is niet opgenomen in de samenvatting, het betreft vooral herhaling.

Begrippen

• Gedragselement

Unit van gedrag. Diensten kunnen worden geboden of gebruikt door dergelijke elementen. Kan data elementen gebruiken of manipuleren op diverse wijzen.

• Actie

Atomic gedragselement uitgevoerd door een enkele actor.

• Proces

Groepering van losjes gerelateerde acties.

• Functie

Groepering van acties naar bijv. vaardigheden, middelen etc.

• Interactie

Atomic gedragselement uitgevoerd door een meerdere actoren.

• Dienst

Gedrag beschikbaar gemaakt aan de omgeving. Een dienst wordt aangeboden door een gedragselement en kan worden gebruikt door andere gedragselementen. Zijn beschikbaar via rolen/interfaces van een actor, omdat deze (of een component) het gedrag uitvoert.

• Transactie

Groeperingen van interacties met de buitenwereld, met een vooraf gedefinieerd resultaat en met beperkingen op de volgorde waarin de interacties plaatsvinden.

• Evenement

Iets dat gebeurt en dat de buitenwereld kan beïnvloeden.

• Actor/component

Entiteit die in staat is om gedrag uit te voeren.

• Interface

De (logische) locatie waar gedrag van een component kan worden bereikt.

• Rol

Representatie van een collectie van verantwoordelijkheden welke mogelijk kan worden ingevuld door één of meer actoren.

• Collaboratie/Connector

Verbindt rollen en interfaces met respectievelijk actoren en componenten.

• Data object

Representatie van informatie.

Manipulatie van data door een actor gaat altijd gepaard met gedrag.

• Bericht

Data object welke bedoeld voor uitwisseling door actoren. Dit gaat via een dienst.

• Document

Herhalende representatie van data uitgedrukt door middel van een medium.

• Medium

Fysieke entiteit of systeem welke data bevat.

• Informatie

De interpretatie van data zoals waargenomen door een actor.

Er wordt overigens onderscheid gemaakt tussen extern zichtbaar gedrag (diensten) en intern gedrag wat hiervoor nodig is.

Designing an ‘adaptive’ enterprise architecture

Bron
BT Technology Journal Vol. 24 No. 4 (http://proquest.umi.com.proxy.ubn.ru.nl:8080/pqdlink?Ver=1&Exp=12-31-2012&FMT=7&DID=1175650461&RQT=309&cfc=1, inloggen verplicht (bij foutmelding even wachten en browser refreshen))

Datum
oktober 2006

Auteur(s)
M. Wilkionsom (HP software’s Regional Chief Technology Officer)

Samenvatting

1 Introductie & 2 Pad naar een Adaptieve Enterprise
Organisaties staan voor grote uitdagingen en IT zou volgens de auteur te rol van ‘business saviour’ en ‘business enabler’ moeten vervullen. EA vormt voor hem dan ook de kern van de ‘nieuwe IT’. Echter hij ziet dat IT vaak een rem vormt door haar complexiteit. Ook in dit document vormt agility (aanpassingen aan veranderingen, responsief handelen, flexibiliteit en efficiency) het kernonderwerp. De IT afdeling heeft vier doelen welke het moet nastreven: het laten toenemen van de performance, het maximaliseren van het rendement, risico’s reduceren en het vergroten van de agility. Echter slechts 10% van het budget gaat uit naar innovatie. De creatie van een adaptieve enterprise wordt beschreven als een reis waarin technologie, proces en organisatie (mensen)worden ‘aligned’ en veranderd om te voldoen aan de noodzaken van de organisatie op een 'agile' en adaptieve wijze. Hij merkt in deze reis drie fasen van volwassenheid op (in volgorde van onder naar boven): stabiliteit, efficiency en tenslotte agility. Waarbij een bepaalde mate van het niveau gerealiseerd moet zijn voordat men kan doorgroeien naar het volgende niveau.

3 Proces en governance
Ook IT governance wordt aangemerkt als een kritiek onderdeel van de weg naar een adaptieve enterprise. Het zorgt ervoor dat projecten onder controle blijven, het helpt bij het adresseren van veel van de compliance initiatieven, verbeterd IT/business alignment waar het gaat om het ‘wat en waarom’, introduceert het gezamenlijk nemen van beslissingen en de verantwoordelijkheidsstelling in projecten. Doormiddel van alignment, transparantie en verbeterde succes rate kan IT zich ook bewijzen als waardevol (i.p.v. een kostenpost). IT governance vormt een brug tussen organisaties of business units, waar de taal, strategie en doelen gedeeld worden. Om het belang van het vroeg introduceren van IT governance in de transformatie te onderstrepen worden enkele voordelen aangehaald: de ROI is 40% hoger, de winsten 20% hoger, de risico van de operationele prestaties worden verlaagd en investeerders zijn bereid meer te investeren.

4 Organisatie
De veranderingen in de organisatie bieden twee kansen: een verhoogde focus op innovatie om de organisatie te ondersteunen en een kans de organisatie te optimaliseren en kosten te besparen. Een interessante waarneming van de auteur is de veranderende operatie als men verder komt in de stabiliteitsfase, men is minder bezig met ‘fire-fighting’ waardoor er budget vrijkomt voor innovatie.

In de tekst introduceert, of spreekt men, ook over een Program Management Office (PMO) welke een ondersteunende rol speelt. Dit bureau kan helpen bij: project support (naar project managers), project management proces/methodologie (ontwikkelen, implementeren en monitoren van een consistent en gestandaardiseerd proces), training, project management software tools en porfolio management (overzicht op alignment en prioriteitstelling van projecten). De auteur geeft ook een groter overzicht van de processen waarop dit PMO zich op focust, echter wij verwijzen de lezer naar het volledig werk voor een overzicht hiervan. Voordelen van een PMO zijn o.a. dat het een strategische impact kan hebben en een bijdrage aan de business demonstreert, door te tonen dat de projecten aansluiten bij de plannen van de organisatie. Dit verzekerd de (financiële) steun van het hoger management, verbeterd de zichtbaarheid van IT successen en de transparantie van de kosten. En uiteraard zijn de projecten effectiever en worden zij efficiënter uitgevoerd door de ‘diensten’ van het PMO. Aligment zorgt er ook voor dat het in plaats van IT project, business projecten met IT worden. Figuur 3 van het artikel toont hoe de organisatie eruit hoe de business/IT ‘samenwerking’ eruit moet komen te zien:

5 Technologie
HP’s strategie met betrekking tot de Adaptive Enterprise is onderverdeeld in vijf aandachtsgebieden: draai IT als een (service leverende) activiteit, adaptieve infrastructuur, ‘mobile enterprise’ en ‘next generation workplace’, digitaliseren van de enterprise en applicatie services.

6 HP’s ‘adaptive’ enterprise architecture
HP’s ‘adaptive’ enterprise architecture is wat de wat de tekst onderlegt. Als een kernonderdeel van IT governance, EA overspant die aandachtsgebieden, namelijk het managen van de IT business (o.a. risico management, security), service delivery (shared services, SOA) en het service delivery management (o.a. availibility, capaciteit management).

Er is een set van architectuur principes en ontwerpregels (zoals de auteur deze noemt) welke een rol speelt in en tussen deze drie aandachtsgebieden, namelijk:

• Modulariteit (binnen infrastructuur, applicaties en business laag)
• Simplificatie
• Integratie
• Standaardisatie