Ecoology

Inleiding

Een veelgehoord misverstand over OO is dat het een methode voor systeemontwikkeling van computersystemen is. Eén van mijn belangrijkste inspanningen in mijn werk is steeds dat idee omver te halen.

OO is niet een methode voor systeemontwikkeling. Het is een taal om complexiteit hanteerbaar te maken. In essentie zou ik willen zeggen: het is een taal die gemaakt is voor complexiteit.

Complexiteit is een begrip dat betekenis heeft gekregen door twee ontwikkelingen in de wetenschap:

  1. Chaos theorie
  2. Complexiteitstheorie

De chaos theorie is verantwoordelijk voor de ontdekking dat werkelijke chaos in natuurlijke systemen niet bestaat, maar dat interne cohesie verantwoordelijk is voor orde op een hoger niveau. Eén van de verhalen uit de chaos theorie is dat het slaan van de vleugels van een vlinder in China de oorzaak is van een orkaan in Florida.

De complexiteitstheorie, ontstaan met name vanuit het Santa Fé instituut[1], maar waarvan de wortels teruggaan tot Gregory Bateson en de cybernetica[2] (de oorsprong van de computer ligt in de cybernetica, de wetenschap van terugkoppeling en sturing), is verantwoordelijk voor een theoretische onderbouwing van systemen die analytisch niet meer te beschrijven zijn. Deze systemen hebben behoefte aan andere metaforen dan de wiskundige, en zeker andere dan de werktuigbouwkundige. We hebben het over de invloed van metaforen op het denken van de mensen die met deze zaken willen werken. Die invloed is aanzienlijk. Verouderde metaforen bepalen nog teveel de manier waarop we tegen de wereld aankijken. Wat studenten leren op de universiteit is afkomstig van een wereldbeeld uit de tijd van de stoommachine. De bekende Von Neumann[3] architectuur is gebaseerd op deze visie op de computer als een soort stoommachine. We zien computers als stoommachines! Alleen al de term automatisering maakt het moeilijk de verregaande effecten te kunnen realiseren die de computer mogelijk maakt. Het zijn de bekende handelingen die we al jaren en soms zelfs eeuwen doen die we gaan uitbesteden aan machines: we automatiseren datgene wat we al deden. Het is dan heel moeilijk om te zien wat er voor dingen mogelijk zijn die we nog niet deden. De meest ingrijpende veranderingen die de ontwikkelingen in de IT zullen bewerkstelligen in de moderne maatschappij, en de wijze waarop organisaties en markten functioneren, beginnen zich nu af te tekenen. De oude specialisaties van customer intimacy, time-to-market, cost-effectiveness beginnen in elkaar over te lopen in een nieuw begrip: the one-person market. De directe relatie die klanten nu kunnen hebben met leveranciers door het Web, zal alle gangbare relaties tussen bedrijven en hun markten omver gaan gooien.

Nieuwe metaforen zijn dus nodig om ons te helpen met deze nieuwe ontwikkelingen om te gaan. Ook zaken als de ethiek van vernieuwingen deze metaforen. Waar moeten deze metaforen vandaan komen? Wie leveren ons deze metaforen en hoe om te gaan met (onverwachte) zij-effecten zullen onderdeel uit moeten maken van? De metaforen voor het beschrijven van complexe systemen komen uit de biologie en de filosofie.

De biologische metafoor

Waarom de biologische metafoor?

Een waarneming die we kunnen doen is dat biologische systemen van een ontzagwekkende complexiteit kunnen zijn zonder dat iemand achter de helpdesk zit om problemen op te lossen.

In 1964 is een boek verschenen van James Watson, de co-ontdekker (samen met James Crick) van het DNA. Dit boek was een monografie over een cel, een coli bacterie van een soort waarvan er miljoenen in onze darmen voorkomen. Als we deze cel bekijken in termen van complexiteit, dan kunnen we een aantal waarnemingen doen.

