Het operationaliseren van een enterprise architectuur

by marc 12. augustus 2008 07:24

Daar zit je dan met enterprise architectuur framework, je ERP-pakket(ten), je COTS-applicaties, je legacy en je servicebus. Hoe vul je in de dagelijkse praktijk het gat tussen enerzijds een paar enterprise architecten met weliswaar goede bedoelingen maar een theoretisch georiënteerde helicopterview en anderzijds de IT-afdeling (technologie- en knustelgedreven) die voor de business (vanzelfsprekend businessgedreven) projecten uitvoert?

Dit is een korte, nog weing gestructureerde, inleiding in het thema om een enterprise architectuur van strategisch niveau ook naar tactische en operationeel te brengen en in te bedden.  Het operationeel maken van de architectuurprincipes zal van twee kanten moeten komen. Het (1) hanteren (en internaliseren) van architectuurprincipes als toetsingskader waartegen oplossingen gehouden moeten worden door de IT-consultants en (2) architectuurconsultancy vanuit architecten richting IT-consultants.   

Checklist Architect Toetsingscriteria Adaptieve Changes/ & Additieve changes

Doel: ontwerp- en bouwprocessen zoveel mogelijk baseren op architectuurproces. 

Vooraf te stellen vragen: is de doelarchitectuur/roadmap nog wel actueel? Heeft deze wel de status geaccordeerd? Is deze wel breed genoeg gecommuniceerd?  

Te stellen vragen door een IT consultant aan zichzelf als hij een oplossing bedenkt voor een door de business aangedragen wens/probleem/oplossing. De term change wordt hier gebruikt voor zowel een rfc die een minimale wijziging van bestaande functionaliteit betreft als voor een project dat omvangrijke nieuwe functionaliteiten introduceert en/of delen van systemen uitfaseert.

  •  Heeft change betrekking op data, setup, of op programmatuur? In geval van setup/parameterinstellingenà wat is de impact van wijziging, welke informatievoorziening/welke processen/welke programmatuur heeft hier mee te maken? In geval van programmatuur à wordt het aantal componenten verminderd, generieker bruikbaar?   
  • Heeft change betrekking op applicatie die uitgefaseerd wordt? Zo ja lost het een situatie op die überhaupt nog wel op zal treden, of zo weinig voordeel zal bieden dat het niet tegen de kosten opweegt?         
  • Heeft change betrekking op standaard programmatuur van de applicatie?
  • Brengt de change de doelsituatie dichterbij?
  • Hoever moet een organisatie gaan om standaardpakketten aan te passen vanuit het oogpunt van gebruikersvriendelijkheid? Wat zijn de criteria bij gevalletjes als ‘de gebruiker snapt dat niet.. die verwarrende dingen moeten weg..’

Hoe kun je zo’n gebruikerservaring meten? Hoe kun je meten of de gemiddelde gebruiker in zo’n geval wel zijn werk naar behoren kan doen/of aantoonbaar sneller iets kan vinden etc. Als deze informatie voorhanden is, dan is dat al heel wat en zal het over het algemeen lonen om de aanpassing door te voeren. Als niemand een eenvoudige niet-kostbare methode kan verzinnen om dit meetbaar te maken, dan is het dubieus of de aanpassing wel zinvol is.   

Zijn gebruikersvriendelijkheidseisen in deze zin anders dan functionaliteitseisen? Bij de keuze voor een COTS pakket is – als het goed is -  de eventuele instelbaarheid van gebruikersinterface een criterium geweest. De afweging is toen gemaakt om een bepaald pakket te kiezen, de gebruikersdoelgroep en hun kennis niveau is toen geinventariseerd. Dit zal over het algemeen niet wijzigen. Mag dit dan in een later stadium toch een argument zijn? De grote ERP pakketten zijn inderdaad eenmalig instelbaar, maar daarna juist heel moeilijk bijstelbaar..  

  • Zijn de businessparameters ook parameters in de oplossing? Een situatie als het hanteren van een andere basisvaluta in een applicatie (van NLG naar EUR) is niet vooraf in te stellen, als de business nu een product heeft dat ondersteund moet worden, dan zal er binnenkort een vergelijkbaar product op de markt komen, maar dan net wat anders. Is die ‘net anders’ situatie gevangen in instelbare parameters?       
  • Is schaalbaarheid geborgd? Kan het proces zowel kleine als grote volumes aan en is de werkwijze dan nog wel behapbaar voor gebruikers en beheerders?     
  • Is hergebruik van gelijksoortige bedrijfsfuncties mogelijk, binnen de grenzen van een informatiegebied , centrale, enkelvoudige vastlegging van persoonsgegevens.
  • Worden gegevens eenmalig bij de bron vastlgelegd, wordt redundantie voorzien van een reden, wordt elk gegevensitem maar in 1 applicatie beheerd, zijn identificerende gegevens door de hele keten aanwezig?       
  • Wordt in transactionele applicatie(modules) voorzien van een herstelfunctie, wordt verder op in de keten de mogelijkheid gecreerd foutieve aanleveringen te weigeren?
  • Wordt gebruikgemaakt van Corporate data?         
  • Past de toegang tot de applicatie/scherm/bestand in het grotere geheel van security, wordt gebruik gemaakt van de eventuele beschikbaarheid van single-sign-on?  

 

Architectuurconsultancy 

Waar IT-consultants bezig zijn met een concreet businessproject en vanuit dat perspectief richting de doelarchitectuur gekeken wordt, is een blik nodig vanuit de doelarchitectuur richting concrete businessprojecten. Als het goed is kom je elkaar in het midden tegen (na enkele discussies). De hierboven genoemde lijst met vragen is dus ook voor de architect van toepassing. Daarnaast is voor de architect toepassing om juist de kaders blijvend aan te scherpen. Het aanscherpen kan vanuit de volgende invalshoeken 

1.   Het voorkomen van onnodige complexiteit bij nieuwe initiatieven.

·         Innovatieve concepten beoordelen op hun risico’s

·         Selectief zijn bij het toepassen van alternatieve componenten, platforms e.d.,

·         Verspreiding van en toezien op het gebruik van standaarden en het generiek gebruiken van modules en componenten

·         Keuze maken voor lang houdbare oplossingen

·         Inwisselbaarheid van modules

·         Betrouwbaarheid leverancier.

2.   Het verminderen van de complexiteit van de staande IT voorzieningen

·         upgrades/uit- en infaseringeren van applicaties onderbrengen in projecten volgens een architectuurroadmap,

·         indelen naar bedrijfsproces en eigenaar t.b.v. bestuurbaarheid en kostentransparantie,

3.   Het inzichtelijk maken van/informeren over complexiteit in businessflows/procesketens en de uitwerking daarvan met IT-middelen.

·         hanteren van een enterprise architectuur framework

·         landschapplaatjes en beschrijvingen die vanuit verschillende perspectieven relevante kenmerken van (de complexiteit in businessflows/procesketens en de uitwerking daarvan met IT-middelen laten zien.

·         Kwantificeren van de complexiteit (niet alleen overlaten aan business cases in individuele projecten) 

4.  Het (ongevraagd) adviseren over:

·         Het bieden van een enterprise architectuur framework om bedrijfsmatige veranderingen snel te faciliteren ter verbetering van de time-to-market van producten,

·         het vormgeven van oplossingsconcepten voor de termijn die boven projecten uitgaat

·         het consequent aanvullen van oplossingsconcepten met generieke, maar vaak vergeten functionaliteiten zoals systeembeheer, uitwijk en security.

·         het zicht houden op IT initiatieven buiten het eigen domein en de synergievoordelen daaruit destilleren

Tags:

Mogelijk Interessant