Veranderen van bedrijven! Engineering of Emergentie?

Frank Schalkwijk, woensdag 05 mei 2010

Het realiseren van effectieve Enterprise Architecturen met Enterprise Engineering én Enterprise Emergentie

Enterprise architecturen worden niet alleen ontworpen, ze ontstaan ook vanzelf en worden ontdekt. Dit artikel plaatst enterprise engineering tegenover enterprise emergentie, waarbij enterprise engineering zich richt op het op het ontwerpen van architecturen voor enterprises, terwijl bij enterprise emergentie de architecturen van enterprises vanzelf ontstaan. Met het effectief aanwenden van mechanismen voor emergentie kan naast het gebruik van engineering, de behoefte van bestuurders worden ingevuld de ontwikkeling van een bedrijf beheersbaar te houden. Dit is van belang in tijden waarbij de dynamiek, de openheid en onvoorspelbaarheid van de omgeving waarbinnen een bedrijf moet opereren alleen maar toeneemt. Dit zijn omstandigheden waarbij niet alleen met het huidige verandervermogen van het bedrijf reguliere veranderinitiatieven worden uitgevoerd, maar ook initiatieven die leiden tot verbetering van het verandervermogen zelf.

Het ontwerpdilemma

Er ligt een dilemma op tafel. De directie heeft zich voor drie dagen teruggetrokken in een luxehotel achteraf. Zij doen dit jaarlijks om een aantal lange termijn zaken te bespreken met het voltallige hogere management. Maar nog niet eerder in het lange bestaan van het bedrijf stond er zoveel op het spel. Het bedrijf moet wezenlijk veranderen. De vraag is, op welke wijze? Één van de overgenomen bedrijven heeft bijzonder positieve ervaring met enterprise architectuur en nu bestaat het voorstel om deze architectuurwerkwijze door te voeren voor de hele onderneming. De werkwijze richt zich op het ontwikkelen van een 'groot ontwerp'. Een aantal knappe koppen stellen in nauw overleg met diverse vertegenwoordigers van interne en externe belanghebbenden een nieuwe architectuur op. Deze bestaat uit onderdelen als visie, missie, bedrijfsdoelstellingen, principes, modellen en standaarden. Ze behelst onderwerpen als producten, diensten, processen, informatie, applicaties en infrastructuur. Daarbij zal het team van knappe koppen het 'groot ontwerp' valideren en verifiëren bij de stuurgroep, expertisegroepen en divisiedirecteuren. Extern wordt ze getoetst bij representatieve klanten, leveranciers en industrie analisten. Vervolgens heeft het 'groot ontwerp' kracht van wet. Ze zal gedicteerd worden aan de organisatie. Via een mechanisme op basis van ‘comply or explain’ zal naleving worden verzekerd. Wil het bedrijf dit wel? Wil zij zich verbinden aan een ‘groot ontwerp’ dat wordt opgelegd?

Het dilemma ligt bij de beheersbaarheid van het verandertraject. Het verandertraject omvat samenvoeging van bedrijven, splitsing van onderdelen en kantelingen van productgericht naar klantgericht werken. Oude systemen moeten worden opgeruimd, en meer. De omvang, de reikwijdte en de duur van de verandering is zo groot dat niemand het overzicht en inzicht kan behouden. Door het grote aantal aspecten en belangen waarmee rekening gehouden moet worden, overstijgt de verandering het menselijke bevattingsvermogen. Dit stelt vraagtekens bij een centraal geleid ‘groot ontwerp’. Daarbij komt dat de onderneming tot stand is gekomen door snelle autonome groei aangevuld met fusies en overnames. De aandacht is altijd sterk naar buiten gericht. Kansen in de markt worden snel opgepakt en ingevuld. Dit heeft geleid tot een grote verscheidenheid aan systemen die onderling met allerhande koppelingen aan elkaar geknoopt zijn. Op dat vlak zal er iets moeten gebeuren. De kosten zijn hoog en de synergie is laag. Intern moeten zaken op orde worden gebracht. Maar moet dit met een ‘groot ontwerp’? Moet dit met zo een drastische omslag in cultuur? Het risico is, dat de organisatie voor een paar jaar alleen maar intern bezig is met de boel te verbouwen en de aandacht voor de markt verslapt. Voor het bedrijfsonderdeel dat deze werkwijze heeft voorgesteld heeft het blijkbaar gewerkt. Maar goed, dat bedrijfsonderdeel is veel en veel kleiner dan de totale onderneming. Is er geen andere mogelijkheid? Een mogelijkheid die een minder drastische verandering van cultuur vereist. Één die de onderneming minder afhankelijk maakt van een stel knappe koppen, een strak dictaat, architectuurpolitie, en een groots opgezet verandertraject?

Hoe enterprise architectuur voor een onderneming wordt ingevuld, is voor iedere onderneming anders. Naast dat ze afhankelijk is van de sector waarin de onderneming werkzaam is, is ze ook afhankelijk van zaken als historie, verandercultuur, en bedrijfsdoelstellingen voor de toekomst. Binnen enterprise architectuur zijn wel twee diametraal verschillende stijlen te herkennen. Dit artikel positioneert deze twee stijlen ten opzichte van elkaar. Deze stijlen zijn enterprise engineering en enterprise emergentie. Het doel van dit artikel is de tegengesteldheid èn de complementariteit van beide stijlen aan te geven. Bedrijven verkrijgen hiermee het perspectief dat veranderingen op verschillende wijzen doorgevoerd kunnen worden door elementen van deze twee stijlen te combineren. Het relativeren en loslaten van bestaande en soms verstarde werkwijzen wordt hiermee ondersteund. Het resultaat is dat bedrijven beter in staat zijn een architectuurstijl op te stellen die afgestemd is op de eigen bedrijfshistorie, verandercultuur en beoogde toekomst.

