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
informatiea rchitectuur. 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 9de in een reeks bespiegelingen. Het is eerder op min weblog ArchITectuurBedrijven gepubliceerd.
[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/.
Only registered users can write comments.
Please login or register. |
