Agile architectuur met het Information System Canvas

Vorige week verschenen in maandblad ‘Informatie’, nu te downloaden op de Open Data Architectuur site: het ISC. ‘Agile’ als thema is hier enigszins off-topic, maar de link zit ‘m natuurlijk in de focus op applicatie-meerwaarde en afnemer-leverancier-relaties als basis voor het inrichten van informatieketens als logistieke ketens.

Applicatie-architectuur op één A4

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 de omgeving. Die interne structuur bevordert de efficiëntie van project en daarop volgend beheer. Denk daarbij aan hergebruik, testbaarheid en onderhoudbaarheid. Externe aansluiting – op bestaande hardware en software, maar ook op regelgeving, beleid en lange termijn plannen – draagt bij aan beheersing van risico, 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.

Dat klinkt meer als ‘waterval’ dan als ‘agile’. Terwijl we met agile ontwikkelmethoden als Scrum 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 (daarmee) je efficiëntie verbeteren.

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 risico- en 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 kleinere 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’, d.w.z. 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, mede 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.

Standaard methoden beschrijven meestal een ideale 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 grotendeels 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 en minder 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 project scope. 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 zonodig snel aangepast te worden n.a.v. 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 9 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 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 business model 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 (zie figuur). Ook het ISC beschrijft twee stappen in die keten: “Hoe wordt welke meerwaarde aan welke gebruikersgroepen geleverd?” en “Welke informatie(functies) zijn daarvoor nodig?”. 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.

 

ISC bschr

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 applicatie- en 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 bestaande 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) onbeschikbaar is? Dit is de fase waar in potentie de grootste architectuurdiscussie plaatsvindt.

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’.

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 waar het voor iedereen bij IT om gaat, namelijk de applicatie(meerwaarde), 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 t.a.v. 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.

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”.

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 van de architect

De architect kan het ISC als architectuurvisualisatie op verschillende manieren inzetten, afhankelijk van de situatie en zijn/haar eigen rol daarin. In een greenfield voortraject of watervalsituatie worden ISC’s door de architect opgesteld, meestal mede op basis van een aantal referentie architecturen en/of projectspecifieke (proces-)analyses. Dergelijke ISC’s kun je dan zien als first-cut werkpakketten 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 beheerders of andere specialisten die de betreffende applicaties kennen. De analyse van fase 2 kan daarna door de architect zelf worden uitgevoerd, inclusief de daardoor eventueel benodigde aanpassingen in de eerder aangeleverde ISC’s die dan een ‘to-be’ 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 conform 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 daarbij 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 kwamen.

Eén van de succesfactoren daarbij was 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 maar 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 aanleiding 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 die twee bouwstenen niet samenvoegen? Nee, gewoon expliciet maken en twee keer opschrijven, niet elke applicatie kent zo’n één-op-één 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 “applicatie canvas” (bekt ook lekkerder) met Nederlandse titels voor de bouwstenen.
  • Is het niet vreemd om user interfaces en systeem interfaces 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 systeem interfaces 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 teveel 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.

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.

 

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.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *