dinsdag 29 juli 2008

Naakte SOA

Jim Webber komt de eer toe om als eerste – of op z'n minst één van de eerste – software analist publiekelijk zijn afkeer geuit te hebben van een “fat SOA”. Zijn levendige en amusante bijdrage aan de Qcon 2007 conferentie onder de titel “Guerilla SOA” [1] heeft ongetwijfeld velen aan het denken gezet. De laatste weken zijn vele industrie-goeroes hem in zijn voetsporen gevolgd. Onder hen bekende namen als Martin Fowler [2], David Linthicum [3] en Joe McKendrick [4]. Het onderwerp prikkelt op z'n minst de creativiteit. Kwalificaties als “Manboobs”, vergelijkingen met “Junk Food” en woordgrapjes als “Enterprise Service Busted”, “Erroneous Spaghetti Box” en “Same Old Atrocity” zijn niet van de lucht. Het lijkt wel een collectieve actie van de softwareontwikkelaars en -architecten gericht tegen de grote boze leveranciers met hun dikke, dure middleware. Tijd voor een dieet?


Het debat

Een naakte SOA is een “back to basics” architectuur. De gedachte is even sympathiek als simpel. Het web is de beste architectuur die het vakgebied tot nu toe heeft voortgebracht. Sir Tim Berners-Lee heeft als geestelijk vader van het web een voorbeeldige prestatie verricht. Het web is schier oneindig schaalbaar, en het biedt een platform voor applicaties die in de verste verte niet te voorzien waren. Waarom zouden we het dan nu moeilijk maken met een ESB?

Het web is van nature één en al middleware. En de grote kracht van het web is dat het zo dom is. Berners-Lee heeft heel bewust voor gekozen voor een oersimpele architectuur. Hij wilde bijvoorbeeld het probleem van de “broken links” niet door het netwerk op te laten lossen. Dat kunnen de gebruikers van het netwerk veel beter zelf doen. In Europa zouden ze zoiets het subsidiariteitsbeginsel noemen – probeer de verantwoordelijkheid voor het oplossen van een probleem zo dicht mogelijk bij de bron te leggen. En applicatie­ontwikkelaars met een integratieprobleem hebben een meer dan begrijpelijke weerzin tegen het oplossen van zo'n probleem op enterprise niveau (waarschijnlijk nog meer dan met enterprise technologie).

Het web als middleware is goed, het is bewezen, dus wie nog betere middleware aan de man wil brengen moet van goede huize komen. En als “betere middleware” alleen zou betekenen dat er intelligentie in het netwerk wordt gesmokkeld die innovaties tegengaat en die dus de oerkracht van het web ondermijnt, dan zou het inderdaad tijd worden om de stormbal te hijsen.

Toch zijn er ook geluiden dat leveranciers niet zelden al te gemakkelijk als zondebok voor jammerlijk mislukte SOA-projecten worden gebruikt. Het is nou eenmaal verleidelijk om de schuld van zulke mislukkingen buiten de eigen organisatie te zoeken. Ik heb zelf nog geen enkel SOA-project gezien dat is mislukt puur vanwege falende technologie. Ik ken wel projecten die zijn mislukt omdat er overspannen verwachtingen waren van de magische vermogens van technologie om architectuurproblemen te verhelpen. Typische voorbeelden van het “Same Old Architecture” probleem. Iedere keer als dezelfde architecten die een bestaand architectuurprobleem niet hebben kunnen voorkomen geacht worden om het op te lossen, dan is de kans niet denkbeeldig dat ze opnieuw in dezelfde valkuilen vallen.

Het is de verdienste van David Linthicum [5] om al zeker 10 jaar onvermoeibaar te hameren op het gevaar van “vendor driven architecture” [3], [6-9]. Hij laat ook geen gelegenheid onbenut om erop te hameren dat een succesvolle transformatie naar een SOA geen tactische operatie is die in een projectvorm tot een goed einde kan worden gebracht, maar dat het een strategische keuze moet zijn die een verandering van lifestyle vereist. In die zin is het domweg opbergen van de bestaande inter-application spaghetti in een blackbox met het label ESB inderdaad een recept voor ellende. Maar is dat nou de schuld van de leveranciers?


De naakte waarheid

Hoe zat het ook al weer. David Chappel – de auteur die het begrip ESB groot heeft gemaakt – stelt het zo: “The ESB provides a highly distributed, event-driven Service Oriented Architecture (SOA) that combines Message Oriented Middleware (MOM), web services, intelligent routing based on content and XML data transformations” [10]. Afgezien van het gebruik van het woord “architectuur” als synoniem voor “infrastructuur” beschrijft dit de kern van de ESB-propositie. De ESB als glueware, met een rijkdom aan functionaliteit om componenten en services losjes (“loosely”) te koppelen.

Oracle beschrijft een ESB als “the underlying infrastructure for delivering a service-oriented architecture (SOA) and event-driven architecture (EDA)” [11]. IBM houdt het op een “infrastructure service that provides robust communication, intelligent routing, and sophisticated translation and transformation of services” [12].

ESB is dus geen oplossing voor een architectuurprobleem. Het is een tool om makkelijk bestaande applicaties van een service-interface te kunnen voorzien, om makkelijk composiete services samen te kunnen stellen en om bepaalde governance­taken te centraliseren. In een ideale wereld zou je waarschijnlijk geen proprietary ESB willen gebruiken. Vendor-lock-in's zijn nooit aan te bevelen. Misschien kun je zelfs wel stellen dat het niet wenselijk is om in een green-field situatie een ESB als concept te gebruiken. Complexiteit voorkomen is altijd beter dan complexiteit beheersen, niet waar?

Een ESB kan naar mijn mening wel degelijk helpen om bijvoorbeeld een legacyprobleem op te lossen. Zie het maar als een stap in een migratie­strategie. Als een truc om gedurende de vlucht de lekke band van een vliegtuig te plakken. Noem het van mij part een “One-night stand”. Weggooiarchitectuur desnoods. Een noodzakelijk kwaad. Maar zie een ESB als een nuttig instrument om problemen die in de loop van de jaren zijn gegroeid te tackelen. Een ESB is niet de bron van de organisatorische en architecturele problemen. Dan is het toch raar om leveranciers te verwijten dat hun EBS die niet kan oplossen?

Een paradigmaverandering gaat altijd gepaard met vallen en opstaan. Het was zo bij de invoering van relationele databases, het was zo met de adoptie van het web en het is zo bij de transformatie naar enterprise architectuur. Succesverhalen en mislukkingen wisselen elkaar af, maar uiteindelijk vinden we met z'n allen een balans die de industrie een hoger plan brengt. Daarbij hebben technologische innovaties altijd een rol gespeeld en er is geen enkele reden om te denken dat zoiets dit keer niet zal gebeuren. De “peak of inflated expectations” [13] ligt inmiddels achter ons, zo veel maakt dit debat wel duidelijk. We zullen de “trough of disillusionment” nog doormoeten om te ontdekken welk potentieel ESB's op termijn zullen bieden, dan wel hoeveel of hoe weinig kleren een effectieve SOA infrastructuur nodig heeft.

Een ding is zeker. Een typische eilandorganisatie met een bijbehorende archipelarchitectuur zal heel wat weerstand moeten overwinnen voordat het zich een cultuur van bruggenbouwen en samenwerken eigen heeft gemaakt. Op termijn is het opsplitsen van zulke organisaties het enige alternatief voor synergetische samenwerking. Wat dat betreft is de markt ongenadig.

In deze kwestie wordt een actueel thema op een scherpe manier geanalyseerd. Het is de 10de in een reeks die op dit weblog gepubliceerd zal worden.

Bronnen

[1] http://www.infoq.com/presentations/webber-guerilla-soa

[2] http://www.infoq.com/presentations/soa-without-esb

[3] http://weblog.infoworld.com/realworldsoa/

[4] http://blogs.zdnet.com/service-oriented/

[5] http://www.davidlinthicum.com/WhoWeAre.html

[6] David S. Linthicum: “Enterprise Application Integration”; Addison-Wesley, 1998.

[7] David S. Linthicum: “B2B Application Integration: e-Business-Enable Your Enterprise”; Addison-Wesley, 2000.

[8] David S. Linthicum: “Next Generation Application Integration”; Addison-Wesley, 2003.

[9] http://www.davidlinthicum.com/paperspresentations.html

[10] David A Chapel: “Enterprise Service Bus”; O'Reilly, 2004.

