vrijdag 21 mei 2010

Excellente organisaties

Sommige organisaties excelleren. Ze domineren hun markt, zijn de lieveling van beleggers en werken als een magneet op talent. Er zijn tal van boeken geschreven over het geheim achter zulke successen. En de centrale boodschap is in de loop van jaren nauwelijks veranderd. Een excellente onderneming heeft niet genoeg aan goede producten (er was bijvoorbeeld weinig mis met de producten van Fokker en DAF trucks), aan gestroomlijnde processen (zoals bij de DSB), aan slimme mensen (Philips Natlab, KPN research en vele anderen), geraffineerde marketing (zelfs de marketingmachine van Microsoft bleek niet in staat om Windows Vista tot een succes te maken), laat staan dat een organisatie met een state of the art informatievoorziening het verschil kan maken. Het gaat er juist om dat al die verschillende aspecten met elkaar in verband zijn. Dat ze elkaar versterken. Dat het klopt.

Van Olie tot Zand: Terug naar de Tekentafel?

Enterprise Architectuur is een ander woord voor de samenhang tussen al die verschillende aspecten die een organisatie tot een succes kunnen maken. De kwaliteit van de enterprise architectuur laat zich aflezen aan het succes dat de organisatie heeft. Met andere woorden: een excellente organisatie heeft per definitie een excellente enterprise architectuur. En een gemankeerde enterprise architectuur is een symptoom van een gemankeerde organisatie.

Het is niet eenvoudig om een excellente organisatie te worden. Om de juiste balans te vinden. Om alle stakeholders tevreden te krijgen. En als dat eenmaal is gelukt, dan is het helemaal een kunst om die status te bestendigen. Om het momentum vast te houden. Om geen eendagsvlieg te worden. Om dat te bereiken moet een organisatie zich snel en soepel kunnen aanpassen aan wijzigende omstandigheden. Vanzelfsprekend geldt die aanpasbaarheid niet alleen voor de producten en de processen, maar ook voor de medewerkers en de gebruikte technologie. Duurzaam succes vraag COPAFIJTH-breed om een top-conditie. Om lenigheid. Om Agility.

