Trends en issues in architectuur

Daan Rijsenbrij en Frank Baldinger, 3 oktober 2012

In het kader van haar tweede lustrum heeft het NAF op 13 september 2012 een workshop georganiseerd met chief architects en managers van architectuurafdelingen over trends en issues in architectuur, gemodereerd door Daan Rijsenbrij en Frank Baldinger.

De bedoeling van deze workshop was een lijst van architectuurtrends (belangrijke issues die zich ontwikkelen) te laten opstellen. Wij zijn er van overtuigd dat er in Nederland veel praktische visie aanwezig is over architectuur en zouden dit graag expliciet maken.

Het woord ‘trend’ interpreteren wij nogal breed: trends, hypes, cruciale onderwerpen, aandachtsgebieden e.d. Wij hebben voor deze brede interpretatie gekozen omdat dit de eerste inventarisatie betreft in Nederland en wij nog zoekende zijn naar de juiste vorm en inhoud van een bruikbare, betrouwbare trendinventarisatie. De komende jaren zullen wij een dergelijke inventarisatie stap voor stap professionaliseren tot wellicht een Gartner-achtig niveau van hype cycles.

Deelnemers aan de workshop waren: Eric Roovers (Software AG), Gert-Jan Kamer (Tata Steel), Gerben Wierda (APG), Huub Bakker (Atos), Jan Verbeek (Be Informed), Jan Albert Kuijk (Rijkswaterstaat), Jurriaan Brandsma (Tibco), Karin Middeljans (ministerie EL&I), Klaas Nieuwhof (UMCU), Lambert Caljouw (Royal Vopak Terminals), Marcel Dijkman (C1000), Marcel van Nunen (DICTU), Martin van den Berg (DNB), Martina Gaiser-Janáčková (Gartner), Menno Gmelig Meijling (SVB), Nanne Nauta (SNS Reaal), Peter Beijer (HP), Peter Kuiters (KPMG), Peter Valkenburg (UWV), Raimond Brookman (Info Support), Richard Lugtigheid (PGGM), Rienk de Kok (The Unit), Sjako ten Haken (Ordina), Theo Arts (Rijkswaterstaat), Theo Jan Renkema (Rabo), Wilbert Kroon (Kadaster), Willem Levelt (Capgemini), Wouter Schmitz (ABNAMRO).

In een eerste plenaire sessie zijn 6 architectuurclusters gekozen waarbinnen de trends kunnen worden gepositioneerd: architectuurproducten, architecten, architecting, technologie, borging en governance van architectuur en complexiteitsreductie door architectuur.

Korte toelichting op de clusterinhoud:

  • Onder architectuurproducten wordt verstaan architectuur als (tussen-)resultaat. Hierbij spelen zaken als denkwijze, architectuurlagen (in het bijzonder businessarchitectuur) en vormgeving. Maar ook de toepassing van architectuur voor de besluitvorming, voor kosten/baten analyse (businesscase) en tijdens de bouw, horen tot deze cluster.
  • Bij architecten kan men denken aan: verantwoordelijkheid, rol, taak, competenties, (advies)vaardigheden, loopbanen, opleidingsvereisten en certificering.
  • Onder architecting wordt verstaan het proces van het maken van een architectuur en de ondersteuning van dit proces met methodes en tools. Hierbij spelen zaken als werkwijze, architectuurproces in relatie tot systeemontwikkelmethoden zoals bijvoorbeeld Scrum, juist in time / just enough architectuur. Maar ook de ondersteuning van de werkwijze behoren tot deze cluster, zoals methodes, frameworks, visualisaties en tools.
  • Technologie gaat over de invloed van technologie op (nieuwe) architectuurmogelijkheden. Te denken valt aan social computing, tablets, BYOD, apps, cloud en big data.
  • Borging en Governance is in feite een onderdeel van architecting. Het grote belang van dit deelonderwerp en het feit dat deze onderwerpen in de lijnorganisatie belegd worden, rechtvaardigt een aparte cluster. Denk aan architectuur board, PSA en daadwerkelijke betrokkenheid van de cruciale stakeholders. Maar denk ook aan de plaats, de verantwoordelijkheid en de rol van de architectuur en de architecten in de organisatie, de communicatie met en over architectuur en referentiearchitecturen.
  • Volgens schattingen wordt ruim 70% van het IT-budget besteed aan het onderhoud en de verbouw van legacy-systemen, systemen die soms meer dan 40 jaar oud zijn. Onderhoud zonder architectuur maakt systemen vaak complexer.

Maar ook door de hectiek in de (business) wereld neemt de complexiteit steeds verder toe. Zoals een hoofdwet van de thermodynamica stelt: ‘een systeem dat aan zichzelf wordt overgelaten, streeft naar maximale entropie’. Om die maximale wanorde te voorkomen dient architectuur te worden ingezet bij het reduceren en bewaken van de complexiteit.

Vervolgens zijn er per cluster middels werkgroepen met plenaire terugkoppeling de volgende 21 issues boven de horizon verschenen:

Architectuurproducten

1. Meer focus op het eindresultaat.

2. Meer focus op architectuurdiensten.

3. Toegankelijk maken voor niet-architecten.

4. Waarde leveren als stuurinstrument.

Architecten

5. Verlies van aandacht voor materie- en domeinkennis.

6. Grens tussen IT en business vervaagt, en dat stelt meer eisen aan de vaardigheden van de architect.

7. Eisen aan de architect wijzigen. Holistische blik, conceptueel vermogen, integratie en verbinding worden de speerpunten.

8. Diversificatie in het architectuurteam is nodig om beter aan te sluiten bij andere IT- en businessparadigma’s.

9. Architecten worden aansprakelijk voor hun beslissingen.

10. Niet consulteren, maar sturend adviseren.

Architecting

11. Verschuiving naar het begeleiden van de besluitvorming.

12. Architectuurprocessen en artefacten worden LEAN-er.

13. Visualisatie van architecturen krijgt plaats naast taal.

Invloed van moderne technologie op architectuur

14. Cloud Computing

15. Big Data

16. Ontstaan van een grote variatie van devices en presentatietechnieken.

Borging en Governance van architectuur

17. Autonomie van de Business.

18. Van vastleggen (IST) naar transformatie (area of change) en het mogelijk maken van de transformatie.

19. Grotere bewustwording van het management.

20. Formalisatie van de governance.

Complexiteitsreductie door architectuur

21. Veel organisaties kampen met grote en complexe IT systemen.

Daarna hebben de werkgroepen de issues verder uitgewerkt, zoals hieronder staat aangegeven. Bij elke issue hoort een omschrijving, het probleem waarop dit issue een antwoord beoogt te zijn en de nieuwe (business)kansen die door dit issue worden geboden. Tenslotte werd nog gevraagd aan te geven of dit issue al wordt opgepakt in Nederland en wat de beoogde tijdsontwikkeling zou kunnen zijn.

1. Architectuurproducten

Issue 1.1

Meer focus op het eindresultaat

Omschrijving

Het opleveren van architectuurproducten die verbonden zijn met het eindresultaat dat bereikt moet worden.

Behoeftegestuurde architectuur (just-enough, just-in-time).

Probleem

  • Architectuurproducten zijn nog teveel documenten die te weinig gericht zijn op het eindresultaat (zoals een succesvolle businesstransformatie).
  • Architecten zijn er niet om documenten volgens een standaard stramien op te leveren, maar om een bijdrage te leveren aan een businesstransformatie.

Kans

Door praktische, goed geformuleerde eindproducten krijg je effectievere architecten en daardoor meer toegevoegde waarde voor de business.

Lopend

Ja

Tijdslijn

Is afhankelijk van de architectuurvolwassenheid. Sommige organisaties doen dit al, bij andere organisaties zal het nog jaren duren.

Issue 1.2

Meer focus op architectuurdiensten

Omschrijving

De architectuurfunctie is gericht op het leveren van diensten (waaronder advies).

Probleem

Heeft raakvlakken met issue 1.1.

Om architecten uit hun ivoren toren te halen en te voorkomen dat het documentfetisjisten worden helpt het om aan te geven wat de dienst is die de architect levert.

Kans

Het wordt voor opdrachtgevers helderder wat van een architect verwacht kan worden

Lopend

Ja

Tijdslijn

Is afhankelijk van de architectuurvolwassenheid. Sommige organisaties doen dit al, bij andere organisaties zal het nog jaren duren.

Issue 1.3

Toegankelijk maken voor niet-architecten

Omschrijving

Bestaande architectuurproducten en – repositories ontsluiten voor niet-architecten

Probleem

Architectuurbeschrijvingen bevatten heel veel nuttige informatie voor de besluitvorming. Door deze informatie slim te ontsluiten en te koppelen aan zaken als kostprijsmodellen van IT, kan managementinformatie worden gecreëerd voor o.a. portfoliomanagement, programma- en projectmanagement.

Kans

Meer zichtbaarheid en toegevoegde waarde van architectuur in de organisatie.

Lopend

Ja

Tijdslijn

Is afhankelijk van de architectuurvolwassenheid. Sommige organisaties doen dit al, bij andere organisaties zal het nog jaren duren.

Issue 1.4

Waarde leveren als stuurinstrument

Omschrijving

Architectuurproducten focussen op de waarde die zij leveren.

  • Operationeel à Minder verspilling
  • Tactisch à Juiste keuzes maken
  • Strategisch à Waarde onderneming verhogen

Probleem

Duidelijk maken waar je als architect het verschil kunt maken. Nu is dat vaak onduidelijk.

Randvoorwaarde is wel dat de governance goed is ingericht, want er is meer dan architectuur nodig om een succesvolle businesstransformatie te bewerkstelligen.

Kans

Meer toegevoegde waarde leveren

Lopend

Ja

Tijdslijn

Is afhankelijk van de architectuurvolwassenheid. Sommige organisaties doen dit al, bij andere organisaties zal het nog jaren duren.

2. Architecten

Issue 2.1

Verlies van aandacht voor materie- en domeinkennis

Omschrijving

We zien dat er onvoldoende aandacht is voor de kennis die onderscheidend is voor een architect, en de basis voor het leveren van een oplossing. Domeinkennis is een vereiste; het gaat om de balans tussen vaardigheden en kennis.

Probleem

De business krijgt geen oplossing, en architectuur verliest kracht doordat de architect is veranderd in een facilitator.

Kans

Door een juiste balans krijg je effectievere architecten en daardoor meer toegevoegde waarde voor de business.

Lopend

Ja

Tijdslijn

Vanaf drie jaar geleden, wordt wel urgenter.

Issue 2.2

Grens tussen IT en business vervaagt, en dat stelt meer eisen aan de vaardigheden van de architect

Omschrijving

Focus op vaardigheden is nodig, maar vergeet de balans met kennis niet.

Probleem

Verlies aansluiting met business, daardoor kan architectuur geen meerwaarde leveren

Kans

Betere alignment, effectievere oplossing

Lopend

Ja

Tijdslijn

Vanaf drie jaar geleden, wordt wel urgenter

Issue 2.3

Eisen aan de architect wijzigen. Holistische blik, conceptueel vermogen, integratie en verbinding worden de speerpunten.

Omschrijving

Een deel van de bestaande generatie architecten zijn pakket-systeem specialisten. Dat voldoet niet langer in de wijzigende omgeving van organisaties. Het accent verschuift naar integratie, zowel over systemen als over processen

Probleem

Architectuur is niet klaar voor de wijzigende omgeving en levert daardoor niet de oplossingen die de organisatie vraagt.

Kans

Architectuur levert een antwoord op toename complexiteit door cloud, toename in aantallen pakketten, everyone’s IT, hogere integratie-eisen met legacy, meer ketens qua proces en systemen, zowel binnen als buiten de organisatie (cloud), en de verwachting van de organisatie daarover.

Lopend

Ja

Tijdslijn

Vanaf drie jaar geleden, wordt wel urgenter

Issue 2.4

Diversificatie in het architectuurteam is nodig om beter aan te sluiten bij andere IT- en businessparadigma’s (andere applicatielandschappen, business modellen etc.).

Omschrijving

Goede architecten komen niet enkel vanuit de IT, diversificatie van het traject om architect te worden is nodig. Door meer aansluiting bij de business, meer gevoel voor de processen, meer voor vaardigheden zijn ook andere vooropleidingen voor architecten mogelijk. Daardoor wordt het architectuurteam beter en diverser. De opleiding van architect is ook nu te verrijken met stages etc.

Probleem

Er is schaarste op de arbeidsmarkt

Er is geen formeel opleidingstraject

Kans

Grotere diversiteit levert hogere kwaliteit en effectiviteit

Lopend

Ja

Tijdslijn

Wordt steeds duidelijker

Issue 2.5

Architecten worden aansprakelijk voor hun beslissingen.

Omschrijving

Als architect kun je je niet meer verbergen, en (vooral in Angelsaksische landen) is een rechtszaak niet ongewoon. Bovendien geeft dat ook het belang van architectuur aan.

Probleem

Is anders dan wat we nu gewend zijn. De vrijblijvendheid van het advies gaat weg. Neemt niet weg dat je keuzen voorlegt aan het hogere management ter besluitvorming (o.b.v. scenario’s).

Kans

Professionalisering van het vakgebied. Certificering kan bijdragen aan kwaliteitsborging.

Lopend

Ja

Tijdslijn

Vanaf 2013

Issue 2.6

Niet consulteren, maar sturend adviseren.

Omschrijving

Architecten komen steeds beter binnen op het hogere managementniveau. Als architecten het verschil willen maken, dan moeten ze niet enkel luisteren, maar ook echt sturend adviseren.

Er is een relatie met het issue ‘aansprakelijkheid’.

Probleem

De verwachtingen van het management zijn hoog, want architectuur is hot. Om dat waar te maken dienen wel oplossingen te worden geboden

Kans

100%

Lopend

Loopt nu al

Tijdslijn

Wordt steeds duidelijker

3. Architecting

Issue 3.1

Verschuiving naar het begeleiden van de besluitvorming

Omschrijving

Organisaties betrekken steeds meer architecten vroegtijdig in het besluitvormingsproces. In plaats van een kant-en-klare opdracht in het realiseren van een IT-oplossing, zijn architecten steeds meer onderdeel van de gehele verandering en adviseren op een breed speelveld van domeinen.

Probleem

  • Door te laat aan te haken komen architecten voor voldongen feiten te staan.
  • Er is onvoldoende aansluiting tussen de businessdomeinen en de IT. De architect met een IT-achtergrond heeft niet de competenties om daar een brugfunctie in te vervullen.

Kans

  • Op deze wijze komt de architect naast de opdrachtgever te staan als raadsman, in plaats van een pure opdrachtnemer te zijn die uitvoert wat gevraagd wordt.
  • De doorlooptijd van architectuurtrajecten wordt korter omdat meteen alle issues op tafel komen en er minder kennisoverdracht noodzakelijk is.
  • De acceptatiegraad wordt hoger omdat de opdracht gezamenlijk gespecificeerd en aangescherpt wordt.
  • Door eerder aan te sluiten wordt een meer integrale benadering afgedwongen.

Lopend

Loopt nu al.

Tijdslijn

  • Deze trend is groeiende en wordt reeds in organisaties toegepast.
  • We verwachten dat deze trend binnen een jaar steeds meer aan populariteit zal winnen.

Issue 3.2

Architectuurprocessen en artefacten worden LEAN-er.

Omschrijving

Het wordt steeds belangrijker dat architecturen vraaggestuurd en effectief worden opgesteld. Architecturen dienen steeds meer just-in-time te worden opgesteld en direct waarde toe te voegen. Daarnaast wordt samenwerking en integraal denken steeds belangrijker.

Probleem

  • Het opstellen van architecturen kent vaak een te lange doorlooptijd.
  • Als architecturen niet snel kunnen worden geleverd, komen ze los te staan van actuele ontwikkelingen en neemt de waarde van architectuur snel af.
  • Architecturen worden regelmatig verder in detail uitgewerkt dan strikt noodzakelijk is om succesvol veranderingen te kunnen doorvoeren.
  • Architectuurdocumenten hebben vaak veel meer volume dan strikt noodzakelijk om de essentiële keuzen voor de verandering te kunnen maken.

Kans

  • Sneller schakelen in de lijn tussen opdrachtgevers, architecten en ontwerpers.
  • Meer in samenwerkingsmodus in plaats van controlling/escalatie modus.
  • Sneller realiseren van een goede oplossing in plaats van architectuurafwijkingen naderhand corrigeren.
  • Graduele overdracht van kennis en verantwoordelijkheid binnen projecten vanuit het enterprise architectuur team. Uitdaging hierbij is wel om de architectuurresources goed te verdelen over de grote diversiteit aan projecten.

Lopend

Loopt nu al

Tijdslijn

  • Deze trend is groeiende, maar veel organisaties werken nog met een losstaand architectuurteam.
  • We verwachten dat deze trend binnen 5 jaar tot een standaard werkwijze ingeburgerd is. Sterker nog, over 5 jaar zal deze manier van denken noodzakelijk zijn om nog bestaansrecht te hebben.

Issue 3.3

Visualisatie van architecturen krijgt plaats naast taal

Omschrijving

Acceptatie van architectuur is belangrijker dan het opstellen ervan. Daarom is effectieve communicatie steeds belangrijker. Deze communicatie dient naast de ratio ook te appelleren aan de emotie. De meeste beslissingen worden voor een belangrijk deel genomen op basis van emotie en het is belangrijk dat de architectuur daarop inspeelt. Visualisatie is krachtiger in het snel overdragen van beleving en andere emotionele aspecten, dan tekstdocumenten.

Probleem

  • Lijvige documenten met veel tekst worden niet gelezen en kosten veel tijd om op te stellen.
  • Puur tekst ‘raakt’ de meeste mensen niet.

Kans

  • Het is mogelijk om formele en informele modellen te koppelen, om zowel aan de emotie te appelleren, maar tegelijk toch consistentie tussen verschillende platen de behouden.
  • Geavanceerde visualisaties maken het weergeven van meerdere dimensies tegelijk mogelijk, bijvoorbeeld:
    • 3D: in 1 model het bekijken van meerdere aspecten
    • Tijd: dynamische modellen zoals migratie scenario’s in de vorm van een animatie maken duidelijk hoe bijvoorbeeld een systeemlandschap door de tijd verandert.
  • Alle zintuigen worden uitgenut en daarmee beklijft de boodschap beter.

Lopend

Loopt nu al

Tijdslijn

  • De trend is in de opstartfase. Er wordt in een aantal organisaties mee geëxperimenteerd, maar is zeker nog geen gemeengoed.
  • We verwachten dat deze trend steeds verder zal toenemen in de komende 5 tot 10 jaar. De huidige generatie is gewend om in beelden en korte statements te communiceren. Dit zal leiden tot steeds meer vraag naar visualisatie.

4. Invloed van moderne technologie op architectuur

Issue 4.1

Cloud Computing

Omschrijving

  • Cloud Computing zal leiden tot een scherpere scheiding tussen de demand en de supply organisatie. Daardoor ontstaat ook een scheiding tussen ‘demandarchitecten’ en ‘supplyarchitecten’.
  • De nadruk bij de supplyorganisatie zal met name komen te liggen op technisch georiënteerde architecten.
  • Als gevolg van het voorgaande zal de nadruk bij de architecten van de demandorganisatie meer komen te liggen bij governance en functionele architectuur.
  • Het belang van integratiearchitectuur zal groter worden.
  • Het belang van architectuur zal als ‘smeermiddel’ tussen business en IT langzaam verdwijnen, in plaats daarvan zal architectuur als onderhandelingsmiddel worden ingezet.

Probleem

  • De scheiding tussen demand en supply is in veel organisaties nog niet volledig doorgevoerd, omdat de regiedeskundigheid aan de demandkant nog onvoldoende ontwikkeld is.
  • In veel organisaties is de benodigde (functionele) governance nog zwak ontwikkeld.

Kans

Zeer groot.

Lopend

Loopt nu al

Tijdslijn

10 jaar tot stabilisatie

Issue 4.2

Big Data

Omschrijving

  • Big Data veroorzaakt een explosie van beschikbare data, waarbij het belang van data- / informatieconsumptie veel groter wordt dan het belang van dataopslag.
  • Het gevolg hiervan is dat modelleertechnieken die gebaseerd zijn op dataconsumptie belangrijker gaan worden dan die voor dataopslag.
  • Bij de requirementsanalyse speelt de beschikbaarheid van gegevens een belangrijkere rol en niet alleen de ‘green field’ vraag.
  • Het gebruik van complexe event-processing vereist specifieke modelleringstechnieken.

Probleem

De benodigde methodes om de behoefte t.a.v. de consumptie (requirements) en de modellering van de data te beschrijven zijn nog in ontwikkeling en kennis van deze methodes is niet wijdverbreid.

Kans

Aanzienlijk

Lopend

Loopt nu al

Tijdslijn

15 jaar tot stabilisatie

Issue 4.3

Ontstaan van een grote variatie van devices en presentatietechnieken.