[11] Vimmika Dinesh et al: “Oracle® Enterprise Service Bus Quick Start Guide 10g”; Oracle website, sept 2006.

[12] Naveen Balani: “Model and build ESB SOA frameworks”; IBM website, mrt 2005.

[13] De Gartner Hype cycle wordt onder andere bechreven op wikipedia, zie http://en.wikipedia.org/wiki/Hype_cycle.

maandag 21 juli 2008

Impedantie Matching

Bedrijfsarchitecten hebben als functie om te analyseren en te adviseren hoe je bedrijfsfuncties het beste in kunt richten. Evengoed hebben applicatiearchitecten zo’n functie voor applicatiefuncties en infrastructuurarchitecten voor infrastructuurfuncties. Het wordt pas lastig als men zich gaat afvragen wie nou in staat zou zijn om de architectuurfunctie zélf in te richten. Het is dan ook niet verwonderlijk dat het ontwikkelen van de bedrijfsarchitectuur van de architectuurfunctie vaak een moeizame bevalling is. Het functioneren van deze bedrijfsfunctie laat dan ook wel eens te wensen over. Het zou meer dan jammer zijn als dit het prille vakgebied zou belemmeren in zijn ontplooiing. In deze column wordt daarom vanuit een organisatiekundig perspectief betoogd wat de unique selling point van enterprise architectuur is.

Het Ontwerp van de Architectuurfunctie

De management goeroe Eliyahu Goldratt heeft er zijn levenswerk van gemaakt om de boodschap te verkondigen dat het zinloos is om in alle bedrijfsfuncties tegelijkertijd een beetje te investeren – het eindresultaat dat zo kenmerkend is voor doorgaans enerverende budgetteringsrondes. Goldratt wordt niet moe om erop te wijzen dat deze praktijk vooral verspilling bevordert. Bedrijven zouden volgens zijn «theory of constraints» in plaats daarvan moeten kijken naar de knelpunten in de processen, en er heel gericht in investeren om die knelpunten op te lossen [1].

Het architectuurproces – het geheel van activiteiten die we in het Nederlands zo bloemrijk omschrijven met de term «werken onder architectuur» – staat bij veel organisaties volop in de belangstelling. Als je de belangstelling voor publicaties, congressen en opleidingen op het gebied van enterprise architectuur en IT Governance als maat neemt, dan wordt er ook volop in het architectuurproces geïnvesteerd.

De architectuurfunctie wordt meestal beschouwd als een “inrichtingsfunctie”. Het speelt een rol in de vertaling van de strategie (“richten”) naar de operatie (“verrichten”). Denk aan concrete activiteiten als productontwikkeling, procesverbetering, herstructurering en systeemontwikkeling. De architectuurfunctie wordt uitgevoerd als onderdeel van een concreet ontwikkelings- of verbetertraject en de archITect houdt zich uit hoofde van die functie op allerlei niveaus en terreinen bezig met

  1. het analyseren van stakeholders en hun concerns
  2. het verkennen van oplossingsalternatieven
  3. het faciliteren van de keuze voor een oplossingsalternatief
  4. het creëren van draagvlak voor het gekozen oplossingsalternatief
  5. de ontwikkeling van het gekozen oplossingsalternatief begeleiden
  6. het gebruik van het gekozen oplossingsalternatief evalueren
  7. het in kaart brengen van verbeterpotentieel

Misschien valt het u op dat dit taken zijn die ook al uitgevoerd werden toen er nog niemand was die de titel “archITect” droeg. Daar is op zich weinig tegen in te brengen. Het spreekt vanzelf dat in de gevallen waarin geen van de direct bij een vernieuwing of verbetering betrokkenen de functie “architect” bekleedt, vaak een of meerdere personen vanuit een andere rol deze taken uitvoeren. Het gaat bij werken onder architectuur dan ook niet persé om nieuwe taken, maar om het expliciet benoemen van deze specifieke combinatie van verantwoordelijkheden.

Het lastige van het inrichten van een architectuurfunctie is dat deze functie raakt aan het ontwikkelen van de strategie en tegelijkertijd raakt aan het ontwikkelen van concrete oplossingen – zoals producten, systemen en platformen. Maar al te vaak is er in de praktijk sprake van een inpendantie mismatch tussen de processen op deze terreinen. Ze “geleiden” veranderingen met een andere snelheid. Het overbruggen van die mismatch is misschien wel de grootste uitdaging bij het vormgeven van de architectuurfunctie.