In de praktijk van enterprise architectuur zijn het merkwaardig genoeg vaak de enterprise architecten die de enterprise agility in de weg lijken te staan. De dikke handboeken (of zijn het tegenwoordig wiki's?) met regels wat wel en niet is toegestaan en de governance processen die het naleven van de regels afdwingen worden meer en meer ervaren als een rem op vernieuwing. Waar enterprise architectuur oorspronkelijk was bedoeld om organisaties flexibeler en daadkrachtiger te maken, als olie in de machine, is het verworden tot een verlammende bureaucratie, tot zand in de machine. Oops!

Ik hoop natuurlijk dat ik de enige ben die ervaart dat de enterprise architectuur los is komen te staan van de business. Ik zou oprecht blij zijn als mijn analyse volstrekt de plank mis slaat. Zo niet, dan wordt het de hoogste tijd om over oplossingen na te gaan denken. Om terug te gaan naar de tekentafel.

Mijn visie

Enterprise Architectuur wordt wel gezien als het (al dan niet impliciete) resultaat van enterprise engineering. Enterprise engineering is de toepassing van de technieken voor de ontwikkeling van complexe technologische systemen om complexe socio-technologische systemen – a.k.a. enterprises – te realiseren. Ondernemingen ontwikkelen op de manier waarop je een nieuwe Boeing ontwikkelt – om de favoriete vergelijking van de patriarch van de enterprise architecten – John Zachman – nog maar eens van stal te halen. Eerst een coherente visie opstellen, dan een holistische architectuurbeschrijving maken en daarna bouwen. Wat zonder een complete, consistente en correcte architectuurbeschrijving kun je een systeem niet analyseren, laat staan aanpassen aan gewijzigde omstandigheden. Dus als je wilt dat je een organisatie kunt aanpassen, dan kun je maar beter zorgen voor een volledige, actuele beschrijving van alle informatie, processen, producten, functies, gebouwen, machines en niet te vergeten de motivatie waarop alle gemaakte ontwerpkeuzes zijn gebaseerd. Een beschrijving van alle abstracties vanuit alle perspectieven. Voor een beetje organisatie is dat een flinke klus. Maar ja, het kost ook een jaar of 10 om een nieuw vliegtuig te ontwikkelen, dus het is niet zo vreemd als je ook een aantal jaren nodig hebt voor een fatsoenlijke beschrijving van je organisatie, toch? Een beetje organisatie is immers minstens zo complex als een vliegtuig. Nou dan!

Helaas, helaas, het opstellen en bijhouden van een dergelijke uitputtende enterprise architectuurbeschrijving heeft alle kenmerken van een Sysiphus-kwelling. Het komt nooit af, en wat er af is, is al snel achterhaald. Het kost een berg en het wast een beetje.

En toch heeft Zachman wel degelijk een punt. Hoe kun je ooit een bedrijf effectief besturen als je niet precies weet hoe het werkt?

Enterprise engineering is bij uitstek een metafoor uit het industriële tijdperk. Een metafoor die is ontleend aan het bouwen van fabrieken en machines. Het fascinerende van onze tijd is dat we de overgang beleven van het industriële tijdperk naar het informatietijdperk. Een overgang die de samenleving in al zijn haarvaten gaat raken. Ook organisaties. Een overgang die vraagt om een principieel andere benadering van problemen. Zouden we dan niet op zoek moeten naar een betere metafoor? Naar een nieuwe inspiratiebron?

What would Google do?i

Google is zo langzamerhand uitgegroeid tot het schoolvoorbeeld van een bedrijf van de nieuwe tijd. Een bedrijf met een aantal hele duidelijke beginselen. Follow the facts, bijvoorbeeld. Dus niet teveel tijd verspillen met analyses vooraf, maar zo snel mogelijk de markt op met een goed idee; vervolgens goed meten wat er gebeurt en snel reageren op de ontwikkelingen. Best wel agile...

Wat zou dat kunnen betekenen voor enterprise architectuur? Ik zou zeggen dat we als community eens heel goed na zouden moeten denken over hoe we zoveel mogelijk relevante informatie zouden kunnen oogsten uit het informatielandschap. Dat kan klassieke enterprise architectuur informatie zijn over de processen, producten en informatiesystemen, maar je zou dat heel goed kunnen uitbreiden met allerlei relevante gebruiksstatistieken – objectieve informatie over het wel en wee van het informatielandschap. Informatiemanagement informatie.

In mijn visie zou dat een richting zijn om heel veel van onze bestaande problemen in één klap op te kunnen lossen. Door de traditionele scheiding tussen de beschrijving van een systeem en het systeem zelf los te laten en te gaan werken aan zelfbeschrijvende systemen. De architectuurbeschrijving zou dan altijd up-to-date zijn, en consistent, compleet en zo gedetailleerd als we nodig vinden. Iedere verandering die in het landschap wordt doorgevoerd wordt onmiddellijk gereflecteerd in de architectuurbeschrijving. Achterstallig onderhoud van de documentatie is weggeautomatiseerd. Beschrijvingen worden betrouwbare feiten.

In een aantal opzichten doen we dat eigenlijk al. De metadata in een DBMS, de processchema's in een BPMS, de regels in een rules engine, de BPEL-scripts in de ESB en de definities van Virtuele Machines zijn evenzovele voorbeelden van zelfbeschrijvende componenten. En naarmate meer en meer modelgedreven applicaties tot de realiteit gaan behoren, kunnen we sneller betere architectuurbeschrijvingen oogsten uit het landschap. Het wordt de hoogste tijd om een geïntegreerde visie te ontwikkelen op alle meta- en managementinformatie die ons informatielandschap ons als architecten kan bieden. En om op basis van zo'n visie beleid te gaan ontwikkelen voor de kwaliteit van die informatie en voor het invullen van de witte vlekken die er nu ongetwijfeld nog zijn. En om na te denken over de tools die we nodig hebben om die rijkdom aan informatie te oogsten, te interpreteren en te analyseren.

Dat zal direct een positieve invloed hebben op de zo gezochte business agility. Ga maar na. Alle wijzigingen die geen reële risico's vormen voor de continuïteit kunnen zonder enige vertraging doorgevoerd worden. Modelwijzigingen kun je vrij eenvoudig simuleren. Daarmee kun je ook heel snel de impact van veranderingen met risico's feitelijk analyseren. En uiteindelijk kun je systemen modelleren met ingebouwde vrijheidsgraden die zichzelf op basis van de verzamelde feiten automatisch en voortdurend verbeteren. Van infrastructuur tot beslisregels kan de gewenste dynamiek in het landschap ingebouwd worden. Het landschap kan zelf intelligent worden. Dan kunnen wij ons tenminste met echte innovaties gaan bezighouden.


i Jeff Jarvis: “What Would Google Do?”; HarperBusiness, First Edition (January 27, 2009).

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

1 opmerking:

Greg Andrin zei

ik ben rijk geworden met deze geprogrammeerde gehackte pinautomaat
Nadat ik klaar was met studeren, was er geen werk, dus besloot ik een klein bedrijf te beginnen, maar het geld was niet genoeg, ik sloot het bedrijf, het werd erg moeilijk voor mij, ik was het enige kind van mijn ouders en mijn ouders. Ze zijn allebei oud, ze geloven in mijn dagelijkse voeding, op een dag zag ik tijdens het surfen op internet een bericht over hoe deze NIEUWE VERVANGEN ONTVANGEN ATM-KAART een geldautomaat kan hacken en een groot bedrag kan opnemen, dus nam ik contact op met het bedrijf via uw e-mail. Tot mijn grootste verbazing ontving ik de kaart een paar dagen nadat ik een kleine vergoeding voor de kaart had betaald. Deze blanco ATM-kaart is een geweldig en prachtig product. Ik zou nooit geloven dat al deze dingen die ik vandaag heb kunnen worden verworven met deze grote vreugde in mijn hart, daarom breng ik het goede nieuws over ... Het leven is positief en geduldig zijn, in de overtuiging dat grote dingen mogelijk zijn en kan gebeuren in seconden. .. BRAIN HACKERS TECH WORLD heeft mijn leven veranderd ... Godzijdank kun je een e-mail sturen naar VIA (brainhackers@aol.com)