Document toolboxDocument toolbox

Phase A - Architecture Vision

Owned by Barry Nauta (Unlicensed)
Last updated: 21 Nov, 2023 by Paul Kiekens
10 min read

Navigation

 

Phase A - Architecture Vision

[TOGAF 9.2 | TOGAF 10]

 

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)

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)

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)

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)

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

Datum

Auteur

Dec 1, 2022

EA Support Team

 

 

Doelpubliek

Enterprise Architects, Solution Architects

Inhoudsopgave

Bijlage(n) / Link(s)