Omschrijving

  • Grotere complexiteit bij het beheer van uiteenlopende particuliere devices en weergavetechnieken, in het bijzonder apps. Daardoor zullen er hogere eisen worden gesteld aan de beheerarchitectuur, in het bijzonder op het gebied van beveiliging, identiteits- en toegangsbeheer en privacy.
  • Architectuur zal eerder worden vertaald in policies en bijbehorende governance in plaats van end-to-end dicht-getimmerde architecturen. Dit verhoogt de flexibiliteit van de oplossing. Dit leidt ook tot een verschuiving van de span-of-control.
  • Databeveiling wordt steeds belangrijker.
  • Kwaliteit wordt steeds belangrijker in een wereld die steeds meer gedigitaliseerd is / wordt. Niet alles wat ter beschikking staat levert voor jou toegevoegde waarde.
  • Het vak van architect verschuift van het ‘managen’ van het technologielandschap en kostenbeheersing naar het managen van het informatielandschap en bedrijfsrisicobeheersing.

Probleem

  • Security risico’s.
  • Nog weinig ervaring met de wijze waarop architecturen beschreven moeten worden in een dergelijk landschap.

Kans

Aanzienlijk

Lopend

Loopt nu al

Tijdslijn

10 jaar tot stabilisatie

5. Borging en Governance van architectuur

Issue 5.1

Autonomie van de Business

Verschuiving ITà Business, waarbij Business de Technology Push geeft.

Omschrijving

De architectuur zal beter aansluiten op de behoefte van de organisatie. Dat maakt het eenvoudiger om verandering daadwerkelijk door te voeren. De business IT alignment zal vanuit een natuurlijker karakter vorm krijgen. (Het is niet IT die alignment oplegt aan de business, maar business die alignment oplegt aan IT). Minder onderscheid tussen business en IT, men moet integraal naar de organisatie kijken.

Probleem

  • De architectuur moet beter gaan aansluiten op de behoefte in de organisatie.
  • Het dient eenvoudiger te worden om veranderingen daadwerkelijk door te voeren.
  • De mensen in de business zijn gewend om privé allerlei apps / applicaties te kunnen downloaden. Het maken van onderscheid tussen je gedrag als privé persoon en als ‘werkend’ persoon (binnen een organisatie) verdwijnt: mensen willen dezelfde technologie op dezelfde manier kunnen betrekken zowel buiten het werk (privé) als op het werk.

Kans

Groot

Lopend

Loopt nu al

Tijdslijn

5-10 jaar (geholpen door de crisis)

Issue 5.2

Van vastleggen (IST) naar transformatie (‘area of change’) en het mogelijk maken van de transformatie.

Omschrijving

  • In aanvulling van het beschrijven van de targetarchitectuur gaat het nu ook om het aangeven van de weg er naartoe als ook het praktisch begeleiden en ondersteunen van de realisatie.
  • Dit noodzaakt ook tot het kiezen van een realistische – i.e. gegeven de omstandigheden bereikbare – target
  • Actief meewerken en betrokkenheid creëren leiden tot een betere samenwerking en alignment van business en IT.

Probleem

  • Mooie vergezichten (lees: targetarchitecturen) zijn niets waard als ze niet realistisch bereikbaar zijn.
  • Duidelijkheid over de bijdrage van een project (stap) in de weg naar de realisatie van de strategie / toekomstbeeld

Kans

Zeer groot

Lopend

Loopt nu al

Tijdslijn

2-5 jaar

Issue 5.3

Grotere bewustwording van het management.
Betrokkenheid van cruciale stakeholders, vooral in de business.

Omschrijving

  • Is organisatie afhankelijk, de maturity en de inrichting van de organisatie zelf.
  • Strategisch: op strategisch vlak wordt minder onderscheid gemaakt tussen business en IT.
  • Tactisch / operationeel: Meer aanbod / praktisch gedreven i.p.v. regie aangaande afstemming plaats en aanbod.

Probleem

Ivoren toren architectuur – architectuur die gezien wordt als een product van de architecten voor de architecten

Kans

Redelijk

Lopend

Loopt nu al (beginnend)

Tijdslijn

5-10 jaar

Issue 5.4

Formalisatie van de governance

Omschrijving

  • Governance – zowel de structuren als de producten – wordt door steeds meer organisaties expliciet ingericht. De structuren zorgen ervoor dat er minder onderscheid is tussen business en IT en dat de besluiten gezamenlijk zijn.
  • Executive als eigenaar van de architectuur – Long term strategic Architecture.
  • Beter functionerende governance creëert betere betrokkenheid.
  • Governance van architectuur moet passen in de cultuur van de organisatie.

Probleem

Projectoplossingen (korte termijn) die voorrang krijgen zonder goede afwegingen van lange(re) termijn effecten

Kans

groot

Lopend

Loopt nu al

Tijdslijn

2-5 jaar

Complexiteitsreductie door architectuur

Issue 6.1

Veel organisaties kampen met grote en complexe IT systemen. Deze complexiteit wordt veroorzaakt door een groot aantal businessfuncties die over een lange tijd (tot wel 50 jaar) tot stand zijn gekomen en op een soms willekeurige manier aan elkaar zijn gekoppeld. In het algemeen neemt de complexiteit met de jaren toe, als er geen aandacht aan wordt gegeven.

Omschrijving

Urgentie

Toenemende complexiteit wordt meer en meer als probleem ervaren door drie ontwikkelingen:

  1. Nieuwe functionaliteit wordt op steeds kortere termijn gevraagd, terwijl de complexiteit leidt tot juist langere ontwikkeltrajecten. Het belang van nieuwe ontwikkelingen wordt tevens steeds groter, zoals big data, cloud, en snelle commerciële ontwikkelingen bijvoorbeeld rond mobiel.
  2. De kosten van IT systemen nemen toe, terwijl de druk op de prijs vanuit de markt maakt dat er een grens zit aan deze kostenontwikkeling. Men kan kosten reduceren in een IT organisatie, maar uiteindelijk worden de kosten fundamenteel bepaald door de omvang en de complexiteit van het gehele IT systeem.
  3. De grote vloed aan oplossingen vanuit de cloud en de toenemende mate van outsourcing van processen en applicaties leidt tot een groter vraagstuk aan risicobeheersing op de totale dienstenketen van het bedrijf. Deze risicobeheersing wordt in zichzelf steeds complexer.

Deze ontwikkelingen maken dat wereldwijd veel bedrijven zoals bijvoorbeeld banken worstelen met de wijze waarop men de kosten en agility onder controle kan krijgen door de complexiteit te reduceren.

Probleem

Het eerste vraagstuk waar een organisatie tegen aan loopt als men de IT-complexiteit wil reduceren is het volgende: moeten wij het systeem in zijn geheel (of grotendeels) vervangen, of moeten wij de complexiteit reduceren door middel van re-architecting.

Het nadeel van vervanging is het enorme risico door onvoorzien oplopende kosten en door het langere tijd (>5 jaar) vastzitten aan een oplossingsrichting. Zo realiseert men zich dat het traject alleen tot complexiteitsreductie leidt als het wordt afgemaakt. Echter, gedurende die 5 jaar is het vermogen van de organisatie om in te spelen op vereisten vanuit de markt of regelgeving (te) zeer beperkt, met alle risico’s van dien.

Het nadeel van re-engineering is dat het traag gaat en gedurende langere tijd noodzakelijk is vast te houden aan een richting. Met andere woorden, er ligt een uitdaging op het vlak van governance. Een systeem dat op dit punt niet gemanaged wordt kent vooral toename in complexiteit. Het managen zodat met ieder project de complexiteit juist daalt vraagt constante en langdurige governance.

Oplossing

De oplossingen zijn primair organisatorisch van aard, maar kunnen goed worden ondersteund door IT middelen. Men moet dan denken aan:

  1. De business meenemen in de discussie en de urgentie bij hen onder de aandacht brengen en houden.
  2. Complexiteit meetbaar maken en KPI’s vaststellen hierop. Doet men dit niet, dan zegeviert de politiek van het moment over het lange termijn belang. Nieuwe manieren om de complexiteit meetbaar te maken zijn bijvoorbeeld de meting van de SCU (Standard Complexity Unit; ref. Robert Glass).
  3. Voor metrics van genoemde aard zijn repositories en code analyse tools noodzakelijk. Het objectief meten van complexiteit reduceert de politiek en maakt KPI’s hard. Een voorbeeld is UBS, die maandelijks de SCU meet voor haar systeem. Iedere invoering die in die maand gedaan wordt leidt tot toename of afname van de complexiteit, waarop managers kunnen worden afgerekend.

Lopend

Loopt nu al

Tijdslijn

1-15 jaar

Sponsoren

Sessies

15-02: GIA sessie over digitale transformatiespel meer...

19-03: NAF Insight met Jeanne Ross meer...

Advertenties

Je kunt hier adverteren

© 2018   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden