Agile architectuur met het Information System Canvas

Agile architectuur met het Information System Canvas
IT-architecten werken met methoden. Dat schept herkenbaarheid en eenduidige interpretatie van artefacten. Maar methodisch werken staat haaks op snelle oplevering. Hoe combineer je het nut van methoden met de eenvoud van een schets op een whiteboard? Probeer het eens met het Information System Canvas.
Architectuur staat voor overzicht en samenhang. Zorgen dat een projectdeliverable zowel intern handig gestructureerd is als extern aansluit op bestaande IT-systemen en op relevante bedrijfseisen. Die interne structuur draagt bij aan de efficiëntie van project en beheer.
Denk daarbij aan hergebruik, testbaarheid en onderhoud. Externe aansluiting gaat over de bijdrage aan beheersing van bedrijfsrisico, total cost of ownership (TCO) en time to market (TTM). Naast de architect werken natuurlijk ook anderen aan die interne en externe architectuur. Maar de architect schept het eerste overzicht en reduceert complexiteit door de gewenste verandering in hanteerbare brokken te verdelen voor verdere analyse, ontwerp en realisatie.
Dit klinkt meer als ‘waterval’ dan als ‘agile’. Terwijl we juist het risico van ‘analysis paralysis’ willen vermijden door direct op dag één (klein) te beginnen met analyse, ontwerp én realisatie? Gaandeweg kun je dan je best practices en (daar mee) je efficiëntie verbeteren. Dat is de basis van agile ontwikkelmethoden als Scrum. In deze visie kun je op twee manieren tegen architectuur aankijken. Architectuur ‘ontstaat’ als gevolg van de beslissingen van het Scrum-team, al dan niet met een architect aan boord. Of: architectuur is ‘ingebakken’ in de feature requests van de product backlog, gemanaged door de product owner uit naam van de belanghebbenden bij kostenbeheersing en wendbaarheid. Bij de eerste manier heb je het meestal over interne architectuur, bij de tweede over externe architectuur.
Voortraject
Die externe architectuur moet er dan wel zijn als de backlog wordt opgesteld. Sterker nog, al bij een beetje serieuze investeringsbeslissing heb je ‘m nodig: om de grootste kosten en risico’s in kaart te brengen. In de praktijk zie je bij commerciële organisaties dan ook dat hoe groter de investering is, des te vaker eerst een onafhankelijk voortraject gerund wordt met een architect aan het roer – of minimaal een consultant met een behoorlijke dosis architectuurgevoel. Gaat het om relatief kleine investeringen, of om organisaties met ruime budgetten en weinig ‘risk ownership’, dan is het geduld voor architectuur minder groot. Je zou dan zelfs kunnen werken ‘zonder architectuur’ vooraf; zowel externe als interne architectuur ontstaat dan pas in het ontwikkelteam. Kortom, de ruimte voor architectuur vooraf is grotendeels situationeel bepaald. Natuurlijk hangt het er ook van af hoe goed de architect in staat is om de kosten en risico’s van werken zonder architectuur over de bühne te krijgen. Die worden namelijk wel eens onderschat. Dat komt enerzijds door wensdenken, en anderzijds doordat ervaringscijfers daarover meestal achterlopen op de realiteit. Dit door almaar voortschrijdende connectiviteit en alomtegenwoordigheid van functionaliteit.
Architectuurmethoden
Welk houvast bieden de gebruikelijke architectuurmethoden om mee te bewegen met tijdslijnen die beïnvloed worden door wisselende kostendruk en risicobereidheid? Ik heb namelijk nog geen organisatie gezien waar het opleverritme wordt bepaald door het architectuurproces. In het gunstigste geval zit de architect op gezette tijden aan bij de beoordeling van lopende en op te starten projecten. Standaardmethoden beschrijven meestal een ide-ale situatie, te configureren naar behoefte, maar zonder duidelijke als-dan stuurparameters. Je kunt ze zien als een uitgebreide checklist om naar eigen bevind van zaken te bepalen welke acties en artefacten hoe ingezet moeten worden. Daarmee neemt de herkenbaarheid van die acties en artefacten wel af. Het gemak van een standaardproces wordt dan vaak tenietgedaan door discussie over aanpassing en interpretatie. Terwijl we juist op zoek zijn naar laagdrempelige, flexibele en snel inzetbare architectuurproducten.
Architectuurproducten
Nu zeggen de meeste methoden meer over het architectuurproces dan over de architectuurproducten zelf. Een uitzondering is de Project Start Architectuur (PSA). Een PSA heeft een herkenbare standaard opbouw en is relatief snel op te leveren. Dat laatste echter alleen als er up-to-date referentie-architecturen beschikbaar zijn en een heldere projectscope. Helaas is dat zelden het geval. Aan de architect de uitdaging om dan alsnog stakeholders en kennisdragers uit te vragen en vooral snel een synthese samen te stellen. En dat liefst in een simpele vorm die weinig uitwerking vraagt, herkenbaar is zonder verdere uitleg, en geschikt is om indien nodig snel aangepast te worden op basis van voortschrijdend inzicht. Soms duurt het opstellen of aanpassen van een PSA te lang. Wat is een snel en voor iedereen werkbaar alternatief?
Business Model Canvas
Bij de oplossing van dit vraagstuk is binnen de NS geëxperimenteerd met de vorm van het Business Model Canvas (BMC). Daarbij zijn de negen bouwstenen van het BMC vertaald naar analogieën in het IT-domein. Wie het BMC kent (en anders is even Googlen de moeite waard), zal beamen dat het visueel erg herkenbaar is en inhoudelijk een overzichtelijke, aansprekende en samenhangende structuur biedt. Het BMC beschrijft in feite twee stappen in de waardeketen waar het gemodelleerde bedrijf deel van uitmaakt. ‘Hoe wordt welke meerwaarde aan welke klanten geleverd?’ en ‘Hoe komt die meerwaarde tot stand?’. Deze twee stappen worden door de bovenste zeven bouwstenen in het BMC beschreven; de waardestroom gaat daarbij van links naar rechts. De onderste twee bouwstenen beschrijven de gerelateerde geldstroom die van rechts naar links gaat: de inkomsten (van klant naar bedrijf) en de kosten (van bedrijf naar activiteiten, resources en partners). Het BMC kan gebruikt worden om een bestaand businessmodel te documenteren, maar ook om te brainstormen over ideeën voor een nieuwe business. In dat laatste geval wordt het template (de negen velden) groot aan de muur gehangen en zo kun je het gemakkelijk gebruiken om met geeltjes in een groep samen ideeën te bespreken, te analyseren en verder te ontwikkelen.
Information System Canvas
In analogie met het BMC beschrijft het Information System Canvas (ISC) een stuk van de informatie(waarde)keten waar een applicatie onderdeel van uitmaakt (figuur 1) . Ook het ISC beschrijft twee stappen in die keten: ‘Hoe wordt welke meerwaarde aan welke gebruikersgroepen geleverd?’ en ‘Welke informatie(functies) moet de betreffende applicatie daarvoor leveren?’ Ook hier gaat de ‘business value’ van links naar rechts. Alleen wordt in het ISC de retourstroom niet in een geldelijke waardering uitgedrukt – IT-kosten worden meestal niet per applicatie doorbelast – maar in contractuele waarderingen, middels KPI’s en andere contractvoorwaarden.
In tegenstelling tot het BMC staat een ISC in de regel niet op zichzelf. Voor álle applicaties in de te beschouwen informatieketen wordt een ISC opgesteld. Alle ISC’s samen vormen de applicatieen informatiearchitectuur van die keten, of – naar gelang de scope – van een heel domein of van de hele organisatie. Vergeleken met de gebruikelijke architectuuraspecten van de PSA – business, informatie(systemen), technische infrastructuur (en secundair: beheer en security) – gaat het ISC uit van een elders beschreven technische infrastructuur en security-architectuur.
OS, hosting en netwerk worden geacht gegeven te zijn. De afspraken daarover komen wel terug in de bouwsteen ‘underpinning contracts’ maar dat is dan ook alles.
Ook de business-architectuur is minder zwaar aangezet: het ISC beschrijft niet de bedrijfsprocessen (die gaan meestal over meerdere applicaties heen), maar de applicatiefuncties die in die processen gebruikt worden. Als er behoefte is aan een procesbeschrijving, zal die ergens anders gedocumenteerd moeten zijn of worden.
Drietrapsraket
Het werken met het ISC gaat in drie fasen. In fase één worden alle relevante huidige en te realiseren systemen (lees applicaties) in kaart gebracht met een ISC per systeem. Zaak is er op te letten dat van alle systemen dezelfde doeldatum beschreven wordt. Elk systeem zal namelijk zijn eigen releaseplanning kennen waardoor functionaliteit en dus het bijbehorende ICS in de tijd kan veranderen.
Fase twee is het toetsen van de volledigheid en consistentie van de keten. Wordt alle benodigde gebruikersfunctionaliteit voldoende afgedekt? Is er voor elke collaboration in de ene ISC ook een corresponderende interface in een andere ISC? Is er voor elke essentiële ‘satelliet-IT-component’ (denk aan spreadsheets en ESB-transformaties) een afzonderlijke ISC opgesteld? Wat is de authentieke bron van gegevens? Welk systeem bepaalt de timing van informatie-uitwisseling? Welke interactiepatronen worden gebruikt? Wat als een systeem in de keten (tijdelijk) niet beschikbaar is? Dit is de fase waar in potentie de grootste architectuurdiscussie plaatsvindt.
Als derde en laatste fase wordt getoetst of alle essentiële functionaliteit in de keten door adequate (toekomstige) SLA’s en underpinning contracts wordt geborgd. Met name bij de genoemde satelliet-IT kan dat wel eens een uitdaging zijn. De rol van de architect gaat normaliter tot het signaleren van gaten en/of inconsistenties. Aan de projectorganisatie of de product owner vervolgens de taak om het beheer dan alsnog afdoende in te regelen.
Herkenbaarheid
Door de focus op de applicatie(-meerwaarde), want daar gaat het voor iedereen om, is het ISC herkenbaar voor zowel gebruikersorganisatie als voor projectteam en beheer. Het kan door de architect bij alle doelgroepen gebruikt worden voor zowel het ophalen van het benodigde in- en overzicht, als voor het communiceren van inrichtingsbeslissingen.
Daarnaast betekent die focus een opdeling van de complexiteit van de keten in hanteerbare componenten, namelijk de applicaties. De samenhang van alle schakels in de keten wordt niet expliciet weergegeven, maar zit impliciet in de afhankelijkheid die elke schakel kent ten aanzien van zijn voorganger(s) (zie kader ‘Keten en services’). In het expliciet maken van die afhankelijkheden – de afstemming van wie doet wat met wiens hulp – lijkt het gebruik van ISC’s op dat van CRC-cards bij software-ontwerp. Daarbij wordt per ‘Class’ (applicatie) aangegeven welke ‘Responsibilities’ die class heeft (bouwsteen ‘Business Value’) en welke ‘Collaborators’ (bouwsteen ‘Collaborators’) daarbij nodig zijn. Een andere parallel in de software ontwikkelpraktijk – die de herkenbaarheid van het ISC ook weer ten goede komt – is het gebruik van user stories bij de requirements-analyse. Een user story is een korte samenvatting van een requirement in de vorm ‘ik als een rol/gebruiker (zie bouwsteen ‘Roles’ en bouwsteen ‘User Groups’) wil functie/ actie (zie bouwsteen ‘Functions’) met als voordeel doel/waarde (zie bouwsteen ‘Business Value’) voor rol/gebruiker’.
Rol architect
De architect kan het ISC als visualisatie van de architectuur op verschillende manieren inzetten, afhankelijk van de situatie en zijn eigen rol daarin.
In een greenfield voortraject of watervalsituatie worden ISC’s door de architect opgesteld, meestal mede op basis van een aantal referentie-architec-turen en/of projectspecifieke (proces-)analyses. Dergelijke ISC’s kun je dan zien als ‘first cut’ werk pakketten voor het nog op te starten realisatieproject.
In een situatie waar een uit te breiden omgeving nog in kaart gebracht moet worden, kan de architect het opstellen van ‘as-is’ ISC’s (fase 1) uitbesteden aan specialisten die de betreffende applicaties kennen. De analyse van fase 2 kan daarna door de architect zelf worden uitgevoerd, inclusief de daardoor benodigde aanpassingen in de eerder aangeleverde ISC’s die dan een ‘tobe’ versie krijgen (dus met een doeldatum in de toekomst).
Een ‘to-be’ ISC kan ook door een architect binnen een project of in een Scrum-team opgesteld worden. De fase 2 analyse wordt dan gedaan hetzij solo door de project- of programma-architect, hetzij in een gezamenlijke analyse met alle projectarchitecten respectievelijk alle teamafgevaardigden in een Scrum of Scrums (in dat geval bij voorkeur gefaciliteerd door één architect).
Praktijk
Bij de NS is het ISC ingezet binnen het programma Besturing 3.0, een groot vervangingsprogramma voor het centrale legacy-systeem voor aanpassing van de dienstregeling bij afwijkingen van de planning. Onder dit programma werkt een aantal-Scrum teams aan nieuwe applicaties die samen de genoemde legacy zullen vervangen. Bij de start van het programma werden scope en context van elke applicatie vastgelegd in (waterval) PSA’s.
De uitwerking van programma-interne interfaces werd vervolgens geheel volgens de Scrum-aanpak bij de teams gelegd, maar door de autonomie van de teams en hun afzonderlijke, strak geplande releases kwam gezamenlijke afstemming van die interfaces in de verdrukking. Vanuit programmamanagement werd daarom een afzonderlijk architectuurtraject in het leven geroepen om de consistentie van de keteninteractie te borgen.
Binnen dit architectuurtraject hielp het ISC om snel overzicht te scheppen in functionaliteit, interfaces en knelpunten – zonder de teams daar
bij noemenswaardig te belasten – en om de discussie over oplossingsrichtingen in gang te zetten. De grootste kwaliteiten van het ISC bleken te zijn:
• Herkenbaarheid: Architecten, analisten, beheerders en andere specialisten konden zich de inhoud en opbouw van het ISC snel eigen maken; zowel de bedoeling van het template als de betekenis van een ingevuld ISC.
• Weinig werk: Door de herkenbaarheid van het template is geen verdere formattering of tekstuele uitleg nodig. Tekst kon vaak bulletsgewijs direct uit referentiedocumenten of mailwisseling worden gekopieerd of letterlijk worden genotuleerd bij mondelinge uitleg. Ook lezen en reviewen ging erg snel.
• Dwingt discipline af: Het verplicht vullen van de helder afgebakende bouwstenen dwingt een haalbare volledigheid af waardoor een aantal knelpunten breder aan het licht kwam.
Eén van de succesfactoren daarbij was toepassing van de ‘80 is prachtig’-regel. Ook al ben je niet helemaal zeker of het canvas al helemaal goed en volledig gevuld is: laat maar reviewen, start fase 2 alvast, eventuele onvolkomenheden zijn snel rechtgezet. Geen perfectie nastreven op het canvas, het is de daaropvolgende analyse en discussie die telt.
Specifieke omstandigheden waren soms aanlei ding voor vragen over de opzet van het ISC.
• We hebben een project dat een aantal gerelateerde kleinere applicaties realiseert. Kunnen we het hele project op één canvas zetten? Ja dat kan, mits ook al die applicaties dezelfde beheervoorwaarden kennen. Zie ook kader ‘Beheercontracten’.
• We hebben hier gebruikersgroepen met allemaal hun eigen rol; kunnen we de twee bouwstenen niet samenvoegen? Nee, gewoon expliciet maken en twee keer opschrijven, niet elke applicatie kent zo’n een-op-een-relatie.
• Dit staat allemaal al in de project repository (i.c. Enterprise Architect). Moeten we het dan nog in een canvas zetten? Ja. Een repository is niet altijd toegankelijk voor iedereen. Bovendien schept het canvas visueel overzicht dat een repository niet levert.
• Kunnen we geen Nederlandse termen gebruiken? Ja dat kan. We hebben intussen dan ook een ‘applicatiecanvas’ (bekt ook lekkerder) met Nederlandse titels voor de bouwstenen.
• Is het niet vreemd om user-interfaces en systeeminterfaces bij elkaar te zetten? Ja, dat is even wennen maar past wel in de waardestroom filosofie: beide zijn intermedium voor levering van de betreffende applicatiemeerwaarde richting de gebruiker.
• Kunnen we niet zowel inkomende als uitgaande systeeminterfaces bij elkaar zetten? Nee, dat zou de intuïtieve interpretatie niet ten goede komen. ‘In’ en ‘uit’ zitten op een andere plek in de waardestroom. Zie ook kader ‘Keten en services’.
• Kunnen we de bouwstenen ‘SLA’ en ‘Underpinning Contracts’ niet leeg laten? Ja, als dat op dit moment te veel uitzoekwerk kost. Dat zijn overigens wel de enige twee bouwstenen die in fase 1 en 2 leeg gelaten kunnen worden.
• Moet de contactpersoon niet de domeinarchitect zijn? Ja dat kan, maar is niet noodzakelijk. Contactpersoon is iemand die betrokken is geweest bij het opstellen van het canvas en die vragen erover kan beantwoorden of doorverwijzen.
Conclusie
Het ISC is een nuttig hulpmiddel gebleken om snel overzicht te scheppen in een complex applicatielandschap en dat op een laagdrempelige manier te delen. Vanuit dit gedeelde overzicht kunnen inrichtingsbeslissingen genomen worden waarvan de impact op hoofdlijnen weer middels ISC’s duidelijk gemaakt kan worden. De mogelijkheid om het invullen van het canvas te delegeren en om analyses uit te voeren in een gezamenlijke sessie maakt het een geschikt hulpmiddel in een veelheid van situaties. Ten behoeve van architectuur vóóraf, áchteraf of halverwege. Hoe agile wil je het hebben.
 
 
KADER: Satelliet-IT
In een informatieketen spelen naast duidelijk herkenbare applicaties vaak ook minder herkenbare componenten een rol. Drie veel voorkomende soorten zijn: persoonlijk contact (telefoon, mail,…), spreadsheets en ESB-mediations. Het is doorgaans nuttig om deze componenten expliciet te maken. 
Zo werd in het genoemde vervangingsprogramma een ESB-mediation tussen applicatie A en applicatie B gerealiseerd door het project van A. De beheergroep van B ging er daarom van uit dat het onderhoud van die mediation bij de beheergroep van A zou horen. Maar in de SLA van A voor de levering van informatie aan B werd de service beschreven die A aan de ESB leverde (en niet die van de ESB aan B)! 
Er is een aantal manieren om in een ISC om te gaan met dit soort satelliet-IT. De meest eenvoudige en vaak meest doeltreffende manier is om een aparte ISC op te stellen voor die satelliet-component. Alleen als dat duidelijk overkill is (als beheer, ondersteuning en gebruik triviaal zijn) is het soms praktischer om de satelliet op te nemen in de ISC van een andere applicatie, door bijvoorbeeld een spreadsheet te benoemen in de databouwsteen, uitgaand mailverkeer als een interface, of inkomend telefoonverkeer te koppelen aan de betreffende collaborator met de tekst ‘via mobieltje’.
 
KADER: Keten en services
Informatieketens worden door het ISC opgeknipt in afnemer-leverancier-relaties. Een applicatie levert meerwaarde voor gebruikers, hetzij direct – middels een user interface – hetzij indirect - middels een interface naar afnemende systemen die uiteindelijk dan weer gebruikers bedienen. Soms levert een applicatie die meerwaarde stand-alone, maar meestal zijn daar ook andere applicaties voor nodig. Die andere applicaties worden dan als collaborator opgetekend. Het zal duidelijk zijn dat alle collaborators die op de ISC van applicatie A worden genoemd, op hun eigen ISC één of meer interfaces moeten hebben die applicatie A dan bedienen. 
De structuur van het ISC dwingt af dat een applicatie wel zijn leveranciers (collaborators) moet kennen, maar niet noodzakelijkerwijs zijn afnemers (afnemende applicaties). Andersom wordt per applicatie wel verplicht vastgelegd via welke interfaces die afnemers bediend worden, maar niet via welke interfaces de applicatie zelf wordt bediend door zijn eigen leveranciers.
Dit past in de filosofie van service-oriëntatie. Een applicatie bepaalt zelf de services die geleverd worden, maar ‘weet’ in principe niet hoe die eventueel hergebruikt worden. En andersom: gebruikmaken van de services van een andere applicatie (collaborator) betekent aansluiten op diens interfaces. Overigens: ook al dwingt het ISC-template dat niet af, die laatste kun je er natuurlijk wel bij schrijven als je een leverancier benoemt in de bouwsteen Collaborators: "<leverancier> via <diens interface>”.
 
KADER: Beheercontracten
Een ISC beschrijft applicatiefunctionaliteit die qua levenscyclus als eenheid gemanaged wordt onder één en hetzelfde beheer. Dat maakt het zinvol én hanteerbaar om SLA’s en underpinning contracts in het ISC op te nemen. De meerwaarde van deze twee bouwstenen ligt in de toets op consistentie en volledigheid van de (in te regelen) beheercontracten in fase 3. 
Daarnaast is de aanwezigheid van deze beheerbouwstenen (of ze nu ingevuld of nog leeg zijn) een constante reminder voor fase 2 dat de architectuurbeslissingen die daar worden genomen niet alleen impact hebben op de applicatie als projectdeliverable, maar op de hele levenscyclus. En dat die beslissingen liefst dus ook rekening moeten houden met de TCO en TTM in de beheerfase. 
Zo spelen deze bouwstenen het architectuurgeweten van het ISC.
 
Joep Creusen (joep.creusen@planet.nl) is informatiearchitect bij de Nederlandse Spoorwegen.

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag