Het zal wel aan mij liggen, maar ik begrijp niet wat ik precies moet verwachten van documenten waarop staat "informatiebeleidsplan", "informatiestrategie", "informatiebeleid", "informatieplan" en "informatievisie". Ik begrijp dat er strategisch moet worden nagedacht over informatie; ik vind dat zelfs erg belangrijk. Ik geloof dat het hebben van een strategische visie op je informatievoorziening essentieel is om deze effectief te laten zijn. Om de een of andere reden lijkt het echter dat strategische informatieproducten moeten bestaan uit wollige taal met een onduidelijke doelstelling. Als architect probeer ik maximaal aansluiting te vinden bij dit soort producten, maar dan moet ik ze wel begrijpen.

Als architect heb ik overigens zelf ook boter op mijn hoofd. Het architectuurvakgebied is ook alles behalve volwassen en van architectuurdocumenten is veelal ook onduidelijk wat je ervan moet verwachten. Standaarden als TOGAF en ArchiMate nemen slechts een beperkt deel van deze onduidelijkheid weg. Het verschil met de meer strategische informatieproducten is echter dat ik als architect zelf in de hand heb wat ik in de architectuur opschrijf. Ik kan er zelf voor zorgen dat de producten maximaal toegevoegde waarde hebben. Daarmee acteer ik echter vooral vanuit mijn eigen kennis, ervaring en visie. De kans is dus vrij groot dat iemand anders geheel andere architectuurdocumenten schrijft.

Ik wil in deze blog in ieder geval helder maken wat ik als input verwacht en wat ik als output oplever voor de strategische informatieprocessen. Daarbij redeneer ik even alleen vanuit i-perspectief, alhoewel enterprise-architectuur eigenlijk breder is. Ik verwacht als input vooral duidelijke doelstellingen, verdiept tot op het niveau van concrete tijdsgebonden ambities. Dat zijn algemene bedrijfsdoelstellingen, maar ook doelstellingen die gelden voor de informatievoorziening. Deze laatste zijn erg belangrijk omdat de algemene bedrijfsdoelstellingen in veel gevallen nog erg ver van de informatievoorziening af staan. Gevoelsmatig zou ik dit soort doelstellingen verwachten in een document genaamd "informatiestrategie".

Daarnaast verwacht ik duidelijke beleidsuitgangspunten die aangeven waarbinnen de architectuur dient te opereren. In tegenstelling tot doelstellingen zijn beleidsuitgangspunten niet zozeer zaken die op een bepaald moment behaald moeten worden, maar beperkingen waarbinnen keuzes moeten worden gemaakt. Het zijn keuzes die door of namens de directie zijn gemaakt. Denk bijvoorbeeld aan keuzes zoals "wij ontwikkelen zelf geen software" of "wij besteden ons IT-beheer uit". Dit soort uitspraken zou ik verwachten in een document waarop "informatiebeleid" staat, alhoewel het wat mij betreft ook wel in hetzelfde document mag staan als de doelstellingen aan de informatievoorziening.

Mijn belangrijkste output bestaat uit architectuurprincipes die fundamentele keuzes voor de inrichting van de informatievoorziening beschrijven. Deze uitspraken lijken erg op de beleidsuitgangspunten hiervoor, maar bevinden zich in mijn persoonlijke invloedssfeer. Ik vind belangrijk dat principes altijd zijn voorzien van een rationale die aangeeft waarom het principe zou moeten gelden en implicaties die het principe concreet maken. Deze basisstructuur zou eigenlijk ook moeten gelden voor beleidsuitgangspunten; het zou ervoor zorgen dat ze beter zijn onderbouwd. Naast architectuurprincipes stel ik modellen op die de principes vertalen in een gewenste inrichting van de informatievoorziening op hoofdlijnen. Deze inrichting zou een goede vertaling moeten tijd van de tijdsgebonden doelstellingen aan de informatievoorziening, zodat je een concreet meerjarenveranderplan kunt opstellen.

Uiteindelijk moet de architectuur leiden tot een set van gewenste veranderingen. Het is belangrijk deze gewenste veranderingen goed aan te laten sluiten op de strategische planningsprocessen en dat is geen sinecure. De vraag is waar de architect precies op houdt en andere disciplines zoals programmamanagement, portfoliomanagement en informatiemanagement het overnemen. In TOGAF lijkt het alsof de architect daar nog behoorlijk gedetailleerd mee bezig is, inclusief een beschrijving van de benodigde resources, tijd en prioriteit. Ik denk zelf dat de architect daar al niet meer in de lead zou moeten zijn. Uiteraard kan de architect hier wel een grove inschatting voor geven, maar het is aan anderen om business cases op te stellen en prioriteiten te bepalen. De architect eindigt wat mij betreft met een grofmazige roadmap, met logische veranderplateaus. Het meer concrete plan waarin ook over resources, tijd en prioriteit wordt gesproken zou wat mij betreft "informatieplan" kunnen heten. Dit informatieplan dient te worden afgestemd met het overall business plan, maar ook met een technologieplan dat de belangrijkste technologieveranderingen beschrijft.

Ik ben benieuwd hoe anderen kijken naar deze positionering van architectuur ten opzichte van de strategische informatieprocessen. Uiteindelijk geloof ik er in dat het echt krachtig is als alle betrokken disciplines goed van elkaar begrijpen welke waarde zij toevoegen in het proces en samen ervoor zorgen dat de noodzakelijke veranderingen plaats vinden.

Weergaven: 1075

Reactie van Jan van Til op 27 Februari 2012 op 16.12

Danny,