Enterprise Engineering

Met het begrip ‘enterprise’ binnen ‘enterprise engineering’ worden ondernemingen, bedrijven, instituten en overheidsinstanties aangeduid. Dit zijn allemaal organisaties van grote omvang, complex, centraal geleid en maatschappelijk verweven met vele andere organisaties. Enterprises behoren tot de meest omvangrijke organisatievormen waarbinnen mensen samenwerken. Andere omvangrijke organisatievormen zijn staatsvormen, markten, industrieën en sectoren. Het verschil tussen enterprises en deze andere organisatievormen is dat bij enterprises, vanwege de centrale leiding, nog het gevoel bestaat dat deze ontwerpbaar zijn.

Het paradigma voor engineering is ontwerpen. Engineering omvat het creatief toepassen van wetenschappelijke principes, empirische ervaringen en vernuftige inzichten voor het ontwerpen en ontwikkelen van structuren, machines, voorwerpen, werkprocessen en andere artefacten. Centraal daarbij staat het opstellen van het ontwerp van het artefact. Engineering is gericht op: het volledig specificeren van wensen en eisen waar het artefact aan moet voldoen, het voorzien en compleet vaststellen van de operationele omstandigheden waarbinnen het artefact moet opereren en het tot stand brengen van volledige bekendheid hiervan bij belanghebbenden en betrokkenen. Engineering is gericht op het verkrijgen en integreren van zekerheden binnen één ontwerp.

Bij enterprise engineering is het artefact dat ontworpen wordt een enterprise. Dit kan een nieuw onderdeel zijn, of een bestaand onderdeel dat het bedrijf wil veranderen. Bij het opstellen van een ontwerp voor een enterprise, is de gangbare werkwijze: het opsplitsen van het ontwerp in haar onderdelen, deze onderdelen toewijzen aan verschillende ontwerpers, om vervolgens deze weer te integreren in het overkoepelend. Wanneer onderdelen op zichzelf nog steeds te omvangrijk zijn, dan wordt dit proces van decompositie herhaald. Daarnaast stellen ontwerpers voor elk onderdeel een specificatie op, brengen in kaart onder welke toekomstige omstandigheden het onderdeel moet functioneren en zorgen voor betrokkenheid bij en bekendheid met het onderdeel bij belanghebbenden. Wanneer het ontwerp klaar is gaat ze een besluitvormingscircuit door waarbij ze wordt aangevuld met een investeringsbegroting, projectplan en risico inschatting. Bij groen licht wordt tot realisatie overgegaan.

Engineering heeft haar succes bewezen bij het maken van allerhande artefacten zoals bij machines, meubilair, schepen, auto’s en software applicaties. Hele industrieën zijn ontstaan door gebruik te maken van het geschetste ontwerpproces. Een lange historie van het opbouwen van kennis en ervaring rondom materialen, werkwijzen, en andere onderwerpen kenmerken deze industrieën. Wat al deze artefacten gemeenschappelijk hebben is dat ze ontwerpbaar zijn. Een ontwerper, of een collectief van ontwerpers, is in staat geweest deze artefacten te ontwerpen.

Ontwerpbaarheid is een vermogen van een industrie, dat groeit naarmate vanuit het verleden meer ervaringen zijn opgedaan en waaruit leringen zijn getrokken. Ontwerpbaarheid geeft een grens aan tussen wat nog ontwerpbaar is en wat niet. Deze grens is relatief gezien de tijd dat een industrie heeft gehad om ervaringen op te doen en daarbij dit vermogen uit te breiden. Deze grens geeft ook een onderscheidt aan tussen microniveau en macroniveau. Op microniveau zijn artefacten nog ontwerpbaar. Bij opschaling naar macroniveau ontstaan beperkingen in ontwerpbaarheid. Werkwijzen die op kleine schaal succesvol zijn, zijn niet zomaar succesvol op grote schaal. De onderstaande lijst geeft een overzicht van beperkingen die optreden wanneer de ontwerpschaal opgerekt wordt.

Beperkingen van het gangbare ontwerpproces wanneer deze naar macroniveau wordt opgerekt:

  • Op macroniveau ontstaat een combinatorische explosie aan mogelijkheden waarmee in een ontwerp rekening gehouden moet worden. Deze neemt onbeheersbare proporties aan. Het wordt onbeheersbaar om volledig rekening te houden met de diversiteit aan markten, landen, producten, technologieën, systemen, etc., en hun onderlinge combinaties.

  • Het samenwerken en afstemmen tussen het grote aantal betrokken partijen met verschillende belangen is complex.

  • Op macroniveau, bijvoorbeeld bij massaproductie, bestaat meer druk op details op microniveau omdat kleine ‘fouten’ grotere impact hebben. De flexibiliteit van medewerkers is ontoereikend deze tijdens de realisatie weg te werken.

  • Juist op macroniveau is het geheel meer dan de som der delen. Eigenschappen als synergie en kritische massa kunnen moeilijk worden voorzien op microniveau. Op microniveau is daarmee weinig expertise voorhanden om synergie op macroniveau te bewerkstelligen.

  • De scheiding tussen activiteiten in het ontwikkelproces – analyse, ontwerp, realisatie – maakt op macroniveau integratie en coördinatie over het ontwikkelproces moeilijker doordat er meer partijen bij betrokken zijn en over langere tijd.

  • Op macroniveau speelt de hele levenscyclus van een artefact. De focus bij ontwerpen op microniveau ligt op de creatie en niet zo zeer op het verval van een artefact.

  • Leereffecten en terugkoppelingseffecten treden op macroniveau meer op maar zijn moeilijker te coördineren.

  • Op macroniveau zijn de toekomstige operationele omstandigheden niet meer te voorzien en is minder mogelijk om omgevingsfactoren buiten te sluiten.

  • Het opstellen en bijhouden van de specificatie van een groot ontwerp vereist meer voorzieningen en het actueel houden hiervan is niet te doen.

In het bijzonder de beperking dat de hele levenscyclus van een artefact al bij ontwerp in overweging genomen moet worden speelt maatschappelijk een steeds grotere rol. Producten moeten afbreekbaar zijn in het milieu. Datacenters worden groen. Bedrijfsapplicaties moeten opgeruimd kunnen worden. Acquisities, fusies, overnames en afstotingen gaan sneller wanneer systeemlandschappen veranderbaar zijn. Hoeveel ontwerpprocessen zijn erop ingericht om bij creatie al te denken aan veranderbaarheid, aanpasbaarheid of verval?

Bovenstaande beperkingen brengen risico's met zich mee voor het ontwerpproces. En de risico’s vragen om maatregelen. Voorbeelden van maatregelen zijn: het terugbrengen van ambitie in reikwijdte, doorlooptijd en budget, het in programmaverband onderbrengen van meerdere kleinere projecten, het strakker sturen op consistentie, het reguleren van inspraak van belanghebbenden, het beter opleiden van ontwerpers, en het inzetten van methoden en technieken ondersteunt met gereedschappen. Ultimo, staat ook het maken van een omvangrijk ontwerp, het Groot Ontwerp, ter discussie. Waarom werken aan een Groot Ontwerp als deze lastig te engineeren is, verouderd is wanneer ze klaar is, medewerkers laat afhaken, et cetera.

Hoeveel tijd heeft een industrie nodig om voldoende ervaring op te bouwen voor de verbetering van de ontwerpbaarheid van haar artefacten? Hoeveel ervaring met enterprise engineering is nodig voor een degelijke ontwerpbaarheid voor enterprises? Laten de schaal van en de omstandigheden waarin enterprises zich bevinden het toe deze tijd te nemen? Laten directies van enterprises dit toe? Is het opschalen van engineering naar het niveau van enterprises op zichzelf wel haalbaar? Bestaat er een inherente beperking in ontwerpen waar niet aan te ontkomen valt? Staat engineering zelf niet ter discussie wanneer artefacten ontwikkeld moeten worden van de omvang van enterprises, marketen, industrieën en staten? Zijn er ook andere wijzen waarop orde, integratie en eenheid binnen enterprises gerealiseerd kan worden? Engineering heeft haar waarde, dat heeft ze alom bewezen, maar is deze waarde zo absoluut als ze wordt beleefd? Of valt hier een relativering aan te brengen? Wat zijn de onderliggende aannames waarop engineering zelf is ontworpen?

Het ontwerp achter ontwerpen

Bij engineering volgt een ontwerper het ontwerpproces om ontwerpen te maken. Aan deze drie aspecten liggen veronderstellingen ten grondslag. Eerst het ontwerp. Ontwerpen zijn unieke specificaties. Ze bestaan voor apparaten, voorwerpen, systemen, organisaties en andere artefacten. Maar daarnaast bestaan in de natuur ook andere zaken waarbij een ontwerp wordt verondersteld zoals bij bomen, dieren, de mens, de inrichting van het heelal et cetera. Een ontwerp specificeert een omvangrijk complex aan eigenschappen die aan iets wordt toebedeeld. De vraag blijft echter of een ontwerp wel zo complex en uniek is. Het bewegen van hemellichamen is momenteel verklaarbaar met een aantal eenvoudige fysische wetten. Geldt dit niet voor alle dingen die de natuur heeft voortgebracht? Is het niet gewoon zo dat uniciteit en complexiteit in een ontwerp verondersteld wordt? En doordat dit wordt verondersteld, de ontwerpen die gemaakt worden ook uniek en complex zijn?

Een tweede veronderstelling betreft het ontwerpproces. Omdat ontwerpen unieke specificaties zijn, is het ontwerpproces zelf een creatief proces. Alleen door creatie kunnen unieke ontwerpen bestaan. De veronderstelling is dat dit proces op zichzelf staat en misschien wel afgescheiden van haar omgeving functioneert. Ook hier leert de natuur iets anders. Binnen de ecologie van een bos of regenwoud zijn alle organismen zowel plantaardig of dierlijk van elkaar afhankelijk. Planten en dieren, ieder voor zich beschouwt, zijn zeker uniek, maar ze bestaan niet geïsoleerd van andere planten en dieren. Integendeel de evolutietheorie leert dat de uniciteit van plant en dier juist ontstaat in wisselwerking met het ontstaan van andere planten en dieren, het klimaat, de aarde en andere omstandigheden. Het ontwerpen gebeurt in synergie en niet in autonomie.

Een derde veronderstelling betreft de ontwerper. Omdat het ontwerpproces een creatief proces is, is daar intelligentie voor nodig. Dit kan alleen de mens zijn. Alleen de mens is in staat tot het creatief ontwerpen. Echter, de natuur, in al haar orde, regelmaat en schoonheid is niet door de mens is ontworpen. Welke intelligentie ligt hier dan aan ten grondslag? Bestaan er nog andere ontwerpers? Of is juist deze vraag verkeerd gesteld? Is er wel een ontwerper nodig? Is het niet mogelijk dat mensen, dieren, en planten gewoon kunnen ontstaan? Dat organisaties en systemen zich zelf ontwikkelen. Dat het onderliggende ontwerp ontstaat zonder aanwijsbare ontwerper?

Engineering staat gegrondvest op de intuïtieve verwachting dat orde niet spontaan kan ontstaan. Wanneer we een hoge mate van orde tegenkomen dan verwachten we dat tenminste iets of iemand verantwoordelijk is. Het kan niet zomaar ontstaan. Ook wanneer we systemen aan zichzelf overgelaten worden ze rommelig, ordeloos en ongeorganiseerd. De entropie neemt toe. De onvermijdelijke verslechtering, afkalving, en ontmanteling. De toename van wanorde, inertie en willekeur. Systemen ontstaan en blijven bestaan met een intentie. Ze hebben functie, doel en reden. En voor het creëren en onderhouden van systemen zijn processen nodig die ook met intentie worden opgezet en nageleefd. En intelligente ontwerpers zijn voorwaardelijk nodig om dit mechanisme in stand te houden.

Terugkijkend op de drie veronderstellingen achter ontwerpen: dat een ontwerp uniek is, dat het ontwerpproces creatief is, en dat er een intelligente ontwerper nodig is om dit alles mogelijk te maken, dan is het misschien ook mogelijk om hieraan tegenovergestelde ontwerpen te zoeken. Dit zijn ontwerpen die in plaats van uniek, gemeengoed zijn, waarbij het ontwerpproces in eerste instantie niet creatief verloopt maar replicatief, en waarvoor geen intelligente ontwerper nodig is. Dit zijn ontwerpen die vanzelf ontstaan, waarvan de omstandigheden voor verschijnen ideaal zijn, en die hun reden tot bestaan ontlenen vanuit deze omstandigheden. Dit zijn emergente ontwerpen. Emergente ontwerpen komen tot stand vanuit spontane orde. De vraag is hoe deze orde op enterprise schaal gerealiseerd wordt?

Enterprise emergentie

Omvangrijke organisatievormen als maatschappijen, staten, markten, industrieën en sectoren zijn niet vooraf ontworpen, maar zijn ontstaan op basis van denkbeelden, tijdsgeest, en de initiatieven van diverse partijen die onderling met elkaar, in overleg of conflict, in wisselwerking staan. Deze organisatievormen komen organisch tot stand gelijkaardig als ecologieën in de natuur. Ze kennen een eigen dynamiek en een eenduidige ontwerper is niet direct aanwijsbaar. Ze komen voort uit het samenspel van meerdere partijen met eigen belangen en eigen criteria waarbij evolutionaire processen de boventoon voeren. Enterprises zoals ondernemingen, instituten en overheidsinstanties bestaan op kleinere schaal maar eveneens zijn hier organische kenmerken terug te vinden. Ook deze organisatievormen staan in sterke interactie met hun omgeving waarbij vele partijen en denkbeelden betrokken zijn zonder dat er sprake is van één ontwerper.

Emergentie is het ontstaan van nieuwe en samenhangende structuren, patronen en eigenschappen die plaatsvinden binnen een proces van zelforganisatie in complexe systemen. Bij enterprise emergentie ontstaan deze nieuwe en samenhangende structuren binnen enterprises. Emergente structuren ontstaan spontaan omdat de omstandigheden hiervoor ideaal zijn. Ze komen voort uit noodzakelijkheid. Het zijn geïntegreerde gehelen die over een periode van tijd blijven bestaan. Een markt ontstaat omdat vragers en aanbieders van bepaalde producten bij elkaar komen en over en weer handel drijven. Een samenleving ontstaat doordat deelnemers aan die samenleving gemeenschappelijke waarden, normen en gedragingen omarmen. Een enterprise ontstaat doordat meerdere bedrijven, min of meer, een gezamenlijke visie, missie en doelstellingen hanteren.

Bij emergentie staat replicatie centraal, zoals bij engineering creatie centraal staat. Emergentie gaat uit van bestaand gedrag en kopieert dat, niet enkele malen maar vele malen. Dit kan door afkijken, voortplanten of door welke replicatiemethode dan ook. Een marktpartij mag deelnemen aan een markt wanneer hij dezelfde gedragspatronen volgt als alle andere marktpartijen van die markt. Doet hij dit niet dan ligt hij eruit. Ditzelfde geldt voor deelnemers aan een samenleving, bedrijven binnen een enterprise, cellen binnen een organisme, vogels binnen een zwerm, vissen binnen een school en elk ander emergent patroon. Toon je gedrag in overeenstemming met alle andere deelnemers dan participeer je, vertoon je andersoortig gedrag dan lig je eruit.

Replicatie leidt tot het ontstaan van netwerken. Binnen een netwerk gedraagt ieder knooppunt zich als elk ander knooppunt binnen dat netwerk. De knooppunten van een netwerk zijn geen klonen, integendeel, er is ruimte voor veel verscheidenheid en eigenheid van afzonderlijke knooppunten. Het enige dat gerepliceerd wordt is het gedrag van het knooppunt en niet het knooppunt zelf. Geheel verschillende partijen, groot en klein, van welke aard dan ook, kunnen in eenzelfde markt of samenleving participeren, zolang ze zich binnen die markt of samenleving maar gedragsovereenkomstig gedragen. Een knooppunt kan ook deel uitmaken van meerdere netwerken. Binnen elk netwerk vertoont het knooppunt gedrag dat in overeenstemming is met andere knooppunten van dat netwerk maar over alle netwerken heen is het gedrag steeds verschillend.

Neem e-mail als voorbeeld. E-mail is een systeem om informatieberichten uit te wisselen. Een gebruiker van dit systeem kan berichten zenden of ontvangen. Gebruikers vormen de knooppunten van het netwerk. Zij kunnen zich gedragen als zenders of ontvangers. De wijze waarop verzonden of ontvangen kan worden ligt vast in een protocol, het e-mail protocol. Alleen wanneer gebruikers dit protocol adopteren en zich ernaar gedragen kunnen ze participeren binnen het e-mail netwerk. Ze liggen uit dit netwerk als ze berichten op andere wijze versturen. Het feit dat gebruikers het e-mail systeem kunnen gebruiken zegt niets over de gebruikers zelf. Dit kunnen zowel medewerkers, klanten, leveranciers als bedrijfsapplicaties zijn. De vrijheid in het gebruik van het e-mail systeem, waaronder het versturen van spam, is ongelimiteerd, uitgezonderd het strikte gebruik van het e-mail protocol. Dit laatste is het enige dat is gereguleerd.

Emergentie vormt de basis voor netwerken. Netwerken hebben hun eigen dynamiek gekenmerkt door zaken als: kritische massa, het ontstaan van knooppunten met veel of juist met weinig relaties, het vermogen tot insluiting en uitsluiting van deelnemers, de interne veerkracht van het netwerk om te blijven bestaan wanneer knooppunten wegvallen en meer. Binnen netwerken ontstaan ketens, flows, hubs, en andere stabiele patronen. Ze bestaan tijdelijk, soms voor lange perioden, afhankelijk van de omstandigheden. Binnen het e-mail voorbeeld bestaan gebruikers, die mogelijk duizenden berichten per dag krijgen. Dit zijn de hubs binnen het netwerk en bestaan naast gebruikers die er maar enkele krijgen. Het nut van het e-mail netwerk neemt exponentieel toe naarmate er meer gebruikers participeren en na een omslagpunt heeft het e-mail netwerk een zuigende werking. Kettingberichten kunnen als een cascade vele gebruikers bereiken. Het e-mail netwerk zal blijven bestaan ook al besluiten enkele gebruikers geen berichten meer te versturen of wanneer een e-mail server buiten gebruik raakt. Een netwerk schept zijn eigen autonomie, context, grenzen en vermogens tot zelforganisatie en zelfregulatie. Deze eigenschappen zijn emergent.

Emergentie bestaat op macroniveau in de vorm van patronen. Van deze patronen is het vooraf niet duidelijk hoe ze eruitzien, wanneer ze zullen ontstaan, hoelang ze blijven bestaan, wat voor effecten ze zullen hebben of anders. De patronen kennen een ontwerp dat herkenbaar is, een bepaalde stabiliteit hebben, en redelijk autonoom staan in hun macroscopische omgeving. Binnen deze macroscopische omgeving kennen deze patronen eigenschappen die aan zichzelf worden toebedeeld. Vermogens tot zelforganisatie, zelfregulatie en overlevingsgedrag zijn hier voorbeelden van. Een vermogen tot zelfreplicatie kan weer op een nog hoger macroniveau wederom leiden tot emergente patronen. E-mail systemen vormen de basis waarop weer andere netwerken ontstaan, bijvoorbeeld allerhande samenwerkingsverbanden voor projecten en klanten.

Emergentie op macroniveau bestaat niet los van terugkoppelingen van macroniveau naar microniveau. Één van de redenen dat een knooppunt op microniveau een bepaald soort gedrag vertoond, heeft te maken met dat ze op macroniveau onderdeel uitmaakt van een bepaald patroon. Berichtuitwisseling tussen projectmedewerkers vindt intensiever plaats tussen medewerkers van hetzelfde project dan tussen medewerkers van verschillende projecten. Er bestaat een terugkoppeling van projectniveau naar berichtniveau. Tussen patronen op macroniveau en de afzonderlijke gedragingen op microniveau bestaan dynamische feedback loops.

Standaardisatie is het middel om emergentie binnen enterprises mogelijk te maken. Een standaard is een ontwerpspecificatie die gedeeld wordt door meerdere artefacten. Standaarden maken replicatie van gedrag mogelijk. Wanneer ieder project op eigen wijze wordt uitgevoerd, en er geen ervaringen worden gedeeld over projecten heen, bijvoorbeeld in de vorm van projectstandaarden, dan is er geen emergentie mogelijk. Wanneer projecten uitgevoerd worden op overeenkomstige wijze, door wel gebruik te maken van projectstandaarden, dan is emergentie wel mogelijk. Ditzelfde geldt voor alle artefacten binnen een enterprise, de diensten, de processen, de applicaties en meer. Projectstandaarden, processtandaarden, informatiestandaarden, technologiestandaarden en anderen leiden tot emergentie binnen enterprises.

Standaardisatie wordt mogelijk vanuit sturing en vanuit faciliteit. Vanuit sturing houdt in dat een standaard wordt opgesteld en vervolgens hiernaar wordt gehandeld en artefacten worden ontwikkeld met gebruikmaking van de standaard. Dit is een top-down proces. Een bottom-up proces is eenzelfde werkwijze of artefact meerdere keren toepassen of repliceren. Zo ontstaan de-facto standaarden. Eikenbomen zijn eiken omdat eiken dezelfde eigenschappen delen. Het delen van deze eigenschappen is voortgekomen uit het voortplantingsgedrag van eiken. Achteraf ontdekken we de eigenschappen van eiken, het ontwerp. De eigenschappen zijn niet vooraf in een eikenstandaard gedefinieerd.

Emergentie is in de kern onvoorspelbaar. De organische ontwikkelingen binnen emergente systemen kunnen alle kanten uitgaan, zowel positief als negatief. Zowel crisis als schoonheid zijn spontaan mogelijk. Het dynamische karakter van emergentie, de feedback loops, de vermogens tot zelf organisatie en andere eigenschappen geven een onvoorspelbaarheid en onzekerheid die de besturen binnen enterprises kan doen afschrikken. Daarnaast zal door toenemend gebruik van technologische netwerken, zoals het Internet, e-mail en andere de-facto standaarden de onvermijdelijkheid van emergentie voor enterprises toenemen. De voordelen wegen ruimschoots op tegen de nadelen bij het gebruik van dit soort standaarden. Enterprises hebben daarom te maken met een dilemma. Vanwege de onvoorspelbaarheid willen ze emergentie buitensluiten. Vanwege de diverse voordelen kunnen ze er niet aan ontkomen. Ze moeten iets met emergentie.

De onvoorspelbaarheid van emergentie impliceert niet dat emergentie onbeheersbaar is. De protocollen van netwerken, de standaarden, de regels waaronder gedrag repliceerbaar wordt, zijn zeer beheersbaar. Deze beheersbaarheid is wel van een andere orde dan die met engineering wordt bereikt. Voordat e-mail gemeengoed werd, werden er systemen ontwikkeld waarin expliciet werd aangegeven, wie met wie informatie mocht uitwisselen. Ieder geautomatiseerd systeem van redelijke omvang kreeg deze functionaliteit. Bij wijzigingen zoals het toevoegen of veranderen van gebruikers moest het systeem worden aangepast. Met e-mail ligt de beheersbaarheid bij het protocol. En als het protocol functionaliteiten in zich heeft voor autorisatie, personalisatie en rechtenbeheer dan kan functioneel hetzelfde worden bereikt maar met veel minder beheerslast. Er zijn minder systemen te onderhouden. En gebruikers kunnen zelf bepalen of en in welke mate bepaalde functionaliteiten gebruikt worden. De beheersbaarheid die met emergentie te bereiken valt licht op het niveau van groepen, collectieven en samenwerkingsverbanden, al dan niet tijdelijk of spontaan. Bij engineering ligt de beheersbaarheid op het niveau van individuen, of afzonderlijke componenten.

Voor enterprises bestaan meer verschillen tussen engineering en emergentie. Voor het opzetten van een eigen architectuur stijl is meer inzicht in deze verschillen wenselijk.

Enterprise engineering en enterprise emergentie vergeleken

Engineering is het meest effectief op microniveau terwijl emergentie het meest effectief is op macroniveau. Voor het realiseren van systemen hebben bouwers ontwerpen nodig die met zekerheid zijn opgesteld. Deze zekerheden, in de vorm van specificaties, zijn het best te verwerven op microniveau. De zekerheden zijn nodig om systemen te bouwen binnen kaders van inspanning, tijd, kwaliteit en geld en hebben betrekking op functie, operationele context, gebruik van componenten, materialen, en meer. Voor het stabiel houden van specificaties hanteren ontwerpers allerhande beperkingen, zoals scope setting, aannames, en randvoorwaarden, waarmee een stabiele, gesloten, onveranderlijke operationele context voor het systeem wordt verondersteld. Ze stellen harde grenzen op. Ze beperken het aantal componenten. Ze trachten ongewenste bijeffecten te voorkomen. In het ontwerpproces plannen ontwerpers top down en stapsgewijs. Ze brengen focus aan, decomponeren ontwerpen in deelontwerpen, maken sterke resultaatafspraken en stellen acceptatiecriteria op. Alles is gericht op het bereiken en behouden van zekerheid. Deze zekerheid is het best te verzekeren op microniveau. Engineering is daarom op dit niveau het meest effectief.

Voor emergentie gelden andere condities. Deze condities leidden tot de conclusie dat emergentie het meest effectief is op macroniveau. Deze andere condities zijn tegengesteld aan de condities op microniveau waaronder engineering effectief is. Als het bij engineering onder meer gaat om beperking, zekerheid, stabiliteit, geslotenheid, uitsluiting en permanentie gaat het bij emergentie om overvloed, onzekerheid, dynamiek, openheid, insluiting en tijdelijkheid. Het ontwerpproces verloopt bij emergentie bottom-up, gelijktijdig, spontaan, en organisch. Bij engineering top-down, sequentieel, voorzien, en mechanistisch. Onderstaande tabel vat een aantal aspecten samen.

Engineering

Emergentie

Artefact

Kunstmatig

Natuurlijk

Denkwijze

Mechanisch, reductionistisch, gericht op autonomie, gericht op bezit

Organisch, holistisch, gericht op synergie, gericht op delen

Coördinatie

‘Comply or Explain’, Hiërarchisch, top-down, taakgericht, directief, sequentieel, voorspelbaar, governance, extrinsieke motivatie

‘Apply or Invent’, Netwerk, bottom-up, expertise gericht, spontaan, gelijktijdig, toevallig, engagement, intrinsieke motivatie

Ontwikkelomstandigheden

Zeker, voorspelbaar, stabiel, beperking, uitsluiting, kortdurig

Onzeker, onvoorspelbaar, dynamisch, overvloed, insluiting, langdurig

Ontwikkelperspectief

Creatie, Autonomie, Intern, lokaal, micro, kleinschalig, gesloten, individueel, innovatief, voorzien, permanent

Replicatie, Synergie, Extern, globaal, macro, grootschalig, open, collectief, standaard, spontaan, vergankelijk

Engineering wordt minder effectief naarmate ze meer op macroniveau wordt ingezet. Wanneer de omvang van het systeem dat ontworpen moet worden groter wordt, meer deelcomponenten in zich heeft, in een meer onstabiele of onvoorspelbare omgeving moet opereren of kortom op een schaal moet worden gerealiseerd waar beperkingen niet of nauwelijks te hanteren zijn, nemen de risico's toe en is meer inspanning, tijd en geld nodig voor realisatie. Engineering wordt onder deze omstandigheden onbeheersbaar en ineffectief. In overeenstemming hiermee geldt voor emergentie dat ze minder effectief ingezet kan worden op microniveau, naarmate er meer beperkingen, minder overvloed, meer stabiliteit en meer geslotenheid aanwezig is.

Het tegenovergestelde karakter van engineering ten opzichte van emergentie maakt het mogelijk om beide bewegingen binnen enterprises gecombineerd in te zetten. Ze vullen elkaar aan en kunnen elkaar versterken.

Enterprise engineering en enterprise emergentie gecombineerd

Enterprises combineren engineering met emergentie het meest effectief door op microniveau engineering te hanteren en op macroniveau emergentie. De beperkingen voor de een zijn de vrijheden voor de ander. Emergentie geeft op macroniveau beheersbaarheid op gebieden van collectiviteit, decentralisatie, uniformiteit, interoperabiliteit, transparantie, gemeenschappelijkheid, gelijkheid, solidariteit en synergie. Engineering geeft op microniveau beheersbaarheid op de gebieden specialisatie, centralisatie, uniciteit, individualiteit en autonomie. Enterprises hebben beide vormen van beheersbaarheid nodig, maar alleen niet voor ieder thema, zaak of onderdeel. Voor concurrentievoordeel is specialisatie, innovatie en onderscheidend vermogen gewenst. Voor kostenvoordelen is generalisatie, standaardisatie en gemeenschappelijkheid gewenst. Voor een product leader is specialisatie en uniciteit van producten gewenst. Een operationeel excellente onderneming zal echter eerder uitgaan van processtandaardisatie.

De combinatie van engineering en emergentie is voor ieder bedrijf anders hoewel de mechanismen achter beide gelijk zijn. Bekendheid met beide mechanismen en bekendheid met de wijze hoe ze op elkaar inspelen zal architecten helpen de unieke combinatie voor de enterprise te realiseren. Deze combinatie kan worden vastgelegd in een unieke stijl van architectuur binnen de enterprise. Op welke onderdelen van de onderneming – producten, processen, systemen – zullen architecten meer nadruk leggen op engineering dan wel emergentie? Hoe kunnen architecten hun keuzes hierover afleiden van missies, doelstellingen en omgevingsfactoren? Hoe dragen ze zorg voor disciplinering, terugkoppeling en leer effecten? Hoe voorkomen ze stilstand in verandering en brengen en houden ze enterprises in beweging? Architectuur is intrinsiek een dynamisch spel waarbij vele partijen betrokken zijn. Zonder zicht op emergentie in combinatie met engineering is dit spel onbeheersbaar. Hoeveel architecten zijn zich hiervan bewust?

De combinatie van engineering met emergentie volgt een cyclus. Door te creëren maken architecten een nieuw artefact. Ze repliceren dit. Bij voldoende replicaties ontstaan emergente patronen. Deze patronen beïnvloeden vervolgens via terugkoppeling de omgang met artefacten op microniveau, waaronder de replicatie van nieuwe gelijksoortige artefacten. Bij overschrijding van kritische niveaus, treedt steeds verdere versnelling van deze cyclus op. Het fenomeen van killerapplicaties zijn typische voorbeelden hiervan. Bij de introducties van producten als fietsen, elektrisch licht en auto's zijn deze cycli goed te herkennen, waarbij het gebruik van deze producten heeft geleid tot verdere toename in gebruik, waarbij ze bestaande structuren als kaarslicht en vervoer met paard en wagen overbodig heeft gemaakt en vervolgens nieuwe heeft gestimuleerd, zoals benodigde infrastructurele aanpassingen in stad en land.

Andere voorbeelden vormen de monolithische IT landschappen binnen enterprises. De monolieten binnen deze landschappen zijn autonoom en bestaan uit sterk geïntegreerde bedrijfsprocessen en systemen. Gegevensuitwisseling wordt verzorgd door allerhande specifiek ontwikkelde koppelingen met andere monolieten. De complexiteit van deze landschappen is enorm. Er is geen architect die vooraf en met vooropgezette bedoeling deze monolithische systeemlandschappen ontworpen heeft. Ze zijn ontstaan en achteraf terugkijkend is het monolithische patroon in deze landschappen ontdekt. Ze zijn emergent. De oorzaak van het ontstaan van deze landschappen ligt in de werkwijze van creatie. Elke monoliet is gebouwd aan de hand van een werkwijze waarbinnen projectmanagement en de business case centraal staat voor de gehele inrichting van bedrijfsproces tot technologisch systeem. Binnen deze geïsoleerde kaders kwam de monoliet tot stand. Vervolgens is het noodzakelijk de monoliet toe te voegen aan en te integreren met het bestaande landschap. Hiervoor zijn allerhande specifiek ontwikkelde koppelingen nodig. Deze werkwijze is vervolgens op elke vervolgontwikkeling toegepast. Het herhaalde karakter is dus de werkwijze rondom business cases gecombineerd met projectmanagement. Hoewel elke monoliet op zichzelf beschouwd verschilt van andere monolieten, is het monolithische patroon ontstaan uit replicatie van eenzelfde werkwijze. Hoe anders zullen IT landschappen worden wanneer andere werkwijzen worden toegepast? Bijvoorbeeld, werkwijzen waarbij gebruikgemaakt wordt van gedeelde technologie platformen, gestandaardiseerde processen of gemeenschappelijke financiering?

Een belangrijke rol voor architecten is weggelegd bij het ontdekken en leren van bestaande werkwijzen en het anticiperen op veranderingen in enterprises wanneer andersoortige werkwijzen worden toegepast. Het onderscheid tussen engineering en emergentie is daarbij van belang omdat voor een zekere enterprise, de combinatie in gebruik uniek is. Enterprises halen weinig voordeel uit het klakkeloos kopiëren van werkwijzen van andere enterprises. Omdat zij een unieke plaats in markt en samenleving hebben, hebben ze een unieke combinatie nodig van factoren van engineering en emergentie. Een product leader in een bepaalde industrie heeft weinig aan het overnemen van processtandaarden van een operationeel excellente onderneming. De snelheid van haar productvernieuwing kan hieronder lijden. Het kunnen onderscheiden van engineering van emergentie is een belangrijk diagnose instrument.

De architectuurstijl van een enterprise ligt vast in de standaarden die ze gebruikt. Het gebruik van standaarden leidt tot emergentie door replicatie van gebruik. Standaarden bestaan zowel voor de onderdelen van enterprises, zoals producten, diensten bedrijfsprocessen, informatieberichten, applicaties, en technologische infrastructuur, als voor de wijzen waarop deze onderdelen veranderd worden, bijvoorbeeld door gebruik te maken van projectmanagement, architectuur management, investeringsmanagement en risico management. De combinatie van standaarden en het gebruik hiervan in allerhande voorzieningen bepalen de unieke ontwikkeling van de enterprise, haar unieke balans tussen engineering en emergentie.

Een bijkomend doel van een architectuurstijl is een enterprise in beweging te krijgen en te houden op de noodzakelijke veranderingen die moeten worden doorgevoerd. Ze werkt tegendraads als de enterprise tot stilstand komt en verzandt in inertie. Op microschaal komt een enterprise in beweging bij een duidelijke, afgekaderde en afgestemde ambitie en een bijbehorend stappenplan. De gewenste toekomstige situatie is leidend om in beweging te komen. Op macroschaal echter, blijft een enterprise in beweging bij een combinatie van een richtinggevende visie, als een stip aan de horizon, en het gebruik van standaarden die nu gehanteerd moeten worden om deze visie te bereiken. De toekomstige situatie is niet leidend maar de huidige situatie. De standaarden welke een organisatie in staat is om te hanteren in de huidige situatie, bepalen het verandervermogen van de organisatie en daarmee het vermogen om in beweging te komen, te blijven en uiteindelijke doelen te bereiken. Ook hiervoor is een balans tussen engineering en emergentie van belang.

Conclusie

Een enterprises is een unieke constellatie van bedrijven, processen en systemen. Ze bekleedt een unieke positie binnen markten waar ze haar producten en diensten afzet. Deze unieke positie ligt vastgelegd in de wijze waarop de architectuur van de enterprise is vormgegeven. De stijl van architectuur die de enterprise hanteert is samengesteld uit kenmerken van engineering en emergentie. Zij bepaald de wijze waarop de enterprise met veranderingen omgaat. Inzicht in het gebruik van emergentie naast engineering is cruciaal voor beheersbaar veranderen van enterprises.

Het verandervermogen van een enterprise ligt besloten in de wijze waarop de enterprise met standaarden omgaat. Voert de enterprise portfolio management over haar standaarden? Hoe ligt de eigenschap van specifieke standaarden? Zijn er mechanismen die standaardisatie stimuleren dan wel afremmen? Worden de standaarden van buitenaf betrokken of dicteert de enterprise juist de standaarden voor de industrie en markt waarbinnen zij opereert? Wat is de standaard werkwijze waarop de enterprise met standaarden omgaat? Wat is haar standaardisatie standaard?

Architecten blijven in de kern ontwerpers en zijn als zodanig gebonden aan de beperkingen die engineering biedt in vergelijking tot emergentie. Het menselijke bevattingsvermogen speelt daarbij een cruciale rol. Echter, ze kunnen emergentie, en daarmee ‘de natuur’ een handje helpen door strakker op de standaarden te gaan zitten. Enerzijds ondersteunen ze daarbij de beheersbaarheid en maakbaarheid van de enterprise terwijl aan de andere kant ze organische en emergente ontwikkelingen mogelijk maakt. Er blijven risico's verbonden aan deze organische ontwikkelingen. Zo zijn crisissen in netwerken niet uit te sluiten. Maar de kwaliteit van de standaarden bepalen mede of in netwerken zelfcorrigerende en zelfherstellende mechanismen ontstaan. Deze zijn misschien niet maakbaar maar wel ontstaanbaar.

[PDF]

Opmerking

Je moet lid zijn van Via Nova Architectura om reacties te kunnen toevoegen!

Wordt lid van Via Nova Architectura

Sponsoren

Sessies

19-06: KNVI/PLDN sessie over semantische data integratie in de weg- en spoorinfrastructuur 

28-06: LAC summit meer...

15/16-11: Landelijk Architectuur Congres meer...

Advertenties

Je kunt hier adverteren

© 2018   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden