Werken onder architectuur bij MN
Mn kent veel systemen die in samenhang met elkaar werken. MN kent ook veel verander initiatieven. Het sturen en richting geven op samenhang tussen systemen, zodat de dienstverlening van MN als geheel goed blijft werken, is in een dynamiek van verandering erg belangrijk. Die samenhang realiseert MN door te werken onder architectuur. De daarbij gekozen methoden, producten, processen en functierollen zijn beschreven in het document MN Architectuurfunctie zoals gepubliceerd op de MN Connectsite Architectuur, en wordt kort toegelicht.
Richting geven Een belangrijk doel van architectuur is het geven van richting. De MN strategie, de aan MN uitbestede processen van de opdrachtgevers en de wettelijke kaders en de kaders van onze toezichthouders, en natuurlijk best practices en ervaringen uit het verleden zijn input voor het MN informatie beleid en de daar onderliggende verdiepende kaders (zoals informatiebeveiligingsbeleid en richtlijnen voor de informatievoorziening). Deze kaders zijn door de EC of de door de EC gemandateerde architectuurboard voor MN van toepassing verklaard. De Kaders en Richtlijnen waaraan moet worden voldaan zijn vastgelegd op het MN Beleidsdocumenten portaal in MN Connect Beleid IV. Jaarlijks wordt getoetst in hoeverre er aan de kaders wordt voldaan. In principe geldt dat nieuwe projecten of projecten met grote changes conform de kaders worden gerealiseerd. Er wordt ca. 3 jaar uitgetrokken om bestaande systemen aan te passen.
Realisatie van architectuur Uiteindelijk zijn al die kaders papier. De verbeterde samenhang en verhoogde toekomstvastheid wordt pas gerealiseerd in projecten die de IT oplossingen, werkwijzen en processen voor gebruikers realiseren. Daarom is het richting geven aan veranderingen essentieel voor het werken onder architectuur. Dat doen de architecten door een aantal producten te leveren, maar vooral door vanuit architectuur deel te nemen aan overleggen en vooral te begeleiden op de IT-werkvloer. Werken onder architectuur vraagt dan ook dat de architecten naar de bouwteams komen en dat de bouwteams naar de architecten komen met vragen over oplossingsrichtingen. De Project Start Architectuur (PSA) is, ook bij agile projecten, het product dat wordt gebruikt om op voorhand (onder het motto ‘eerst denken, dan doen’ ) de belangrijkste keuzen voor de oplossingsrichtingen te maken in overleg met de betrokkenen. Dat gaat niet alleen over systemen en IT-infrastructuur, maar ook over business processen en security.
De PSA bevat een set keuzen en modellen die bedoeld zijn om de bouwteams en de business te helpen. Het voorkomt rework en het zorgt ervoor dat systemen integraal kunnen worden doorontwikkeld. Om die reden besteden de architecten veel aandacht aan het uitdragen van die PSA. Een uiting daarvan is bijv. het opnemen van de PSA in de ‘Definition of Done’ in de IV voortbrengingsketen. Ook controleren de architecten op het naleven van de kaders in de PSA en geven een architectuurcertificaat af als aan de PSA wordt voldaan.
Zodra een (grotere) IT wijziging gepland wordt om te realiseren, zal de change manager, projectleider of product owner samen met de architect vaststellen wat de beoogde oplossingsrichting is, rekening
houdend met de kaders. De architect bepaalt dan in samenwerking met betrokkenen de richting van de informatievoorziening en legt die vast in o.a. de PSA. Daarmee is de architect bepalend voor welke technologie(kaders) er wordt toegepast en welke grenzen er zijn aan de wensen van de opdrachtgever om bepaalde pakketten en technologieën te gebruiken. Tevens worden i.h.k.v. pakketselecties vanuit de architectuur requirements opgeleverd die zich baseren op het informatiebeleid en de onderliggende kaders, richtlijnen en architecturen. Daarbij wordt een concept PSA gemaakt indien dat toegevoegde waarde levert.
Overigens kent MN naast de PSA ook de PCA (de proces cluster architectuur). De PCA richt zich op systeemonderhoud en geeft aan wat er in ongeveer een jaar vanuit architectuur (op vooral technisch niveau) zal moeten veranderen (c.q. wegwerken technische schuld). Naast projecten zijn er vele kleinere changes waarbij o.b.v. een checklist wordt bepaald of de architectuurfunctie moet worden ingeschakeld.
Naast het opstellen van architectuur op MN, unit en projectniveau volgen de enterprise-architecten actief IT-trends en kijken naar de mogelijke toepassingen en kansen die IT ontwikkelingen bieden voor MN.
Meerdere architectuur rollen zijn betrokken Het werken onder architectuur gebeurt bij MN door meerdere architecten en business consultants. Naast de Enterprise architecten (EA’s) zijn de Solution architecten in de units van groot belang. Deze architecten zijn onderdeel van de bouwteams en maken gezamenlijk met de EA’s de PSA, dragen de PSA uit, en helpen de teams bij de realisatie onder architectuur. Ook onderkent de solution architect de architectuur epics en stuurt op de realisatie hiervan. Indien er spannende architectuur keuzen moeten worden gemaakt qua oplossingsrichting zoekt hij/zij pro actief AKV/Architectuur op. Een uitgebreidere beschrijving van de Solution Architect rol is opgenomen in het document MN Architectuurfunctie.
Belangrijk voor het werken onder architectuur is het sturen op de architectuur. Dat wordt o.a. gedaan door de architectuurboard, die het MN-brede architectuurgeweten vormen. De architectuur board is formeel vastgesteld en kent voor haar werkwijze een charter. Omdat hier beleid en richtlijnen op MN niveau worden vastgesteld zijn de (meeste) leden afgevaardigde managers van de units.