Territoriumdrift

Good Fences Make Good Neighbors – althans volgens de oude volkswijsheid. De gedachte is even simpel als diepzinnig: om goed samen te kunnen leven is (tenminste een gevoel van) privacy belangrijk. Het is niet zelden de eerste investering die de trotse eigenaren van een nieuwbouw­woning in hun tuin doen. Eerst het territorium afbakenen, hek er omheen, en daarna zien we wel verder. Het lijkt wel een universele behoefte die teruggaat tot de vroege mensheid. Het vee moet binnenblijven maar roofdieren en vreemdelingen vooral buiten. Honden doen een plas, mensen zetten een hek. Biologen noemen dat territoriumdrift.

Hekken in de informatieruimte

Ook in de informatieruimte komen we zulke hekken tegen. Hekken tussen de verschillende informatiedomeinen – zonder de juiste «credentials» krijg je vanuit de ene ruimte echt geen toegang tot de andere ruimte – en een hoge muur tussen de ontwikkelomgevingen en de productieomgeving.

Tot zover wat mij betreft niets dan lof en begrip. En dan volgt er meestal een maar. Zo ook nu. Want deze hekken zijn bij veel bedrijven doorgevoerd in de architectuur van de systemen. Beter gezegd, ze hebben de hekken vervangen door diepe slotgrachten en hun systemen op eilanden gebouwd. Ze hebben al het mogelijke gedaan om de systemen onderling maximaal los te koppelen, maar ze zijn vergeten dat er volgens de beste software engineering principes ook een maximale cohesie tussen de samenstellende delen moet zijn [1]. Het is namelijk best lastig als je bij de buurman een pondje suiker wilt lenen en dan eerst de boot in moet en vervolgens geduldig moet wachten voor alle ophaalbruggen die je onderweg tegenkomt en overigens maar moet afwachten of de buurman zin heeft om de poort open te doen. Roger Sessions heeft in zijn boek “Software Fortresses – Modeling Enterprise Architectures” ooit nog eens een lans gebroken voor dit model [2]. Hij heeft zelfs een modelleertaal ontwikkeld compleet met slotmuren, wachters, ophaalbruggen, boodschappers en onderhandelaars – heel artistiek vormgegeven met figuurtjes die zo van Astrix en Obelix zouden kunnen afstammen. Je moet er toch niet serieus aan denken dat je een enterprise architectuur zou moeten modelleren met louter van die melige stripfiguurtjes? Alleen daarom al is het gelukkig dat dit nooit echt is aangeslagen...

Zo'n extra beveiligd systemenlandschap wordt al helemaal lastig als je ooit wilt gaan ruilverkavelen. Als de informatieruimte, om welke reden dan ook, op de schop moet. Dan kun je ineens enorm last hebben van al die kunstmatig opgeworpen barrières die eerst de buurman buiten de deur moesten houden maar nu ineens een coherent domein dwars doorkruisen. Je wilt toch niet echt dat de normale bedrijfsvoering serieus wordt gehinderd door zelfgecreëerde, schier onneembare barrières in de architectuur?

Trouwens, het is in de huidige constellatie al lang niet meer zo makkelijk om alleen maar te denken in binnen- en buitenwereld. Die grenzen zijn in snel tempo aan het vervagen. Ironisch genoeg vragen juist de innovatieve business concepten met zelfbedieningsklanten, vertrouwde derden, complementoren en affiliates om een steeds genuanceerdere beveiliging.

Grensverleggend denken

Zou het ook anders kunnen? Zou je ook kunnen denken in complementaire deelsystemen die zich wel flexibel kunnen aanpassen aan wijzigende omstandigheden en toch steeds robuust, veilig en betrouwbaar zijn?

We zitten in ons denken al snel vast in de metaforen uit de fysieke wereld. Kijk maar naar de terminologie die we kiezen. “Ruimte”, “domein”, “omgeving”, “eiland”, “hek”. Maar wat dan als we een concept zouden bedenken om in de virtuele wereld te gebruiken waarvoor in de werkelijkheid geen equivalent bestaat? Zou het ontbreken van een passende metafoor ons niet bij voorbaat beperken in onze creativiteit? Of zou het juist een uitdaging moeten zijn om een patroon te bedenken dat echt past bij de unieke architectuurproblemen die we in de digitale wereld aantreffen?

In principe kunnen we in de virtuele wereld veel creatiever met het afbakenen van het territorium omgaan dan in de werkelijkheid ooit mogelijk zou zijn. Je zou het bijvoorbeeld op basis van executeerbare regels interactief kunnen maken. Of juist sterk contextafhankelijk – bij voorbeeld op basis van de reputatie die je als gebruiker in de loop van de tijd hebt verworven. Je kunt filosoferen over een “virtual private service catalogue” – naar analogie van de “virtual private database”. Een soort verplaatsbare schermen in de informatieruimte die gegeven een specifieke situatie precies de grenzen van het virtuele domein afbakenen. En die zich naadloos aanpassen als een veranderende situatie daartoe aanleiding geeft. Zou dat niet heel erg passend zijn?

