Enterprisearchitectuur

In de enterprisearchitectuur wordt de middellange-termijnvisie van de organisatie vastgelegd. De enterprisearchitectuur bestaat uit een aantal deelarchitecturen.

De deelarchitecturen van de enterprisearchitectuur.

Bedrijfsarchitectuur

De bedrijfsarchitectuur beschrijft hoe een organisatie zich in de markt wil positioneren: missie, bedrijfsstrategie en -doelstellingen, waardebod (producten en diensten), bedrijfsfuncties, klanten, leveranciers of kanalen. Vaak wordt ook de interne organisatiestructuur op hoofdlijnen beschreven, o.a. in termen van organisatieonderdelen, verantwoordelijkheden, besturing, enz. Allereerst is de bedrijfsarchitectuur van belang om de implementatie van de bijbehorende ICT-technologie continu te relateren aan de bedrijfsdoelstellingen en de business drivers. Dit verhoogt de acceptatie en het draagvlak bij het management. Daarnaast is de bedrijfsarchitectuur relevant omdat hierin de overkoepelende architectuurprincipes worden uitgewerkt: algemeen geldende principe-uitspraken die de business drivers vertalen in richting en kaders voor het vormgeven van de informatievoorziening. Deze architectuurprincipes verklaren de belangrijkste ICT-keuzes vanuit een bedrijfsmatige invalshoek. Tenslotte is de bedrijfsarchitectuur relevant om duidelijkheid te hebben over verantwoordelijkheden binnen de organisatie. Hiertoe wordt een indeling gemaakt in bedrijfsdomeinen: voor de organisatie herkenbare, afgebakende onderdelen die een duidelijke bedrijfsfunctie vervullen. Deze indeling zal in de applicatiearchitectuur gebruikt worden voor het toewijzen van verantwoordelijkheden voor applicaties en dus ook de services van die applicaties.

Procesarchitectuur

Een procesarchitectuur beschrijft de inrichting van de bedrijfsprocessen: processtappen, activiteiten, taken, bedrijfsfuncties, functionarissen, de materialen die nodig zijn voor de uitvoering, waar de uitvoering plaatsvindt, enz. Een procesarchitectuur is belangrijk omdat hiermee gestuurd kan worden op standaardisatie en optimalisatie van de bedrijfsprocessen. Verder is duidelijkheid over het eigenaarschap van de bedrijfsprocessen en de ondersteunende componenten een vereiste. Tenslotte hebben de bedrijfsprocessen een belangrijke invloed op het definiëren van de services en geeft het type proces een eerste indruk voor de geschiktheid van services.

Als een organisatie daadwerkelijk procesgericht wil gaan werken, dan moet dit in de procesarchitectuur concreet worden ingevuld. De eisen die de moderne tijd stelt aan organisaties worden tijdens het opstellen van een procesarchitectuur meegenomen als uitgangspunt bij het eventuele herontwerp van de primaire bedrijfsprocessen.

Informatiearchitectuur

Een informatiearchitectuur beschrijft het globale informatiemodel van de organisatie, met daarin de gespreksonderwerpen uit de business waarover informatie wordt bijgehouden. Dergelijke gespreksonderwerpen noemen we bedrijfsobjecten of ‘business objects’ of ‘information objects’. Naast namen en definities wordt ook vastgelegd wat de samenhang is, welke informatiebehoeften er zijn, hoe eigenaarschap is belegd, enz. Hiermee ontstaat een gemeenschappelijk begrippenkader of definitiestelsel voor de organisatie en dat is uiterst relevant: het standaardiseren van koppelingen tussen applicaties is niet alleen een technisch trucje, maar vergt vooral ook afstemming op het niveau van begrippen en definities (semantiek). Soms wordt dan ook wel van informatie-integratie gesproken.

Bedrijfsobjecten zijn een belangrijk uitgangspunt voor het afbakenen en definiëren van services; een service kan worden gezien als een operatie of methode op een bedrijfsobject. Door de informatiebehoeften van de bedrijfsprocessen af te beelden op de bedrijfsobjecten kan worden geanalyseerd welke services gewenst zijn. Er kan hierbij ook gebruik worden gemaakt van modellen die abstraheren van de procesinrichting, bijvoorbeeld een functiemodel. De inrichtingsonafhankelijke beschrijving die hiermee ontstaat is namelijk in een latere fase een goed uitgangspunt voor stabiele bedrijfsservices. Clustering van samenhangende begrippen is nodig om het geheel beheersbaar te houden. Relevante criteria hierbij zijn onder andere: herkenbaarheid en relevantie voor het bedrijf (isomorfie); zelfstandig bestaansrecht; relatieve autonomie: sterke interne samenhang en zwakke externe koppeling en mate van complexiteit.

Vanuit de bedrijfsprocessen wordt van elk bedrijfsobject de levenscyclus vastgesteld: de zogenaamde toestanden en toestandsovergangen. Tevens worden de belangrijkste bedrijfsregels die van toepassing zijn op het bedrijfsobject gedefinieerd. Deze zijn van belang omdat ze het toegestane gedrag van de services gaan bepalen. De koppeling aan de bedrijfsobjecten heeft als belangrijk voordeel dat de bedrijfsregels slechts één keer gedefinieerd zijn en in een latere fase ook slechts één keer geïmplementeerd hoeven te worden.

Applicatiearchitectuur

Een applicatiearchitectuur is de verbindende schakel tussen een procesarchitectuur en een informatiearchitectuur: deze architectuur beschrijft de gewenste manier waarop de bedrijfsprocessen in hun informatiebehoeften voorzien en geautomatiseerd ondersteund worden door applicaties. In een servicegeoriënteerde informatievoorziening wordt een applicatie voor een eindgebruiker samengesteld uit functionaliteit die ‘onder water’ via services van allerlei applicaties ter beschikking staat (‘composite applications’). Dat kunnen oude legacyapplicaties zijn, maar ook standaardpakketten of moderne webtoepassingen. Een applicatiearchitectuur geeft op hoofdlijnen aan welke applicaties (al dan niet geclusterd tot bedrijfs- of applicatiedomeinen) er binnen de organisatie onderkend worden, inclusief de onderlinge interfaces, eigenaarschap en richtlijnen voor communicatie. Dit is relevant omdat deze applicaties c.q. applicatiedomeinen de aanbieders zijn van de services en er duidelijk moet worden welke afspraken er gelden voor het aanbieden en gebruiken van services. Daarnaast worden in een applicatiearchitectuur ook richtlijnen gegeven voor het definiëren en bouwen van services, berichten, de interne constructie van applicaties (in termen van componenten en lagen), enz.

De applicatiearchitectuur vormt eveneens een belangrijk vertrekpunt voor het vaststellen van de migratiestrategie, door de visie op de gewenste situatie te projecteren op het bestaande systemenlandschap en zodoende inzichtelijk maken wat wel en niet (meer) tot de verantwoordelijkheid van een bepaald systeem behoort en waar de grootste veranderingen inzake bijvoorbeeld eigenaarschap plaatsvinden.

Technologiearchitectuur

Een technologiearchitectuur beschrijft de gewenste technische en infrastructurele aspecten van de informatievoorziening: hardware, middleware, software, pakketten, netwerken, protocollen. Ook wordt hierin de gewenste systeemontwikkelomgeving beschreven, in termen van methoden, technieken, talen en hulpmiddelen. Het doel van een technologiearchitectuur is om een samenhangende blauwdruk van infrastructurele voorzieningen op te zetten die optimaal aansluit op de benodigde applicaties en de gewenste bedrijfsvoering.

Enkele zaken die normaal gesproken zullen terugkomen in een technologiearchitectuur zijn: uitgangspunten (bijvoorbeeld 7*24 uur beschikbaarheid, of web-based, of SOA) hardware, middleware en operating systems, met richtlijnen om te komen tot de keuzes:

• richtlijnen voor technische componenten;
• hulpmiddelen, onder andere voor softwareontwikkeling en beheer;
• richtlijnen voor interactie, stijlgidsen, taalgebruik;
• communicatie, netwerken, met afspraken over beveiliging, protocollen en dergelijke;
• identificatie, vaststelling van authenticiteit en autorisatie;
• logging, tracking en tracing;
• databasekeuzes en toegang;
• transactiemanagement, sessiemanagement en load balancing.

Als een servicegeoriënteerde informatievoorziening wordt nagestreefd, dan betekent dit dat de technologiearchitectuur op sommige punten anders zal worden ingevuld. In essentie worden er onderdelen toegevoegd die de samenwerking tussen softwarecomponenten gaan standaardiseren en dat zijn vooral veel standaarden:

• standaarden voor berichtuitwisseling en services;
• richtlijnen voor technische lagen en componenten;
• richtlijnen en templates voor het bouwen van services;
• richtlijnen voor gebruik van de Enterprise Service Bus.

De flexibilisering die door middel van services mogelijk wordt brengt met zich mee dat goede afspraken essentieel zijn om de samenwerking vlekkeloos te laten verlopen, deze afspraken zijn de afgelopen jaren vastgelegd in internationale standaarden.

In de praktijk blijkt dat het hebben van standaarden niet direct betekent dat een organisatie willekeurig elk product kan toevoegen aan de technologiearchitectuur om een best-of-breed invulling te bewerkstelligen. Het is geen nieuw dilemma: kiezen we voor de leverancier met de vele producten (met als nadeel een vendor lock-in) of kiezen we voor vele leveranciers (met als nadeel de onvermijdelijke integratieproblematiek, zowel technisch als organisatorisch). Vaak is het verstandig om de grote kern van de technologiearchitectuur in te vullen met producten van één of een beperkt aantal leveranciers: met een minimale set de maximale behoefte afdekken. Dit voorkomt integratieproblemen tussen middlewareproducten, besturingssystemen en hardwarecomponenten.