Ten eerste bestaat de cel voor het grootste gedeelte uit water –informatietechnisch weinig interessant. De interessante aspecten bevinden zich met name in de eiwitmoleculen in de cel. Als we deze zouden uitdrukken in termen van computers kunnen we de informatie in deze ene cel uitschrijven in 10 zware werkstations (2014). De snelheid echter waarmee deze informatiehoeveelheid wordt gemanipuleerd binnen een cel is ontzagwekkend. Ter vergelijking: wanneer we de eiwitmoleculen opschalen tot de grootte van een Volkswagen, verplaatsen ze zich voortdurend met een snelheid van 4 maal die van het licht. De chemische interacties vinden plaats met een heftigheid die we ons niet kunnen voorstellen. De complexiteit is ook nauwelijks te meten – de enige manier waarop we de cel kunnen onderzoeken is door het dood te maken. Waarmee veel chemische activiteit stopt …

Biologische systemen in het klein (zoals cellen) en in het groot (zoals ecologische systemen) hebben een groot aantal eigenschappen die beschreven zijn en waar we binnen de IT ons voordeel mee kunnen doen. Een belangrijk vakgebied binnen de IT doet onderzoek naar complexe adaptieve systemen, dat zijn systemen die zijn ontworpen aan de hand van deze metaforen. Veel van deze systemen zijn niet OO. Het is mijn overtuiging dat het huwelijk van OO met complexe adaptieve systemen en kunstmatige intelligentie (intelligent agents bijvoorbeeld) kan leiden tot een nieuwe golf van veranderingen in de IT.

De computer revolutie

Een tweede overweging die ik graag mee wil geven is het feit dat de computerrevolutie nog niet heeft plaatsgevonden, zoals Alan Kay, de uitvinder van OO, regelmatig verkondigd heeft.[4]

Wat dit inhoudt kunnen we bijna dagelijks ondervinden: veranderingen gaan zo snel dat we niet meer in staat zijn erin mee te gaan. Dat is een zeer begrijpelijke situatie. Geld en mankracht zijn niet voldoende om een vakgebied of een uitvinding tot wasdom te brengen. Daar is ook tijd voor nodig. Die tijd is nodig om heuristieken te ontwikkelen, om de consequenties (in positieve en negatieve zin – in maatschappelijke, psychologische, technische enz. zin evenzeer) te leren kennen. Dit is trouwens ook begrijpelijk vanuit de complexiteitstheorie zelf: nieuwe technologische ontwikkelingen veranderen de omgeving, die weer terugkoppelende effecten heeft op de technologische ontwikkelingen zélf.

De computerrevolutie heeft die tijd nog niet gehad. We zitten nu nog in een tijd waarin veranderingen zich zo snel voltrekken, dat het weinig zin heeft te investeren in technologische oplossingen op een wat langere termijn. Deze zullen immers binnen enkele jaren alweer verouderd zijn!

CBD en SOA

Momenteel is er veel belangstelling voor CBD (Component-Based-Development) en SOA (Service Oriented Architecture). Met name vanuit het management is het eenvoudig hiervoor de belangstelling te wekken, omdat het inspeelt op vraagstukken die al jaren spelen. Alweer heel wat jaren geleden verscheen Byte magazine[5] met een slogan op de omslag: “Why Object Orientation has failed”.

De teneur van het artikel was zeer begrijpelijk en kan mede verklaren waarom deze belangstelling zo groot is. Er werd gesteld dat OO al jaren beweert de techniek te zijn om herbruikbare componenten te ontwikkelen, maar dat een markt voor deze componenten maar niet van de grond komt. Dit in tegenstelling tot een grote en sterk groeiende markt van herbruikbare (en gebruikte!) componenten die niet volgens het gedachtegoed van OO zijn ontwikkeld, namelijk de Visual Basic componenten. Talloze kleine en middelgrote bedrijven floreerden in deze markt van VBX’en, OCX’en, ActiveX’en en later Java Applets. Deze componenten waren niet of nauwelijks OO ontwikkeld.

Het artikel verscheen op een opportuun moment, want de situatie was drastisch aan het veranderen. Een jaar later had het artikel niet meer geschreven kunnen worden, want een sterk groeiende markt van niet alleen kleine en middelgrote, maar nu ook grote en zeer grote bedrijven waren zich aan het positioneren op de markt als componentleveranciers van OO componenten.

Toch is de kritiek niet terzijde te vegen.

De volgende stap in Responsibility-Driven Design

Ik ben een cola blikje. Het doel in mijn leven is simpel: mezelf verkopen. Om dit voor elkaar te krijgen kijk ik om mij heen en ik zie een aantal elementen.

Ten eerste heb ik een gevoel van eigenwaarde. Dat wordt enigszins tegengewerkt door een element in mijn omgeving dat zijn eigen doelen heeft waar ik geen weet van heb, en dat mij af en toe onder druk zet om mijn waarde te verlagen. Ik heb geen idee waar die noodzaak vandaan komt, maar dat element (laten we het “marktaandeel” noemen) weet mij aardig onder druk te zetten!

Gelukkig heb ik heel wat wapens om in de strijd te werpen. Zo heb ik bijvoorbeeld een gezicht. Geen gezicht denk je misschien, een cola blikje met een gezicht, maar dat is heel nuttig, een gezicht. Een gezicht kun je vragen om er sexy uit te zien, en dat heeft weer positieve invloed op de verkoop.

Om mijn doel in mijn leven te bereiken maak ik gebruik van welk element in mijn omgeving dan ook om het voor elkaar te krijgen. Zo gaat er wel eens iets fout: een element waarvan ik dacht dat het zonder haperen functioneerde blijkt plotseling niet beschikbaar te zijn. Laatst nog, een klant wilde betalen met een chipcard. Blijkt dat de kaartlezer kapot was.

Vervelend natuurlijk. Ik stelde nog voor om cash te betalen maar dat wilde de klant niet. Een klant stel je niet teleur. Het was ook nog een warme dag, en bovendien (dat kon ik op de chipcard zien) was de klant een lid van mijn primaire doelgroep, een jongeman van 18 jaar. Ik besloot dus om mijzelf gratis weg te geven. Goede reclame. De investering werd ook door “marktaandeel” goedgekeurd dus ik had ook nog enige back-up. Daarna werden nieuwe klanten natuurlijk gewaarschuwd voor de kapotte chipkaartlezer (door de chipkaartlezer zelf, die ook via Internet het onderhoudsteam had gewaarschuwd, maar dat zijn zaken die buiten mijn scope vallen natuurlijk).

In bovenstaand sprookje probeer ik aan te geven op welke wijze een model dat gemodelleerd is rond verantwoordelijkheden in staat is te reageren op zijn omgeving. Dergelijke modellen zijn een stuk simpeler in onderhoud, en eigenlijk is een verder doortrekken van dit model een model dat “zichzelf onderhoudt”. Maar dat is een onderwerp voor een later hoofdstuk.

Een dergelijk model is ten eerste niet use-case driven ontstaan. De structuur is een resultaat van responsibility-driven-design.

Handvaten

Om het voor elkaar te krijgen in deze veranderende wereld overeind te blijven, zijn er enkele handvaten waarvan we gebruik kunnen maken.

Gebruik OO als een taal. Gelukkig is deze aan het standaardiseren: UML bevat voldoende syntax en semantiek om als expressiemedium te dienen voor OO. Extensies voor de taal komen voort uit de frameworks, de daarin gebruikte patterns etc. Het is deze taal die als communicatiemedium dient, niet de code of de executable!

Gebruik OO niet als een taal. Een veel voorkomend probleem ontstaat wanneer ontwikkelaars met gebruikers, opdrachtgevers of klanten denken in OO taal te kunnen praten. Dit werkt niet. Class diagrammen, sequence diagrammen en dergelijke zijn niet begrijpelijk voor niet geschoolde mensen. De truc is veeleer dat de ontwikkelaar deze diagrammen gebruikt terwijl hij/zij met de klant praat. Voor een domein deskundige is dan de illusie compleet dat hij op een inhoudelijk niveau een gesprek heeft. De ontwikkelaar heeft het OO model als een referentiemodel dat hem daartoe in staat stelt. Wij gebruiken een zeer effectieve techniek die helpt om business mensen aan te laten haken, genaamd eXploratory Modelling.

