Architecturen in bedrijf en ict zijn meestal doordachte visies en concepten, uitgewerkt in ontwerpen, modellen, standaards, enzovoorts. Toch is het moeilijk om die architecturen daadwerkelijk en consistent toegepast te krijgen. De makers, de bedrijfs- & ict-architecten, werken soms in een ‘theorietoren’ op afstand van de bedrijfswerkelijkheid. Hoe kun je deze bedrijfs- en ict-architecturen uit de toren naar een effectieve toepassing in de dagelijkse praktijk brengen?
De ANSI/IEEE standaard P1471-2000 definieert architectuur als volgt: “The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles guiding its design and evolution.”
Het begrip systeem is zeer ruim en kan op allerlei doorsneden van een bedrijf worden toegepast.
In het artikel ‘Software-architectuur in vogelvlucht’, van D. Greefhorst in Java magazine (april 2003), worden acht architectuursoorten genoemd: enterprise-, business-, proces-, informatie-, applicatie-, software-, technische- en infrastructuurarchitectuur. Inhoudelijk verschillen deze gebieden aanzienlijk. De een heeft het bijvoorbeeld over product-markt combinaties en de ander over datacommunicatieprotocollen. Toch kunnen voor elk van deze acht gebieden architecturen gemaakt worden.
Toegevoegde waarde
Er is al veel geschreven over de voordelen van architectuur, dat hoeft hier niet herhaald te worden. Architectuur geeft richting en beperkt het aantal vrijheidsgraden en levert daardoor – hoe vreemd dat ook in eerste instantie mag lijken – meer flexibiliteit, betere beheersbaarheid en kostenverlaging. Niet alleen in de ontwikkelingsfase, maar ook in productie en beheer.
Er ligt echter nog steeds een kloof tussen het bedenken en beschrijven van bedrijfs- & ict- architecturen en het werkelijk toepassen in de praktijk. Werken onder architectuur (woa), wordt dat genoemd. Het acroniem woa doet denken aan overheidsregelgeving, maar net als soa heeft woa in de ict een opgewektere betekenis.
De benaming ‘werken onder architectuur’ wekt echter de indruk dat architectuur op een organisatie drukt; je ‘moet eronder’ werken. Eerder een last dan een lust. Dat is natuurlijk niet de bedoeling. Het is geen last, maar een nuttig middel.
Waar het om gaat, is dat de voor een bepaalde situatie ontwikkelde architectuur daadwerkelijk wordt toegepast in de dagelijkse praktijk, dat er terugkoppeling plaatsvindt naar de bedenkers, zodat die eventuele tekortkomingen kunnen aanvullen, en dat het mee verandert met veranderingen in bedrijfsconcepten, technologie, regelgeving, et cetera.
Die brug van ontwerp naar toepassing, van tekentafel naar bouwplaats, wordt hier verwoord met ‘operationaliseren van bedrijfs- en ict-architectuur’ of korter: operationaliseren van architectuur.
Zeven processen
Wat daar zoal bij komt kijken kan in de volgende zeven processen worden ingedeeld.
Scope en visie. Stel vast welke soort architectuur (zie de eerste alinea’s) in de specifieke situatie wordt bedoeld. Betreft het de architectuur van hardware en systeemsoftware of de bedrijfsprocessen of de architectuur van de applicatiesoftware, enzovoorts. Let dus goed op waar de afbakening gelegd moet worden én welke competenties nodig zijn voor die specifieke architectuur. Onderzoek welke eisen de klant of opdrachtgever stelt, de huidige situatie, het toekomstbeeld, de doelstellingen, de tijdlijn, et cetera. Ontwikkel een langetermijn visie waar bedrijf, proces, product, dienst, systeem, et cetera op termijn zouden moeten zijn. Beschrijf het ideale koersdoel.
Realiseren. In deze fase bouw je het architectuurteam (of teams) op en worden de beoogde producten ontwikkeld. Er wordt samenwerking opgebouwd met de verantwoordelijken voor andere architectuurgebieden. Zonodig wordt een architectuur- of designboard opgericht waarin de diverse partijen gezamenlijk een koers kunnen uitstippelen. Ontwerp en ontwikkel de benodigde architectuurmodellen (Met het enorme aantal vaak lijvige business & ict-architectuurboeken dat in de loop der jaren is geproduceerd kunnen bibliotheken worden gevuld. Dat kan ontmoedigend werken maar het voordeel is dat we ‘The Good, The Bad & The Ugly’ op dit gebied onder handbereik hebben en we er ons voordeel mee kunnen doen bij visie en ontwerp van bedrijfs- & ict-architecturen. Selecteer de geschikte onderdelen uit de verschillende architectuurconcepten en pas die toe), principes, richtlijnen en standaards, of selecteer en verwerf de architectuurproducten die nodig zijn voor het realiseren van de visie.
De resultaten van dit proces bestaan uit: besturingsproducten, zoals een visiedocument, accorderingsprocedure, ontwikkel-, verwervings- en beheerprocessen en rapportages; architectuurproducten zoals modellen, standaards en richtlijnen; architectuurdiensten zoals adviezen, reviews en audits en communicatieproducten zoals een intranetsite, presentaties, bulletins en workshops.
Accorderen en bindend voorschrijven. Stem de noodzaak van architectuurproducten en de voorkeursoplossingen met alle betrokken partijen af. Zorg voor een formeel goedkeuringsproces, zodat de gekozen oplossingen ook bindend kunnen worden voorgeschreven.
Communiceren en beheren. Weet wat er in huis is, zorg voor de beschikbaarheid van de juiste versies, voor goede indexering en beschrijvingen. Communiceren doe je vanaf het eerste begin. Het eenvoudig afroepen van architectuureisen en dwingend voorschrijven van de architectuurproducten sec, zodra die beschikbaar zijn, werkt helaas niet. Communiceren is in dit geval het toegankelijk maken en beschikbaar stellen van de architectuurproducten en het gebruik van een breed palet aan middelen en methoden (intranet; presentaties; workshops; gebruikersforum; enzovoorts) om dit onder de aandacht te brengen en te houden. Het credo is: herhaal, herhaal, herhaal. Bied gelegenheid tot vragen stellen, tot inbreng van ideeën, tot discussie.
Implementeren. De vorige processen vormen de aanloop tot het daadwerkelijk toepassen van de architectuurproducten. Daartoe moeten die architectuurproducten worden ingebed in de bedrijfsprocessen. Bijvoorbeeld in productmanagement, offertes, projectintake en -start, projectvoortgang, productoplevering, et cetera. Het toepassen van de architectuurproducten moet niet afhankelijk zijn van de animo of goede wil van de betrokkenen, maar het moet onderdeel zijn van de bedrijfsprocessen. Zo moet in het offerteproces een architectuurcheck plaatsvinden: voldoet het voorstel aan onze eigen standaarden? In het projectstartproces moet als voorwaarde gelden dat er een projectstartarchitectuur beschikbaar is, enzovoorts. Vanuit deze processen moet ook terugkoppeling worden gegeven naar de architectuurteams, zodat zij de architectuurproducten kunnen aanpassen op basis van de gebruikservaringen.
Toezicht op de naleving. Inbedding in de bedrijfsprocessen is een nodige, maar niet voldoende voorwaarde voor het operationaliseren van architectuur. Er moeten ook regelmatige en steekproefsgewijze checks worden uitgevoerd op de naleving van de architectuurvoorschriften. Een goede manier hiervoor is het opnemen van een architectuurcheck in projectvoortgangs-, test-, oplevering-, review- en auditprocessen.
Aanpassen. Niets is veranderlijker dan business en ict. In beton gegoten architecturen zijn ten dode opgeschreven. Zorg ervoor dat er voeling gehouden wordt met veranderingen in klanteisen, producten, bedrijfsprocessen, technologie, regelgeving, methodieken, enzovoorts, en dat de bestaande architectuur zonodig wordt aangepast aan die veranderende omgeving. Architectuurreleases zijn een uitstekend middel om samenhangende architectuurproducten te clusteren. Zo kunnen bijvoorbeeld twee architectuur-‘generaties’ naast elkaar bestaan: de huidige en de volgende. Eigenaren van processen en/of systemen kunnen daar in de lifecycle-planning rekening mee houden.
Architectuurteams
Een voetbalteam met alleen maar spitsen, doelpuntenjagers, boekt geen succes. Datzelfde geldt voor architectuurteams met alleen maar architecten. Uit het voorgaande zal duidelijk zijn dat een dergelijk team ook over andere capaciteiten moet beschikken: procesontwerp, beheer, communicatie, veranderingsmanagement, advisering. Er zullen echter altijd teams nodig zijn met specifieke kennis van het betreffende architectuurgebied.
De architecten mogen de smaakmakers zijn, het spel wordt vooral door anderen bepaald. Naruurlijk opdrachtgevers en management, maar voor het operationaliseren van architectuur zijn er ook andere spelbepalers. Een paar voorbeelden met een korte toelichting volgen hierna. De termen hebben geen uniforme betekenis dus let goed op hoe zo’n spelbepaler in je eigen organisatie wordt genoemd.
Architectuurboard of Design Office: groep architecten uit diverse disciplines die een samenhangende architectuur bepalen. Zij kunnen ook optreden als een toetsingsgremium die projecten beoordeelt op de architectuuraspecten.
ICT-board of Programmaboard: groep lijn- en ict-managers, verantwoordelijk voor een lange termijnplan van systemen en projecten. Rangschikken en fiatteren projectplannen. Bepalen de lifecycle-planning van systemen.
Change Control Board: groep inhoudelijke deskundigen die grote wijzigingsvoorstellen, zoals nieuwe releases van een systeem, beoordelen en besturen.
Bedrijfsbureau of projectenbureau: verantwoordelijk voor intake, begrotingen, planning, voortgangs- en kwaliteitsbewaking van projecten.
IT-auditors: specialisten binnen het audit vakgebied, specifiek op het gebied van organisatie en automatisering, onder andere voor beoordeling van bedrijfsprocessen in relatie tot ict, ontwikkel- en beheerprocessen en de toepassing van wet- en regelgeving.
IT-security officers: specialisten op het gebied van informatiebeveiliging, zij stellen beveiligingsrichtlijnen op en beoordelen systemen en projectplannen op dit aspect.
Zij horen formele schakels te zijn in de bedrijfsprocessen zoals hiervoor genoemd.
De parallel met de bouwwereld is evident. Operationaliseren van architectuur vergt grote inspanning, maar het heeft geen zin om bedrijfs- en ict-architecturen te maken als de operationaliseringsstap niet wordt genomen. Dan blijft het studeerkamerwerk, tekentafelmodellen ver van de bedrijfswerkelijkheid. Stroop dus de mouwen op, neem de tekentafelmodellen onder de arm en operationaliseer architectuur!
Ferdinand G. Geuther, adviseur management en ict-vraagstukken