Als ik je goed leesbare artikel - dat tegelijk ook als een ordeningsvoorstel oogt - lees, blijf ik toch wat zitten met de volgende 'ophangingsvragen':
1. Wie maakt/maken de inputs (doelstellingen, beleidsuitgangspunten) voor jou als architect? In welk verband doen ze dat?
2. Wie gebruikt/gebruiken de outputs (architectuurprincipes modellen/roadmaps) van jou als architect? In welk verband doen ze dat?
3. Wie treedt er op als de "Belangrijkste Timmerman" die het geheel begeleidt - dus van eerste idee tot werkende IT, om het maar even zo te zeggen?

Reactie van Danny Greefhorst op 27 Februari 2012 op 18.25

Beste Jan,

Goede vragen, waar ik echter de antwoorden ook nog niet echt op heb. Laat ik een poging wagen met wat antwoorden te komen:

1. Ik zou hier in eerste senior management verwachten voor het aanleveren van de algemene doelstellingen. Een informatiemanager zou de vertaling naar doelstellingen voor de informatievoorziening en beleidsuitgangspunten kunnen maken. Dit zou wat mij betreft een cyclus op twee niveau's zijn; een meerjarencyclus waarin de doelstellingen op hoofdlijnen worden bepaald en een jaarcyclus waarin de SMART doelstellingen voor het komend jaar in zijn uitgewerkt.

2. De architectuur kent vele gebruikersgroepen; enerzijds medewerkers in de operatie die deze gebruiken als kennis en leidraad voor projecten (m.n. ontwerpers) en uitvoering en anderzijds management als basis voor planvorming. Met name projectmedewerkers zullen een belangrijke afnemers zijn omdat veranderingen voor een groot deel in projecten plaats vindt. De informatiemanager zou met name de roadmap moeten gebruiken voor het opstellen van een "informatieplan".

3. Dit zou vooral de architect moeten zijn die anderen inhoudelijk begeleidt.

Mvgr,

Danny

Reactie van Erik Vermeulen op 28 Februari 2012 op 22.47

Mijn ervaring is dat je eenvoudigweg moet kijken naar wat er in een gegeven situatie nodig is om de gewenste veranderingen op gang te brengen en de juiste richting op te sturen en te houden. Het heeft niet mijn voorkeur om de werkzaamheden van de architect (als persoon) zo scherp af te bakenen. Wie nu precies wat kan of zou moeten kunnen is relevant voor persoonlijke ontwikkelpaden (die van persoon tot persoon kunnen verschillen), maar niet zo relevant voor de praktijk. Gegeven een vraagstuk moeten de juiste competenties worden gemobiliseerd en zal er als een team gewerkt moeten worden aan de oplossing. Persoonlijk lijkt het mij handig als enterprise architecten (dus niet alle architecten) ook in staat zijn om een business case te maken en om een target operating model (mate van standaardisatie en integratie) te ontwikkelen dat aansluit bij de business doelstellingen en ontwikkelingen. Maar het is ook prima als een ander teamlid met bijvoorbeeld een sterke financiële achtergrond verantwoordelijk is om de business case op te stellen en weer een ander teamlid met veel kennis en ervaring van de business de lead neemt bij het ontwikkelen van een target operating model. En als ze zich allemaal een beetje architect voelen is dat wat mij betreft ook prima (ook wanneer ze zich geen architect voelen). Wel is het zaak om - los van de poppetjes - de enterprise architectuur te borgen.

Het target operating model (een belangrijk element van de enterprise architectuur) kun je ook zien als de operations strategie zoals wordt bepleit door onderzoekers van het Center for Information Systems Research. Belangrijke inputs zijn in dit geval de bedrijfsstrategie in termen van zaken als markt- en winstdoelstellingen; de ontwikkelingen in de markt; de technologische ontwikkelingen; de relevante concurrentiekrachten en het waardebod. De outputs kunnen sterk variëren maar zullen uiteindelijk moeten resulteren in concrete migratieplannen; TOGAF - in het bijzonder de ADM - biedt hiervoor prima handvatten maar vraagt wel om een kritische selectie van producten en hier en daar ook om een uitbreiding van producten. Het helpt om bij de selectie van producten in ieder geval eerst te bepalen of je veel of weinig aandacht moet besteden aan het beschrijven van de huidige situatie.

Ik deel verder je opvatting dat de architect ook een belangrijke rol speelt bij het maken van een plateauplanning. Een aanpak voor strategische planning die ooit in de jaren 90 is ontwikkeld (overigens door mijn werkgever) om ervoor te zorgen dat veranderingen integraal en in behapbare stappen verlopen. Een plateau beperkt zich dus niet tot de veranderingen in het IT-landschap.

Vriendelijke groet, Erik

Reactie van Danny Greefhorst op 8 Maart 2012 op 21.00

Beste Henk,

Volgens mij zijn we het met elkaar eens; we moeten helder maken wat in het algemeen de positie en waarde van de architect is. Natuurlijk heeft Erik ook gelijk als hij zegt dat het in de praktijk ook sterk gerelateerd is aan de kennis en competenties van een specifiek persoon.

Mvgr,
Danny

Reactie van Danny Greefhorst op 16 April 2012 op 20.37

Ik ben bezig de relatie tussen de verschillende processen rondom informatievoorziening in relatie tot elkaar beter te beschrijven. Onderstaande plaat is een aardige weergave van mijn huidige beelden. Meer informatie kun je vinden in een presentatie die ik aan het ontwikkelen ben over het onderwerp.

Opmerking

Je moet lid zijn van Via Nova Architectura om reacties te kunnen toevoegen!

Wordt lid van Via Nova Architectura

Sponsoren

Advertenties

Je kunt hier adverteren

© 2019   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden