Phase A - Architecture Vision
Navigation
Vorige phase - Preliminary phase
Volgende phase - Phase B - Business Architecture
- 1 Phase A - Architecture Vision
- 1.1 Establish the Architecture Project
- 1.1.1 Aanbeveling(en)
- 1.2 Identify Stakeholders, Concerns, and Business Requirements
- 1.2.1 Aanbeveling(en)
- 1.2.2 Blueprint
- 1.3 Confirm and Elaborate Business Goals, Business Drivers, and Constraints
- 1.3.1 Aanbeveling(en)
- 1.3.2 Blueprint
- 1.4 Evaluate Business Capabilities
- 1.4.1 Aanbeveling(en)
- 1.4.2 Blueprint
- 1.5 Assess Readiness for Business Transformation
- 1.5.1 De prijs van complexiteit
- 1.5.2 Beheren van complexiteit
- 1.5.3 Aanbeveling(en)
- 1.6 Define Scope
- 1.6.1 Aanbeveling(en)
- 1.7 Confirm and Elaborate Architecture Principles, including Business Principles
- 1.7.1 Aanbeveling(en)
- 1.8 Develop Architecture Vision
- 1.8.1 Aanbeveling(en)
- 1.8.2 Blueprint
- 1.9 Define the Target Architecture Value Propositions and KPIs
- 1.9.1 Aanbeveling(en)
- 1.10 Identify the Business Transformation Risks and Mitigation Activities
- 1.10.1 Aanbeveling(en)
- 1.11 Develop Statement of Architecture Work; Secure Approval
- 1.11.1 Aanbeveling(en)
- 1.12 Afsluitend
- 1.13 Versie
- 1.14 Doelpubliek
- 1.15 Inhoudsopgave
- 1.16 Bijlage(n) / Link(s)
- 1.1 Establish the Architecture Project
Phase A - Architecture Vision
Establish the Architecture Project
Aanbeveling(en)
In elke fase van de ADM bekijken we Requirements Management waarbij, afhankelijk van de context of de ADM fase, we andere requirements en constraints evalueren en documenteren.
Identify Stakeholders, Concerns, and Business Requirements
Hoe groter het project, hoe groter de veranderingen die worden doorgevoerd. Deze veranderingen kunnen grote impact hebben op de manier waarop mensen werken en samenwerken. Change management wordt vaak onderschat of zelfs niet meegenomen, terwijl een verandering pas succesvol kan zijn als deze ondersteund wordt door alle betrokken partijen.
Volg je de TOGAF iets stricter, dan documenteer je de stakeholders in een ‘Stakeholder map matrix’.
Aanbeveling(en)
Maak een lijst van alle stakeholders, hun motivatie en bezorgdheden. Zorg ervoor dat je niet teveel op de hiërarchische structuren focust en bekijk ook de ‘informele’ stakeholders. Vergeet hierbij zeker het security aspect niet (CISO, DPO, Legal, ….)
Classificeer de stakeholders ook naar hun rollen en verantwoordelijkheden. Meer informatie: https://vlaamseoverheid.atlassian.net/wiki/spaces/EAP/pages/6131649766
Neem change management mee als basis element in de transformatie. We werken met mensen, de impact van de transformatie kan grote gevolgen hebben. Voor meer informatie: Change management
Maak zeker de link met Requirements Management
Blueprint
De motivational elementen worden typisch toegevoegd aan de “Public Service”. Hieronder zie je een voorbeeld, we maken gebruik van een placeholder:
Confirm and Elaborate Business Goals, Business Drivers, and Constraints
Waneer deze al gedefinieerd zijn, bekijk of de beschikbare documentatie nog up-to-date is. Bekijk niet alleen de beperkingen binnen de context van het project maar ook deze van het agentschap.
Moderne architecture worden vaak geployed in een public cloud omgeving. Dit is een speciaal aandachtspunt voor persoons-gevoelige data. Bepaal zo vroeg mogelijk de cloud strategie en impact op de transformatie. Deze keuze heeft verregaande gevolgen voor de kosten, doorlooptijd, risico's en architectuur keuzes van de transformatie!
Wanneer met het https://vlaamseoverheid.atlassian.net/wiki/spaces/EAP/pages/6086787137 Principe hanteert is het belangrijk om te kijken of het pakket (COTS) dat men aan wil schaffen wel aan de cloud vereisten voldoet.
Breng de risico’s en mitigerende acties in kaart, kijk hiervoor naar Risico management / SWOT
Aanbeveling(en)
Maak zeker de link met Requirements Management . Wanneer er onduidelijkheden zijn rond bepaalde constraints (zoals bijvoorbeeld privacy gevoelige informatie en de verwerking daarvan) betrek de juiste mensen vroegtijdig (in het geval van het voorbeeld de DPO’s van de betrokken entiteiten).
Evalueer zo snel mogelijk de mogelijkheden mbt cloud adoptatie en de impact hiervan. Betrek DPOs, Legal, security experts en meer. Probeer alvast een antwoord te vinden op data beveiliging (voor meer uitleg; zie: Afkortingenlijst):
DIM - Data in motion
DIU - Data in use
DAR - Data at rest
Blueprint
De motivational elementen worden typisch toegevoegd aan de “Public Service”. Hieronder zie je een voorbeeld, we maken gebruik van een placeholder:
Evaluate Business Capabilities
Een gedetaileerde analyse van de (business) capabilities vindt typisch plaats in Phase B - Business Architecture maar het is zeker al nuttig om nu al te kijken welke capabilities er zijn om de mogelijkheden te bekijken om de transformatie te ondersteunen vanuit architecturaal en resource standpunt.
https://www.opengroup.org/it4it definieert een value stream specifiek toegepast op “IT als business” en die ziet er als volgt uit:
De Strategy to Portfolio (S2P) Value Stream bekijkt strategische verzoeken voor nieuwe of verbeterde diensten van de business of IT zelf en ontwikkelt de Conceptuele Service blueprint om de nieuwe of verbeterde business/IT dienst weer te geven die wordt gevraagd.
De Requirement to Deploy (R2D) Value Stream bouwt verder op de Conceptual Service Blueprint en ontwerpt en ontwikkelt het Logical Service Model met meer gedetailleerde requirements die beschrijven hoe de nieuwe gevraagde business/IT service en zijn componenten moeten worden ontworpen. Het Logical Service Model kan worden gezien als wat traditioneel in IT-termen wordt uitgedrukt als het "systeemontwerp".
De Request to Fulfill (R2F) Value Stream gaat verder met de Logical Service Blueprint nadat het door ontwikkeling, test, en vrijgave goedkeuring is gegaan.
De Detect to Correct (D2C) Value Stream biedt een raamwerk voor het integreren van de monitoring, management, herstel, en andere operationele aspecten geassocieerd met gerealiseerde diensten en/of diensten in aanbouw.
Een voorbeeld van een capability map is de volgende
Aanbeveling(en)
Evalueer de capabilities en plaats deze op een value chain. Hoe helpen de verschillende capabilities waarde te creëren?
Blueprint
Het strategisch luik van de oplossing wordt typisch niet opgenomen in een blueprint maar wordt gemodelleerd op een aparte view gebruik makend van het ArchiMate strategy viewpoint.
Assess Readiness for Business Transformation
Zoals aangegeven is change management van cruciaal belang voor het slagen van een transformatie. TOGAF geeft hiervoor een template die gebruikt kan worden die naast het persoonlijke aspect ook kijkt naar capabilities, funding en meer.
Een transformatie houdt typisch ook in dat er een roadmap wordt opgesteld. We gaan van een base-architecture naar een target-architecture.
Gregor's Law: Excessive complexity is nature's punishment for organizations that are unable to make decisions.
Het uitwerken van een current architecture (as-is, landscape, ….) wordt uitgewerkt op alle lagen van een architectuur (Phase B - Business Architecture, https://vlaamseoverheid.atlassian.net/wiki/spaces/EAP/pages/6139249051 en https://vlaamseoverheid.atlassian.net/wiki/spaces/EAP/pages/6139544760).
Het opstellen van een current architecture, roadmap en target architecture geeft in ieder geval de volgende voordelen:
Transparantie en overzichtelijke informatie
Flexibiliteit
Kost efficientie (of in ieder geval meer inzicht in kosten)
Duidelijke identificatie bouwstenen en waar ze gebruikt worden (integratie opties)
Globale ipv lokale optimalisatie
De prijs van complexiteit
Complexiteit heeft veel problemen
Hoge kost - het onderhouden van meer puzzlestukjes vraagt meer effort en een grotere skill set
Verlaagde betrouwbaarheid. Complexe systemen, zeker waneer deze geconnecteerd zijn met andere complexe systemen, hebben slecht begrepen failure states en recovery paths. Dit geeft een lagere MTBF en een hogere MTTR
Hogere kwetsbaarheid - Simpelere systemen zijn beter onder controle en de kans dat hierin een “weak link” is (verkeerde configuratie, vergeten patch, default hidden password, ….), is beduidend lager.
Beheren van complexiteit
(source: https://architectelevator.com/architecture/it-complexity/ )
Technologie blijft versnellen, complexiteit is moeilijk beheersbaar, daarom moeten we zorgen voor:
Transparantie - complexiteit is twee maal zo erg wanneer we complexiteit verborgen is.
Architecture - modellen en abstractie om irrelevante complexiteit te verbergen om zo het beslissingsproces beter te kunnen ondersteunen. You can’t manage what you can’t understand
Standaarden - inzetten op open interface standaarden
Aanbeveling(en)
Change management - Wanneer je zelf de change wil doorvoeren, dan zijn de 8 stappen van Kotter interessant om eens te bekijken. Wil je eerder naar de impact van wijzigingen op individuen bekijken, kijk dan eens naar Prosci ADKAR.
Bekijk hoe je complexiteit onder controle houden - transparantie, duidelijke architectuur (modellen) en gebruik standaarden. Kijk naar https://mitpress.mit.edu/9780262542760/designed-for-digital/ om input te krijgen hoe het best naar componentisatie en hergebruik te kijken.
Define Scope
Bepaal wat binnen en wat buiten de reikwijdte valt van de base-architecture en de target-architecture, met dien verstande dat de base- en de target-architecture niet op hetzelfde detailniveau hoeven te worden beschreven. In veel gevallen wordt de baseline op een hoger abstractieniveau beschreven, zodat er meer tijd beschikbaar is om het doel in voldoende detail te specificeren.
Hoeveel tijd wil je besteden aan architectuur, welk niveau van detail, hoe breed gaat de architectuur (binnen een afdeling, over afdelingen heen, …)? Zijn er bepaalde domeinen die meer aandacht verdienen (Business, Data, Application, Technology) en waarom?
Aanbeveling(en)
Evalueer en plan de 4 domeinen van “architecture scope”:
Breedte
Diepte
Tijdsbesteding
Architecture domains (BDAT)
Dit document spreekt altijd over een “Baseline”, een “Target” en een “Gap”. Hier moet men de volgende afweging maken: Wanneer het om een totale herwerking van een bepaalde oplossing gaat, of een greenfield oplossing, dan is ofwel niet nuttig (te evalueren) of niet mogelijk om een baseline te creëren. En wanneer er geen baseline is, dan is de gap ook impliciet, nl van. niet bestaand naar de target. M.a.w. het is niet altijd nuttig om alle stappen volledig te volgen, pick-and-chose, don’t overarchitect!
Confirm and Elaborate Architecture Principles, including Business Principles
Herziening van de principes op grond waarvan de architectuur moet worden ontwikkeld. De architectuurprincipes zijn normaliter gebaseerd op de architectuurprincipes die in het kader van de Preliminary phase zijn ontwikkeld . Controleer of de bestaande definities actueel zijn, en verduidelijk eventuele onduidelijkheden.
Aanbeveling(en)
Zorg ervoor de dat lijst met principes (geïdentificeerd in de Preliminary phase) correct en volledig is en werk onduidelijkheden weg, vul aan waar nodig.
Develop Architecture Vision
TOGAF® v9.2 vermeldt het volgende: Gebaseerd op de stakeholder concerns, business capability requirements, scope, constraints, en principles, creëer een high-level view van de Baseline en Target Architectures. Informele technieken worden vaak gebruikt. Een gebruikelijke praktijk is het tekenen van een eenvoudig “Solution Concept Diagram” dat beknopt de belangrijkste componenten van de oplossing illustreert en hoe de oplossing zal resulteren in voordeel voor de onderneming.
Binnen onze context werken we dus verder aan de Blueprint die gebaseerd is op de https://vlaamseoverheid.atlassian.net/wiki/spaces/EAP/pages/6082789831. We maken nu voor het eerst een duidelijk onderscheid tussen de bestaande oplossing (baseline) en waar we naar toe willen gaan (target) en geven al high-level een aantal mogelijkheden aan om de afstand hiertussen (de gap) te overbruggen. Dit doen we door een high-level roadmap te presenteren waarin we verschillende alternatieve paden presenteren.
Aanbeveling(en)
Bekijk de https://vlaamseoverheid.atlassian.net/wiki/spaces/EAP/pages/5624792128 en identificeer welke solution building blocks (lees: bestaande oplossingen die hergebruikt kunnen worden) in de oplossing een plaats kunnen vinden.
Geef de geïdentificeerde building blocks een plaats in de Blueprint die je aan het ontwikkelen bent.
Geef ook aan welke SBBs wel potentieel in aanmerking zouden komen, maar waarom deze niet gebruikt zijn in deze context.
Definieer op voorhand hoe ‘reusable’ je wit dat de oplossing gaat zijn. Gebruik hiervoor de https://joinup.ec.europa.eu/collection/european-interoperability-reference-architecture-eira/solution/reusability-quick-assessment-toolkit/release/v120 assessment toolkit.
Maak een duidelijk onderscheid tussen de huidige situatie (baseline) en toekomstige situatie (target) en presenteer al enkele paden (roadmap) om deze transformatie te ondersteunen.
Blueprint
We maken typisch gebruik van een grouping element die aangeeft welke (externe) building blocks gebruikt worden, maar dit is eerder een conventie dan een regel.
Hier wordt er gebruik gemaakt van een simpele associatie, als het mogelijk is om een meer explicietere relatie te leggen is dat natuurlijk beter.
Define the Target Architecture Value Propositions and KPIs
Ontwikkel de business case voor de veranderingen en stel een value proposition op elk van de stakeholders. Wanneer men overgaat tot het aankopen van een (gedeeltelijke) oplossing (zie ook het architecture principle: https://vlaamseoverheid.atlassian.net/wiki/spaces/EAP/pages/6086787137), neem de requirements voor de aankoop mee vanuit een architecturaal standpunt. Bepaal de KPIs / OKRs (op een https://vlaamseoverheid.atlassian.net/wiki/spaces/EAP/pages/6142034095 manier!) die in de architectuur werking moeten worden ingevoerd om aan te behoeften te voldoen en de architectuur werking mogelijks bij te sturen wanneer bepaalde KPIs / OKRs niet gehaald worden (zie ook: https://vlaamseoverheid.atlassian.net/wiki/spaces/EAP/pages/6142066844).
In de context van de overheid is het gebruik van de cloud een groot discussie punt, het is het beste om hier zo snel mogelijk duidelijkheid over te krijgen. Kijk hiervoor naar de “VO Cloud Strategie” maar kijk ook naar de VTC adviezen: https://overheid.vlaanderen.be/vlaamse-toezichtcommissie-advies-cloud-kort en https://overheid.vlaanderen.be/digitale-overheid/informatieveiligheid/vlaamse-toezichtcommissie-cloud n.a.v. het gebruik van data en het Schrems II arrest.
Aanbeveling(en)
Ontwikkel de business case, bekijk de architecturale impact bij potentiële (gedeeltelijke) uitbesteding en stel KPIs / OKRs (zie ook: https://vlaamseoverheid.atlassian.net/wiki/spaces/EAP/pages/6142066844) voor de architecturale werking op.
Gebruik voor het opstellen van KPI’s / OKR’s https://vlaamseoverheid.atlassian.net/wiki/spaces/EAP/pages/6142034095 doelstellingen.
Identify the Business Transformation Risks and Mitigation Activities
Er zijn altijd risico’s verbonden aan transformaties. Evalueer de risico's en documenteer mogelijke mitigating actions. Belangrijk om te begrijpen is dat het aan de architect is om de risico’s te identificeren en in kaart te brengen, maar dat het uiteindelijk de ‘governance body’ (die al opgezet is in de Preliminary phase) is die de uiteindelijke beslissing neemt en het risico in beheer neemt. Meer informatie: Risico management / SWOT
TOGAF heeft een gelijkaardige matrix. Meer uitleg is hier te vinden: https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap27.html#tag_27
Aanbeveling(en)
Identificeer en evalueer de risico's, documenteer deze en bekijk mitigating actions. Bedenk hoe je risico’s wilt monitoren. Zie ook: Risico management / SWOT
Het managen / monitoren van risico’s gebeurt in https://vlaamseoverheid.atlassian.net/wiki/spaces/EAP/pages/6139249590
Develop Statement of Architecture Work; Secure Approval
Beoordeel de werkproducten die moeten worden geproduceerd (en tegen wanneer) tegen de business requirements. Dit houdt in dat ervoor gezorgd moet worden dat performance metrics zijn ingebouwd in de werkproducten en dat specifieke prestatie-gerelateerde werkproducten (typisch assets) beschikbaar zijn.
Aanbeveling(en)
Overleg of presenteer alle documentatie aan de sponsor van de transformatie en zorg dat er overeenstemming is over de te volgen weg, over de volgende stappen. Dit kan op een formele manier gedaan worden, maar mag zeker ook op een informele manier tot stand komen.
Afsluitend
De “Architecture Repository” breiden we verder uit:
[Project naam]
Doelstellingen en scope
Stakeholder Map Matrix
Decision log
Team setup (rollen, verantwoordelijkheden)
Architecture principes, guidelines en policies
Informatieclassificatie
Requirements Catalog
Functional Requirements
Constraints
Quality attributes / Non-Functional Requirements
Reference models, viewpoints en tools
Blueprint
Versie
Datum | Auteur |
---|---|
Dec 1, 2022 | EA Support Team |
|
|
Doelpubliek
Enterprise Architects, Solution Architects
Inhoudsopgave
- 1 Phase A - Architecture Vision
- 1.1 Establish the Architecture Project
- 1.1.1 Aanbeveling(en)
- 1.2 Identify Stakeholders, Concerns, and Business Requirements
- 1.2.1 Aanbeveling(en)
- 1.2.2 Blueprint
- 1.3 Confirm and Elaborate Business Goals, Business Drivers, and Constraints
- 1.3.1 Aanbeveling(en)
- 1.3.2 Blueprint
- 1.4 Evaluate Business Capabilities
- 1.4.1 Aanbeveling(en)
- 1.4.2 Blueprint
- 1.5 Assess Readiness for Business Transformation
- 1.5.1 De prijs van complexiteit
- 1.5.2 Beheren van complexiteit
- 1.5.3 Aanbeveling(en)
- 1.6 Define Scope
- 1.6.1 Aanbeveling(en)
- 1.7 Confirm and Elaborate Architecture Principles, including Business Principles
- 1.7.1 Aanbeveling(en)
- 1.8 Develop Architecture Vision
- 1.8.1 Aanbeveling(en)
- 1.8.2 Blueprint
- 1.9 Define the Target Architecture Value Propositions and KPIs
- 1.9.1 Aanbeveling(en)
- 1.10 Identify the Business Transformation Risks and Mitigation Activities
- 1.10.1 Aanbeveling(en)
- 1.11 Develop Statement of Architecture Work; Secure Approval
- 1.11.1 Aanbeveling(en)
- 1.12 Afsluitend
- 1.13 Versie
- 1.14 Doelpubliek
- 1.15 Inhoudsopgave
- 1.16 Bijlage(n) / Link(s)
- 1.1 Establish the Architecture Project
Bijlage(n) / Link(s)
Change management - Kotter
Change management - Prosci ADKAR
https://vlaamseoverheid.atlassian.net/wiki/spaces/EAP/pages/6082789831
https://vlaamseoverheid.atlassian.net/wiki/spaces/EAP/pages/6086787137
https://vlaamseoverheid.atlassian.net/wiki/spaces/EAP/pages/5624792128
https://vlaamseoverheid.atlassian.net/wiki/spaces/EAP/pages/6142034095
https://vlaamseoverheid.atlassian.net/wiki/spaces/EAP/pages/6142066844
https://vlaamseoverheid.atlassian.net/wiki/spaces/EAP/pages/6086787137
https://vlaamseoverheid.atlassian.net/wiki/spaces/EAP/pages/6131649766
https://overheid.vlaanderen.be/sites/default/files/VO Cloudstrategie.pdf
https://overheid.vlaanderen.be/vlaamse-toezichtcommissie-advies-cloud-kort
https://mitpress.mit.edu/9780262542760/designed-for-digital/