Om over te Peinzen

Veel organisaties worstelen ermee dat investeringen in enterprise architectuur lastig in concrete business initiatieven onder te brengen zijn. Het probleem laat zich van verschillende kanten te benaderen. De investeringen in enterprise architectuur renderen als het goed is bij meerdere business initiatieven. Veranderingen en vernieuwingen worden makkelijker, beter of sneller te realiseren. Maar als meerdere stakeholders ervan profiteren, waarom wordt de investering dan afgewenteld op de eerste gebruiker? Waarom moet de eerste die beweegt het risico dragen? Is het wel te verkopen dat dit initiatief door de verbreding van de scope meer (management)tijd gaat kosten?

Als het dan zo onaantrekkelijk is om als eerste een architectuurvernieuwing te adopteren, dan zou het gevolg daarvan kunnen zijn dat dit soort fundamentele verbeteringen maar moeizaam tot stand komen. Dan zou de perceptie kunnen ontstaan dat investeringen in enterprise architectuur vooral afleiden van de hoofdzaak. Als het nemen van zulke risico’s ook nog eens onvoldoende wordt beloond, of als er geen duidelijke verantwoordelijkheid wordt belegd, dan bestaat de kans dat managers zich gaan richten op andere prioriteiten. Maar worden er op die manier dan geen gezonde business kansen gemist? Kunnen zulke investeringen gedurende langere tijd ongestraft achterwege blijven? Zou dat op langere termijn de gezondheid van de organisatie niet kunnen ondermijnen?

Het inrichten van een aparte functie voor “enterprise architectuur” beoogt een uitweg uit dit dilemma te bieden. Het is een mechanisme om een verantwoordelijkheid te creëren voor de functies en voorzieningen die het belang van één bedrijfsdomein overstijgen. Dat betekent dat de opdrachtgevers van business innovaties de functies die hun eigen verantwoordelijkheidsgebied overstijgen voortaan over kunnen laten aan een afdeling die daarvoor speciaal geëquipeerd is. Natuurlijk roept zo’n centrale functie tal van nieuwe besturing­vragen op, maar het is tenminste een nobele poging om een begin te maken met het oplossen van de geschetste problematiek.

Het valt te bezien of het inrichten van enterprise architectuur een modegril van voorbijgaande aard is, of dat er anno 2008 dieperliggende redenen zijn waarom het organiseren van een architectuurfunctie op enterprise niveau noodzakelijk is geworden. Persoonlijk ben ik van mening dat de noodzaak voor het organiseren van een architectuurfunctie alles te maken heeft met het definitief afscheid nemen van het silo denken. Of het nou Service Oriented Architecture heet, of Business Process Reengineering, of misschien Complex Event Processing, het zijn allemaal varianten op het thema “slimmer structureren van de informatiefunctie”. Met meer synergie, meer consistentie en meer slagkracht als resultaat.

Het onderscheiden van de bedrijfslaag, de applicatielaag en de technologielaag als aparte aandachtsgebieden in de architectuur is een beproefde manier om zo’n slimmere structuur vorm te geven. Maar deze drie lagen hebben van nature elk een eigen dynamiek c.q. een aparte impedantie; denk bijvoorbeeld maar aan de verschillende discussies die rondom het thema ‘outsourcing’ op de verschillende lagen worden gevoerd – vaak met elk hun eigen uitkomst. Het voorkomen van een mismatch tussen deze lagen rechtvaardigt niet alleen, maar vereist zelfs een andere aanpak, een andere manier van samenwerken. "Werken onder architectuur" is hiervoor juist geknipt. Dat blijkt keer op keer uit de ervaringen van structurele verander- en verbeterinitiatieven.

Is het feit dat veel organisaties vandaag de dag worstelen met een nijpend legacy-probleem trouwens geen voldoende indicatie dat zij hun architectuurfunctie in het verleden misschien onvoldoende hebben belicht?

Effectief en efficiënt innoveren is tegenwoordig voor veel bedrijven van cruciaal belang. Investeringen in de architectuurfunctie zijn dus indachtig het gedachtegoed van Eliyahu Goldratt vooral van belang als de architectuur een bottleneck vormt in het innovatieproces – het proces van ontwikkeling van nieuwe functies en verbetering van bestaande functies. Als de bestaande architectuur vernieuwingen en verbeteringen in uw organisatie beperkt in plaats van stimuleert. Dat plaatst investeringen in architectuur meteen in de relevante business context. Innovatievermogen. Hoe beter het is gesteld met uw architectuur, hoe groter uw innovatievermogen is. En hoe slechter uw architectuur in elkaar zit, hoe slechter u in staat bent om te vernieuwen en te verbeteren.

Dus mocht u ooit de vraag krijgen wat u als archITect nou eigenlijk doet, dan weet u nu het antwoord. Als architect werkt u aan het verbeteren van het innovatievermogen van uw organisatie. Een «mission statement» om trots op te zijn, vindt u niet?

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

[1] Eliyahu M. Goldratt, Jeff Cox: “The Goal: A Process of Ongoing Improvement”; North River Press, 1984.

maandag 14 juli 2008

De Midoffice Mythe

Toen de meeste mensen nog gewoon in een fabriek werkten, waren er twee soorten medewerkers – fabrieksarbeiders en kantoorpersoneel. Je droeg al naar gelang je positie of een ranzige overall, of een schoon overhemd – bij voorkeur met een hagelwit boordje. Dat was duidelijk.

Toen de dienstensector opkwam, kwam er behoefte aan een nieuwe tweedeling. De mensen die in de vuurlinie stonden – de medewerkers met klantcontacten, bijvoorbeeld achter het loket van een bankfiliaal – werden ingedeeld bij de frontoffice, en de mensen die op de achtergrond hun werk deden – medewerkers van de administratieve organisatie en de stafdiensten – hoorden even vanzelfsprekend bij de backoffice. In de wandelgangen werd het vaak zo samengevat: de frontoffice verdient het geld, en de backoffice maakt het op.

Wat zou de midoffice hieraan nog kunnen toevoegen?


Common Sense

Oorspronkelijk werd IT vooral gebruikt om taken uit de backoffice te “automatiseren” – niet voor niets is de term “administratieve automatisering” in zwang geraakt. Sinds de e-commerce en e-business ontwikkelingen speelt IT steeds nadrukkelijker ook bij de frontoffice taken een rol. Klanten kunnen op de website on-line bestellingen doen, problemen melden en met een beetje geluk ook zelf oplossen. Dankzij straight-through processing in de geautomatiseerde back-office is menselijke tussenkomst soms niet eens meer nodig. Goed, je kunt nog betogen dat de “content managers” van vandaag op een indirecte manier het klantcontact verzorgen, dus eigenlijk moderne frontofficers zijn, maar strikt genomen hebben zelfs zij nu een ondersteunende taak.

De laatste tijd lees je met enige regelmaat de term midoffice – vooral in relatie tot de elektronische overheid. Dan gaat het doorgaans om allerlei IT-systemen die de coördinatie en afstemming van de overige IT-systemen regelen. Systemen die niet klant-gericht zijn, en niet administratief van aard zijn, maar die integreren en orchestreren. In software-engineering termen zou je het al snel over middleware hebben, wellicht nog wat aangevuld met typische enterprise services. De “enterprise service bus”, de “business rules engine” en de “business process management engine”, dat soort systemen.

Maar hoe vertaalt zich dit in bedrijfskundige termen? Bestaat er een afdeling, liefst eentje die nog geautomatiseerd kan worden, die tot taak heeft om de frontoffice met de backoffice met elkaar samen te laten werken? Of is zo'n nieuwerwetse term op de keper beschouwd toch weer baarlijke IT-


Flauwekul?


Een klein onderzoekje is meteen ontluisterend. Er is op internet geen definitie van het begrip midoffice te vinden. Zelfs Bayens en Lankhorst wagen zich in “De Midoffice ontrafeld” (http://www.via-nova-architectura.org/artikelen/tijdschrift/de-midoffice-ontrafeld.html, 2008) niet aan een definitie. Dan maar wat dieper gegraven.

De aloude Webster Dictionary definieert in de online versie de term backoffice als “of or relating to the inner workings of a business or institution”. Frontoffice wordt gedefinieerd als “the policy-making officials of an organization”. Sic.U leest het goed. De enige echte front-office wordt volgens deze definitie gevormd door de beleidsmakers.

Gelukkig geeft de Business Dictionary een heel andere interpretatie. De frontoffice is “Marketing, sales, and service departments that come in direct contact with the customers, and liaise with the back-office (administrative) departments to maintain a two-way flow of information”. Techweb maar eens geraadpleegd. “front office refers to systems that deal directly with the customer such as order processing” en “back office refers to systems that do not deal directly with the customer”. Gelukkig maar. Webster is gewoon niet helemaal bij de tijd. Dus kunnen we veilig uitgaan van de conceptie dat de front-office klantgericht is, en de back-office intern-gericht.

Maar hoe zit het dan met de midoffice? Die komt zelfs in de TechEncyclopedia (met meer dan 20.000 IT termen) niet voor. Volgens het programmabureau elektronische gemeenten EGEM gaat het bij de midoffice om de systemen die de frontoffice systemen en de backoffice systemen aan elkaar knopen:

“Het mid office als architectuurconcept bevindt zich tussen het front- en back office. Het front office vormt de presentatielaag van een organisatie naar de buitenwereld; alle interactie daarmee speelt zich af in het front office. In het front office worden verschillende kanalen onderscheiden, zoals een callcenter, website en balie. Het back office daarentegen vormt het hart van de organisatie waar zich onzichtbaar voor de buitenwereld de primaire (gegevensverwerkende) processen afspelen. Het mid office fungeert daarbij als koppelvlak voor de verschillende front- en back office systemen.” (uit: Marktverkenning mid office systemen, 26 november 2004).

Bayens en Lankhorst gaan in hun enthousiasme nog een stap verder. Zij zien naast een ESB ook het BPM-systeem en een Operational Datastore (ODS) als onderdeel van een midoffice. En dat is dan nog maar de dunne variant. Want de “dikke midoffice” bevat ook nog een CRM-systeem, een Document Management Systeem en een Workflow Management Systeem. Een “totaal-bouwdoos” voor een “moderne SOA”. Slik.

Hier maken de auteurs naar mijn idee toch echt een denkfout. Omdat een workflowsysteem een workflowmodel kan executeren is het workflowsysteem zelf nog geen applicatie geworden – althans geen gebruikersapplicatie. Dat is op z'n best het workflowmodel zelf. En die zit normaal gesproken niet in een suite van een leverancier. Die moet tenslotte op de specifieke omstandigheden van de organisatie afgestemd worden. Zoals het in bepaalde architectuurkringen wel heet: “Today there are two things in life you cannot buy: love and an SOA”. Met ander woorden: de leverancier van een workflow-managementsysteem levert technologie – geen architectuur en geen gebruikersapplicatie. Dat een workflowmodel misschien niet in een derde-generatie computertaal is geschreven, maar op een alternatieve manier is gecodeerd, betekent op zichzelf nog niet dat zo'n workflow-engine niet gewoon een interpreter zou zijn. Niet veel anders als een webserver die PHP kan interpreteren.

Wat een midofficesysteem heet te zijn, zit feitelijk helemaal niet “tussen” de klantgerichte en de interne, administratieve systemen in – zoals de naam suggereert. Het is in mijn ogen technologie die beide soorten systemen faciliteert. Het zit er als het ware onder. De in Amerika gangbare term 'SOA platform' met 'enterprise services' is dan ook veel logischer. Inderdaad, het klopt dat zo'n 'SOA platform' functioneel steeds rijker wordt. Eerst werd het platform verrijkt met zaken als “middleware”, applicatieservers en met database management systemen en nu zijn we zo ver dat we een platform hebben met een rules engine, een document management systeem, een orchestratieservice. The rich get richer. Zo gaat dat nou eenmaal. Maar een platform blijft een platform.

Dat we het platform of de enterprise services in architectuurplaatjes graag in een tussenlaag platslaan, omdat dat nou eenmaal makkelijker tekent, soit. Dat het daarbij op de keper beschouwd niet zo zeer gaat om de enterprise services, maar de “scripts” die daarop worden uitgevoerd, dat wil ik ook nog wel voor lief nemen. Maar laten we toch alsjeblieft stoppen met voor die laag de verwarrende kreet 'midoffice' te gebruiken.

Er speelt nog iets anders. In enterprise SOA-plaatjes wordt de informatieruimte – met een knipoog naar het “3-tier model” uit de software architectuur – vaak opgedeeld in drie lagen:

  • een applicatielaag – de gebruikers-georiënteerde onderdelen (de “presentation tier”)

  • een services cloud – de gegevensverwerkende en beslissingsondersteunende onderdelen (waarin de “application tier” en de “data tier” tegenwoordig broederlijk opgaan)

  • een lijmlaag – de integratiecomponenten, inclusief de 'command and control' onderdelen

In dit verband worden ook wel de termen frontofficesystemen en backofficesystemen gehanteerd (veelal 'gemakshalve' afgekort tot 'frontoffice' en 'backoffice'). Systemen met een gebruikerinteractie zijn frontofficesystemen en services zonder gebruikerinteractie zijn backofficesystemen. Een volstrekt begrijpelijke terminologie – de “gebruiker” van een applicatie neemt in het denken de plaats in van de “klant” van een organisatie. En ik wil ook nog best wel toegeven dat de term midofficesysteem in díe context prima op z'n plaats kan zijn.

Toch blijft het risico op verwarring onverminderd groot. Een gebruiker die in de backoffice werkt, gebruikt per definitie een frontofficesysteem om toegang te krijgen tot de backofficesystemen. Daar moet je IT-er voor zijn om dat te kunnen begrijpen. En in enterprise architectuurmodellen betekent de term “backoffice” in de organisatieview dan iets totaal anders dan in de “softwareview”. Verwarrende terminologie, daar hebben we wat mij betreft al meer dan genoeg van.

Misschien is deze discussie wel een goede aanleiding om een terminologie te ontwikkelen die nog niet belast is. Wie durft een suggestie te doen? Ter inspiratie: ik houd het voor mezelf tot nader order op de Podiumzone (populair: de P-Zone), de Atriumzone (A-zone) en de Origozone (O-Zone). Maar ik sta natuurlijk absoluut open voor betere suggesties.

Deze flauwekul ontzenuwt een actueel architectuurdebat op een pittige en soms zelfs controversiële manier. Het is de 5de in een reeks flauwekul die op dit weblog gepubliceerd zal worden.

maandag 7 juli 2008

Lerende architecten

Architecten zijn vaak betrokken bij innovatie en vernieuwing. Er ontstaat ergens in de organisatie een idee, dit moet op allerlei manieren onderzocht worden, en alleen als het een vruchtbaar idee lijkt, tot een oplossing gebracht worden. En als het aan de architecten ligt, dan moet de oplossing natuurlijk onder architectuur gerealiseerd worden. Over wat dit precies behelst verschillen de lezingen echter.

De kwestie

Don Tapscott heeft in zijn visionaire boek “the Paradigm Shift” al in 1993 een werkmodel geschetst voor werken onder architectuur. Het bestaat uit vier stappen, te weten:

  1. Reimage – het ontwikkelen van een visie

  2. Restructure – het structureren van een oplossing

  3. Realize – het ontwikkelen en in gebruik nemen

  4. Renew – een continue verbetering

Het zal u misschien opvallen dat Tapscott zich hierbij heeft laten inspireren door de bekende Deming-cyclus (“plan-do-check-act”). Er zijn in elk geval ook vier fasen en het is beide gericht op een lerende organisatie.

In 2001 kwam Sogeti onder het kopje DYA – Dynamische Architectuur – met een eigen model. Dit bestaat uit drie stappen, te weten:

  1. De Strategische Dialoog – het bepalen van de business doelen

  2. Architectuur Services - het opstellen en bewaken van de architectuur

  3. Ontwikkelen (z)onder architectuur – het realiseren van de business doelstellingen

De parallel tussen deze twee modellen is op zich opvallend. De strategische dialoog is bedoeld om een gemeenschappelijke visie te ontwikkelen. Architectuur Services geven structuur en kader aan de oplossingen. En de daadwerkelijke realisatie wordt onder architectuur gebracht als de rol van de architecten niet beperkt is tot het beschrijven van de architectuur. Tegelijkertijd is het kenmerkende verschil in het achterliggende denkmodel opmerkelijk. Waar Tapscott veel waarde hecht aan het leren van fouten in en het continue verbeteren van eenmaal gerealiseerde oplossingen, ontbreekt dit in het DYA denkmodel volledig. Als de oplossing gerealiseerd is, dan hebben de Dynamische Architecten hun taak naar behoren vervuld.


Gemiste kans

Het verschil tussen de modellen is wellicht te verklaren uit het feit dat Sogeti, de organisatie achter het DYA-model, een leverancier is, die het moet hebben van het uitvoeren van projectgebonden activiteiten, en betrekkelijk lastig geld kan verdienen aan de structurele activiteiten die voor continue vernieuwing nodig zijn. Het structureel analyseren en verbeteren van het bestaande applicatieportfolio is immers eerder iets voor de gecommitteerde 'insiders' binnen een bedrijf, dan voor tijdelijke 'inhuurkrachten' van buiten. Maar daarom hoeft de architectuurcommunity zich nog niet bij deze omissie neer te leggen. Er werken tenslotte ook tal van gerenommeerde architecten als 'insider' bij bedrijven en instellingen. Is continue vernieuwing een relevante activiteit voor architecten? Zou het in het architectuurproces een plaats moeten krijgen? Zo ja, hoe geeft je dat dan vorm? Of zouden alle architecten zich uit hoofde van hun functie moeten concentreren op projecten met een afgebakend doel en een beperkte looptijd?

Als het leren van de gemaakte keuzes een doel is – en waarom zouden architecten niet van praktijkervaringen kunnen leren – dan ligt het in elk geval erg voor de hand dat er na het opleveren structureel een serieuze analyse wordt gedaan van de goede en mindere aspecten van de architectuur. In hoeverre was de project-start-architectuur doelmatig? Was hij correct, volledig en niet voor misverstanden vatbaar? De antwoorden op die vragen zijn ongetwijfeld leerzaam. Een end-of-project review lijkt dus een nuttig instrument om de architectuurfunctie te verbeteren. Maar is het voldoende?

Vanuit een business perspectief is de belangrijkste vraag waarschijnlijk of de gekozen architectuur adequaat is. Met andere woorden: is het op basis van de gekozen architectuur mogelijk gebleken om de business doelstellingen daadwerkelijk te realiseren. In de praktijk zal het niet vaak voorkomen dat deze vraag al aan het einde van een project beantwoord kan worden. Immers, na het invoeren van een nieuwe IT-oplossing verloopt er doorgaans de nodige tijd voordat de business doelstelling daadwerkelijk en volledig is gerealiseerd – al was het maar omdat de impact op de organisatie (waaronder de beheerorganisatie) nog moet blijken. Dat betekent ook dat er na verloop van tijd mogelijk nog belangrijke lessen te trekken zijn uit de praktijk van het levende systeem. Echter, alleen als architecten bereid en in staat zijn om een serieuze post-project review te doen, kan er van die – ongetwijfeld weerbarstige – praktijk daadwerkelijk geleerd worden.

Maar zelfs in het geval dat de business doelstelling volledig is gerealiseerd, dan wil dat nog niet zeggen dat het denken hoeft op te houden. De wereld is continu aan het veranderen. De markt ontwikkelt in een hoog tempo en de technologische mogelijkheden nemen met de dag toe. Het kan, met andere woorden, niet zo veel kwaad om periodiek en structureel te evalueren of de bestaande oplossingen nog wel adequaat zijn in de huidige situatie. Het overleven van de concurrentiestrijd vereist een mate van fitheid die zonder een gezonde portie beweging domweg niet houdbaar is.

Natuurlijk is het niet eenvoudig om dit te organiseren. Veel architecten worden geleefd door de 'hartbeat' van projecten. En zeker in het geval van inhuur is de betrokkenheid van de architect bij de organisatie vaak van beperkte duur. Maar zolang de architectencommunity niet om te beginnen de ambitie uitspreekt om een lerende discipline te willen zijn, dan gaat het zeker niet lukken om oplossingen te vinden voor dat soort organisatorische problemen. Misschien zouden we eens een business architect moeten vragen hoe je zo'n nijpend probleem nou het best zou kunnen oplossen?

In deze kwestie wordt een actueel thema op een scherpe manier geanalyseerd. Het is de 9de in een reeks die op dit weblog gepubliceerd zal worden.