Validation of Public Sector IT Architecture Leo F. Presentatie afstudeerwerk Juni 2011.

Presentatie over: "Validation of Public Sector IT Architecture Leo F. Presentatie afstudeerwerk Juni 2011."— Transcript van de presentatie:

1 Validation of Public Sector IT Architecture Leo F. Presentatie afstudeerwerk Juni 2011

2 Inhoud 1.Inleiding en aanleiding 2.Voorbereiding 3.Onderzoeksaanpak 4.Literatuur 5.Conclusie normstelling 6.Ontwerp framework 7.Test 8.Conclusie 9.Vragen en discussie

3 Inleiding en aanleiding

4 Waarneming grote overheidsprojecten Het gaat vrijwel altijd fout, ondanks: een voor de hand liggend idee veel inzet van dure expertise veel aandacht en actie van het management grote bestuurlijke en politieke aandacht Inleiding en aanleiding

5 Analyse Rekenkamer 2007-2008 Probleem: Projecten zijn te ambitieus en complex: kan niet goed gaan Oplossing: CIO’s benoemen Portfoliomanagement invoeren Enterprise architectuur Inleiding en aanleiding

6 Maar helpt architectuur op projectniveau? Enterprise architectuur meer norm dan oplossing Project (start) architectuur biedt niet altijd steun: Technisch verhaal Mini EA Continuering bestaande context Opportunisme (producten) Innovatie (cloud) Gebrekkige verbinding met bestaande praktijk Discussie over architectuur zelden vruchtbaar Wat is architectuur? Inleiding en aanleiding

7 Probleemstelling As the extensive research by the Court of Audit shows, large IT projects in the public sector often fail, even if a considerable amount of time and money has been spent on preparation. The court of audit advises further investment in IT architecture in order to improve the situation, but does not indicate how to establish when a project has invested enough in IT architecture. We do not dispose of standards or methods to establish ex ante if a given project architecture is of sufficient quality. Checking compliance with specific and easily measurable standards and criteria is not enough. Onderzoeksaanpak

8 Onderzoeksdoel The goal of this study is to develop an Architecture Validation Framework (AVF) for the validation of the architecture of such a system. The term ‘framework’ is chosen to indicate that within the scope of this research we develop a first version, even if it is tested in several concrete cases. Thorough validation of the framework is (far) beyond the scope of this research. Onderzoeksaanpak

9 Onderzoeksvragen 1.Conceptual analyses of what is meant by ‘IT architecture’. 2.What are the key quality aspects of an IT project architecture that should play a role in validation? 3.How can we operationalize IT architecture taking into account different levels of architecture and different approaches in current literature? 4.What are possible criteria per key quality aspect? 5.How can we operationalize these criteria so that they can be tested? 6.Is the AVF to be constructed on the basis of the aforementioned criteria on the one hand sufficiently general (fits different types of projects) and on the other hand sufficiently clear and concrete (can be used by a any professional meeting certain competence criteria). 7.What criteria can be formulated to establish if the AVF is successful in a test or not? Onderzoeksaanpak

10 Drie boeken over architectuur 1.Vitruvius, De Architectura, ca. 25 v.C. 2.Christopher Alexander, Notes on the Synthesis of Form, 1965 3.James Scott, Seeing like a State, 1998 Literatuur

11 Vitruvius Architect ‘in overheidsdienst’ Werkte aan verdedigingswerken en watervoorziening Leefde in een tijd van opbouw en expansie De Architectura bedoeld om architectuur te kunnen beoordelen Literatuur

12 Vitruvius Begrip architectuur: geen nadere duiding Goede architectuur: proces bepaalt resultaat: De opdrachtgever kiest de architect Opleiding architect zeer breed, niet alleen technisch Ervaring even belangrijk als opleiding Architect verantwoordelijk voor kosten Persoonlijke eigenschappen: meer dan integer, altruïstisch Literatuur

13 Vitruvius Rol ‘firmitas, utilitas, venustas’ is beperkt Gezondheid komt steeds terug Aantrekkelijkheid voor de gebruiker ook Literatuur

14 Analyse Vitruvius Brede opleiding + brede rol vormen een indicatie dat de boodschap van Vitruvius eigenlijk was dat inductie onvermijdelijk is en dat je de condities voor de goede werking ervan moet creëren om goede architectuur te krijgen. Keuze van de architect door opdrachtgever geeft krediet, want de oplossing is niet bewijsbaar. Literatuur

15 Conclusie Vitruvius Architectuur is kwalitatief begrip rustend op drie pijlers: Verhouding tot de opdrachtgever Opleiding, ervaring en persoonlijke eigenschappen architect Rol van inductie De eerste twee zijn door de opdrachtgever te beïnvloeden, daarmee creëert hij de condities voor de derde. Literatuur

16 Christopher Alexander Wiskundige en architect(uurtheoreticus) Bijna 40 jaar hoogleraar Berkeley Bijna bekender in de ICT dan in de bouwkunde Heeft het ontwerpprobleem fundamenteel beschouwd Literatuur

17

18

19 Analyse Christopher Alexander ‘Notes’ poging om ontwerp uit te rekenen: deductie In de 1971 editie neemt hij er volledig afstand van, de deductie berust geheel op zachte input: koers rechtstreeks op het constructieve diagram: inductie Sterke nadruk op roeping van de architect Geleidelijk steeds meer opgeschoven richting iteratief ontwerpen in de context, met gebruikers, combinatie van architect en bouwer optimaal Kwaliteit is objectief, maar ‘quality without a name’ Literatuur

20 Conclusie Christopher Alexander Architectuur is gebaseerd op inductie: wordt gekenmerkt door inductie. De architect heeft een zware persoonlijke verantwoordelijkheid voor een superieur resultaat maar ook voor kosten. Goede architectuur ontstaat door het goede proces (groei, in de context) en heeft ‘objectieve’ ervaren kwaliteit. Literatuur

21 James Scott Hoogleraar Yale Agrarian Studies Onderzocht effecitiviteit ruimtelijke ordening maatregelen in ontwikkelingslanden Literatuur

22 James Scott ‘Seeing like a state’; waarom goede bedoelingen soms tot niets leiden Om de werkelijkheid overtuigend tot object van beleid te kunnen maken moet deze gereduceerd worden De neiging kan bestaan om de werkelijkheid aan te passen als reductie tekort schiet Literatuur

23 James Scott Reductie: Alleen die aspecten van het sociale leven die van officieel belang zijn worden beschouwd Alleen documentaire informatie telt (aantallen, beschrijvingen) Alleen relatief statische feiten tellen Belangrijke feiten zijn vaak geaggregeerde feiten Gehanteerde standaardisering en categorisering dient vaak om mensen in groepen in te delen Aanpassing: Vaak in de vorm van social engineering Gevaarlijke vorm: high modernism, met machtsmiddelen ingevoerd, verzwakte burgerlijke samenleving. Literatuur

24 James Scott Risico: Er is een sterke neiging de mogelijkheden van centrale planning te overschatten als dit betrekking heeft op de interactie van mensen met hun omgeving, met name in het publieke domein. Omgekeerd is er de neiging om het probleemoplossend vermogen van bestaande structuren van sociale interactie te onderschatten. Maatregel: werk vanuit bescheidenheid en interactief, kleine stappen kies bij voorkeur omkeerbare maatregelen houd rekening met verrassingen houd rekening met menselijke inventiviteit Literatuur

25 Conclusie James Scott Kies voor een groeimodel waar mogelijk Kies oplossingen die de kennis, vaardigheden, betrokkenheid en ervaring van gebruikers vergroten Oplossingen die aantrekkelijk zijn voor gebruikers hebben een grotere kans van slagen Literatuur

26 Vertaling naar IT architectuur Vitruvius is herkenbaar omdat er enerzijds naadloze aansluiting is bij de moderne rol van de architect, anderzijds architectuur minder was ontwikkeld. IT architectuur nu kun je vergelijken met bouwarchitectuur toen. Bevindingen Alexander en Scott zijn fundamenteel, los van toepassingsdomein. Werken volgens groeimodel zelfs beter mogelijk in IT dan in de bouwwereld. Literatuur

27 Confrontatie met de literatuur uit het vakgebied IT IT-literatuur zeer overwegend methodegericht: benadrukken van het engineering paradigma: deductie Uitzondering: Rechtin, The Art of Systems Engineering Literatuur

28 Rechtin Vier methodologieën voor systems architecting Science, engineering, deductive Normatief (vaste regels) Rationeel analytisch (methodisch) Art, inductive Participatief (belanghebbenden) Heuristisch (kennis gebaseerd, ervaring) Art is wat de architect zelf doet, de engineering maakt hij gebruik van. Literatuur

29 Rechtin Fundamentals of architecting Systems architecting wordt gekenmerkt door: A systems approach A purpose orientation A modelling methodology Ultra quality implementation Certification Insight Literatuur

30 Rechtin Volwassenheidscriteria Erkenning van de noodzaak van architectuur door opdrachtgever en andere betrokkenen Erkenning van architect als de specialist Standaarden, methoden, technieken, organisaties Onderling (h)erkende verdeling van verantwoordelijkheden tussen opdrachtgever, architect en aannemer Erkenning van de rol van inductie en deductie Architectuurteams van master/doctor niveau Literatuur

31 Algemene beeld: eenduidigheid in de literatuur: -Architect: opleiding, ervaring persoonlijke eigenschappen -Architect bedient zich van de techniek en is deskundig, maar de engineering mag iemand anders doen -Inductie, in elk geval niet alleen deductie -Architect staat dicht bij de opdrachtgever; vertaalt diens ambitie in een aantrekkelijk perspectief incl. business case -Geeft de opdrachtgever keuzes die hij kan overzien -Aantrekkelijk ook voor de gebruiker/context -Stapsgewijze werken, interactie met de context Afwijkende meningen Architect-bouwer (Alexander): ik kies voor zuiverheid van de rol IT specifiek -Ultra quality in software engineering problematisch Conclusie normstelling

32 Uitgangspunten Hoe vroeger je problemen signaleert hoe beter Toepassing door niet-architecten Eenvoud en genericiteit: geen varianten Resultaat bestuurlijk uit te leggen Ontwerp framework

33 Match criteria met uitgangspunten Vroeg correspondeert naadloos met opdrachtverlening architect die cruciale factor is Toepassing door niet-architecten zeker mogelijk Eenvoud en genericiteit aanwezig Criteria zijn voldoende objectiveerbaar Resultaat is bestuurlijk uit te leggen door eenvoud, genericiteit en objectiveerbaarheid. Past verder bij Gateway review. Ontwerp framework

34 Casus is perfecte match met Gateway Review 0 Strategische uitgangspunten en haalbaarheid Uitgevoerd voor projectstart en daarna zo vaak als nodig Uitgevoerd door peers Resultaat vertrouwelijk aan opdrachtgever: groen, oranje, rood. Gateway Reviews zijn bestaand beleid Gezag reviewer wel belangrijk en vertrouwelijkheid problematisch Ontwerp framework

35 Resultaat Lijst vragen toe te passen in kader Gateway Review 0 Toelichting Ontwerp framework

36 Aanpak test Toepassen op enkele casus Beoordeling resultaat door vier professionals: twee ervaren architecten en twee auditors Test

37 Casus Rekeningrijden Elektronisch Patiënten Dossier Test

38 Probleem testen: Achteraf Je krijgt niet altijd makkelijk toegang tot materiaal en vooral mensen. Test

39 Rekeningrijden scoort slecht op alle punten Nauwelijks aandacht voor rol architect: draaide om politiek, projectmanagement en leveranciers Ontwerp was technische exercitie: alle keuzes zijn ‘technisch’ of ‘optimalisatie’, maar wel uniek en innovatief, geen beproefd concept gekopieerd. Inductie ontbreekt Er is veel geïnvesteerd in maatschappelijk draagvlak via intermediaire organisaties, maar het is niet aantrekkelijk gemaakt Niet stapsgewijs, het moest in één keer Project ondoorzichtig, documentatie ‘geheim’ Privacy issues en incl. mogelijkheid snelheidscontrole defensief benaderd Test

40 EPD scoort beter, maar toch onvoldoende Herkenbare architect stabiel ingezet gedurende hele projectduur, wel ondergeschikt in relatie tot projectmanagement Openheid en kwaliteit documentatie voorbeeldig: alles op internet De aantrekkelijkheid is niet aannemelijk gemaakt, behalve voor chronisch zieken Er is wel stapsgewijs ontwikkeld maar daar had niemand wat aan: het landelijk schakelpunt draait Privacy issues defensief benaderd Fatale fout (m.i.): tot 2005 is gepoogd het geheel samen te ontwikkelen met de bestaande regionale systemen, daarna is besloten het in één keer van bovenaf op te leggen en de regionale systemen verder te negeren Test

41 Conclusie: De voorgestelde aanpak lijkt effectief om het risico van mislukkende grote ICT projecten te verkleinen. Met een eenvoudige checklist kun je – aansluitend bij het al gevestigde Gateway instrumentarium - in een heel vroeg stadium checken of het besef van de noodzaak van architectuur bij de betrokkenen aanwezig is Later in het traject kun je stapsgewijze aanpak checken plus business case Nog weer later of aanpak plus perspectief aantrekkelijk wordt gevonden door de betrokkenen Conclusie

42 Nader te onderzoeken Internationaal vergelijkend onderzoek nodig naar instrumenten voor risicomanagement in relatie tot projectresultaten Architectuur van grote complexe systemen is een team aangelegenheid: wie is dan de architect, en hoe werkt dan inductie Nader onderzoek

43 Einde