Er is dus volop ruimte voor creatieve oplossingen, maar er is wel één belangrijke voorwaarde. De omgeving moet geënt zijn op een geïntegreerde informatie-infrastructuur waarop uniforme toegangscontroleregels kunnen worden afgedwongen. Dat kan met een gemeenschappelijke informatiearchitectuur. Maar dat blijkt keer op keer nog een hele uitdaging.

Doorgaans is een enterprise architectuur opgebouwd uit drie afzonderlijke ruimtes – de business ruimte, de informatie- en applicatieruimte en de technologieruimte (deze begrippen komen in allerlei verschillende referentiemodellen in verschillende bewoordingen voor, maar het basisidee is tamelijk consistent). De business ruimte wordt als vanzelfsprekend geordend volgens de concrete afdelingen, processen en producten die een enterprise kent. De indeling van de businessruimte verandert logischerwijze als de indeling van de business zelf wijzigt. De technologieruimte kent ook zijn logische demarcatielijnen, bijvoorbeeld per hardware platform, geografische plaats en provider. Ook hier volgen de wijzigingen in de modellen de werkelijkheid.

De verleiding is groot om voor de informatieruimte ofwel de indeling van de businessruimte ofwel de indeling van de technologieruimte te adopteren. Het voordeel daarvan zou in elk geval zijn dat de aansluiting op in elk geval één van de twee ruimtes naadloos is. Het nadeel is vanzelfsprekend dat de indeling aangepast moet worden als er in een andere ruimte een verandering optreedt.

Enterprise architecten die zich serieus verdiept hebben in de modelleertaal ArchiMate zien zich tegenwoordig gestimuleerd om op z'n minst de mogelijkheid te overwegen om de indelingen van de verschillende ruimtes radicaal te ontkoppelen. Immers, in het Archimate metamodel vormen de servicelaag tussen de business- en de informatieruimte en de servicelaag tussen de informatie- en de technologieruimte, maken het mogelijk om iedere ruimte in te delen langs de lijnen die voor die ruimte het meest logisch zijn [zie figuur] [3].

In een goede, stabiele informatiearchitectuur zijn de informatieservices afgebakend langs lijnen die in de informatieruimte logisch zijn – niet in de steeds veranderende werkelijkheid. Idealiter betekent een verandering in de businessruimte of de technologieruimte dan alleen een remapping van de vernieuwde ruimte op de bestaande informatiearchitectuur. Dat kan natuurlijk alleen als die ruimte zodanig is gekozen dat er geen impliciete beperkingen in zitten.

Een slimme zonering van de informatieruimte is in combinatie met een flexibele, contextgevoelige afscherming de basis voor een toekomstvaste architectuur. Daar waar succesvolle servicegeoriënteerde architecturen zijn gerealiseerd vind je ook voorbeelden van zulke slimme zoneringen. Denk aan een classificatie in termen van basisregistraties (niet alleen bij overheden, maar ook bij bedrijven in de vorm van een relatieregister, een productregister en een termenregister); kernsystemen (robuuste transactieverwerkers); beslissingsondersteunende componenten, hulpsystemen (bijvoorbeeld voor in/excasso; outputverwerking; email en content management); integratiecomponenten; besturingscomponenten en portalen.

ArchiMate laat zien dat je deze concepten via een servicelaag kunt koppelen aan de processen uit de businessruimte en aan de infrastucturele componenten uit de technologieruimte. Deze servicelagen zijn bij uitstek geschikt om een contextgevoelige toegangsbeveiliging te realiseren en vormen de facto de geïntegreerde informatie-infrastructuur. Geen hoge hekken met prikkeldraad, en al helemaal geen diepe slotgrachten, maar flexibele schermen die makkelijk te verplaatsen zijn als een veranderende situatie daarom vraagt.

Deze overpeinzing is bedoeld om tot nadenken te stemmen. Het is de 9^de in een reeks bespiegelingen die op dit weblog gepubliceerd zal worden.

[1] Noot: strikt gesproken geldt het cohesiebegrip voor de functies binnen een subsysteem. Echter, een verzameling subsystemen vormt doorgaans een subsysteem van een groter suprasysteem, zodat cohesie ook hier zijn nut kan bewijzen. In service-georiënteerde architecturen geldt dit vanwege de radicale scheiding van concerns in het algemeen sterker dan in silo-georiënteerde architecturen, waarin van nature veel meer redundantie voorkomt.
[2] Roger Sessions: “Software Fortresses – Modeling Enterprise Architectures”; Addison-Wesley, 2003.
[3] ArchiMate kent ook een serviceconcept voor het ontkoppelen van de businessruimte van de buitenwereld. Voor meer informatie: http://www.archimate.org/.