Leg de nadruk op domein modellen. Als we zien waar veranderingen zich het meest voltrekken, is dat in zaken als persistentie, communicatiemedium, GUI. Het domein model blijft relatief het meest stabiel. Investeringen hierin kunnen gezien worden als van strategische betekenis voor het bedrijf. Tools die het clean-room ontwikkelen van domain modellen bemoeilijken of teveel beïnvloeden moeten dan ook niet gebruikt worden.

Goede modellen zijn niet use-case driven.[6] Een domein model is een model dat dient als onderliggend stratum voor een verscheidenheid aan toepassingen:

  1. Business modeling en (re-) engineering
  2. Systeemontwikkeling
  3. Strategische scenario sessies
  4. Business simulaties

Om deze modellen herbruikbaar te maken in deze verscheidenheid aan contexten is er geen enkele motivatie om use cases te gebruiken. Deze zijn teveel toegespitst op systeemontwikkeling, en de vraag van gebruikers en klanten in een tijdelijke context. De onderliggende modellen moeten aan veel zwaardere eisen voldoen wat betreft scope.

Goede modellen zijn use-case resistant. Een model dat overeind blijft onder de “aanvallen” van use-cases, bijvoorbeeld use-cases die zijn opgesteld in het kader van een requirements analyse, is een volwassen model.

Bronvermeldingen

BATES1 Bateson, Gregory [1] Steps to an Ecology of Mind
BATES2 Bateson, Gregory [2] Mind and Nature. An essential unity
BATES3 Bateson, Gregory [3] Where Angels fear to thread
BYTE1 Byte Magazine Why object-orientation has failed
KAY1 Kay, Alan The computer revolution has not happened yet.Keynote speech, OOPSLA 1997
KORSO Korson, Timothy D. Constructing useful use-casesComponent Strategies. March 1999
KORZY Korzybski, Alfred Science and Sanity 1924
MITCH Mitchell Waldrop, M. Complexity. The emerging science at the edge of order and chaos.Simon & Schuster 1992
NEUM Neuman, John von, Arthur Burks, Hermann Goldstine Preliminary Discussion of the Logical Design of an Electronic Computing Instrument 1946

Voetnoten

[1] Zie MITCH. Dit boek is een uitstekende inleiding in de complexiteitstheorie.

[2] Zie BATES1. Hij is de uitvinder van de cybernetica. Bateson’s betekenis voor de moderne IT wordt ernstig onderschat. Hij heeft in zijn artikelen handvaten gegeven om het aloude probleem van de dichotomie tussen vorm en proces op te lossen (nl. synthese op een hoger abstractieniveau). Dit probleem speelt in de IT voortdurend, bijvoorbeeld in de discussie over use-case driven vs. responsibility-driven design.

[3] Zie NEUM. Geeft een goed inzicht in de overwegingen die hebben geleidt tot deze computerstructuur.

[4] Zie KAY1. Deze speech fungeerde tevens als podium voor de presentatie van Squeak, het nieuwe project van Alan Kay en consorten waarin een nieuwe vernieuwingsgolf in de IT wordt vormgegeven.

[5] Zie BYTE1

[6] Zie KORSO.

Abonneer op de nieuwsbrief

DM-screen

The need for clarity

In the Netherlands we have this saying when we want to describe how we “translate” complex documents in esoteric language for a larger audience: “Jip en Janneke taal” (the language of Jip and Janneke). Jip and Janneke are the names of the two main protagonists in a series of  children’s novels by a great Dutch writer, Annie M.G. Schmidt. The series was written in the period between 1952 and 1957 and is still required reading for kids all over the world, since the series has been translated in a number of languages, including Chinese.

Anyway, Jip and Janneke language is the layman’s language or Plain English version. We as architects produce a lot of documents. Let a project manager, or any other role in the enterprise read those documents and they may exhibit a number of symptoms, most notably a irrepressible urge to fall asleep, or as a board member of an organisation I am involved in most eloquently cried out: “Disgusting! Really disgusting!”

The question is: do we, as architects, fall short in communication skills because of the esoteric nature of our documents?

I don’t think so. It is in the nature of our work that the models we use to get to grips with the complexity of our world are complex as well. We use special languages for them, and I for one am convinced there is no problem there, on the contrary.

I always illustrate my view of those complex models and the role they play in communication with another role I played in my youth, sometimes for days (and nights …) at an end: that of a Dungeon Master.

A Dungeon Master or DM is the game leader of a game called Dungeons and Dragons, in which characters play the roles of elves, gnomes or wizards in a mythical world. This world usually is created by the DM: he has a number of maps and a variety of tooling to create a tantalising and entertaining story. He has for example a number of dices with which stochasticity is introduced: does this monster appear now? does the wizard’s spell work? does the fighter win a fight?

The DM sits behind a screen that hides these apparels from the view of the players. He uses the representations of the complex world of the game to steer the game but the players are unaware of that. As they should be. They only know what the DM tells them their senses experience. In effect the DM constantly creates viewpoints that each character can use to visualise his or her place in the world at the particular point in time that the game is on.

This is exactly how I use my tools and models. They are never meant to communicate directly with the people I talk with (except when they are architects as well), but they help me to create the illusion to those people that I understand what they talk about, that I understand their world, their perspective, their concerns. And of course if there is a problem there, the problem lies with me, with my models with which I attempt to capture their world. Those are the viewpoints of course, and often these end up as documents or models as well. But they are not the architecture, and they should always have a prominent disclaimer that, no, this is not the architecture, this is the viewpoint for this particular stakeholder at this particular point in time. Because, yes, the architecture is much much more complex.

 

Abonneer op de nieuwsbrief

n-WORK-large570

Wat dóet een architect eigenlijk?

Ik kreeg de vraag gisteren tijdens een gesprek: wat heb je nu eigenlijk gedaan als enterprise architect bij die organisatie?

De vraag werd gesteld door een manager van een stafafdeling die verantwoordelijk was voor architectuur, en enterprise architectuur in het bijzonder.

Ik deed mijn best uit te leggen hoe ik architectuur aanpak bij organisaties: welke mensen betrek ik er bij, hoe zorg ik ervoor dat het aansluit bij de werkvloer, bottom-up en top-down bewegingen synchroon inrichten, architectuurbewustzijn kweken op alle lagen van de organisatie en het architectuurproces inrichten.

Wellicht was dat verhaal op zich niet oninteressant maar er ontstond een groeiend onbehagen bij de andere partij. “Maar wat doe je nu concreet?”

Pas na het gesprek realiseerde ik mij waar mijn gesprekspartner behoefte aan had. Wat hij wilde horen was: ik heb die en die architectuurmodellen gemaakt, die en die workshops gehouden waar die en die documenten uit voortkwamen. Ik heb een baseline architectuur opgesteld samen met die en die stakeholders, en op basis van de strategische doelstellingen in gezamenlijkheid die en die doelarchitecturen opgesteld. Kortom: mijn gesprekspartner was wellicht wel geïnteresseerd in mijn “hoe” verhaal, maar kon het niet verankeren zonder het “wat” verhaal.

Die fout heb ik eerder gemaakt. Voor mij is immers het “hoe” zóveel belangrijker dan het “wat” dat ik soms vergeet dat voor veel mensen dat zo ongeveer is wat een architect doet: architecturen maken. Daarnaast zijn die aspecten voor mij misschien (naast dat ze secundair zijn en in mijn optiek ook zouden moeten zijn) zó vanzelfsprekend dat ik geneigd ben ze niet naar voren te brengen.

Ik wil zeker niet beweren dat ik het “wat” niet belangrijk vind, en voor mij was het wel degelijk een les dat aspect niet te onderbelichten wanneer ik de vraag een volgende keer krijg. Wat doet een architect? Hij legt de focus op het “hoe”, en gebruikt een reeks van tools voor het “wat”.

Wat denken jullie: wat doet een architect eigenlijk?

Abonneer op de nieuwsbrief

%d bloggers like this: