IT-budgetten doorlopen gedurende een fiscaal jaar over het algemeen een redelijk streng en vooraf bepaald proces. Managers zijn zich maar al te bewust van de sterke concurrentie tussen de verschillende IT-belangen. Servicegeoriënteerde architectuur (SOA) is, met haar beloften over hergebruik en uitwisselbaarheid door het bedrijf heen, vaak een goede kandidaat voor het aantrekken van middelen. Dat geldt des te meer nu er succesvolle voorbeelden zijn en executives zich van de voordelen van SOA bewust worden. We zijn de hype voorbij.

Over het algemeen is dit positief, maar architectuur is in alle aspecten van software van belang en zelfs de beste SOA zal zonder goede onderliggende architecturen in de implementatie van de specifieke diensten hoogstwaarschijnlijk falen. Vreemd genoeg is ook het omgekeerde waar. Het gevaar bestaat dat de moeite en middelen die in één architecturele discipline worden geïnvesteerd, voor niks zullen zijn als de andere tekortschieten.

Ik woon in Chicago, een stad die bekend staat om zijn architectuur. De stad kent fantastische architectuur in zijn gebouwen en zijn infrastructuur. Beide zijn nodig voor een succesvolle stad waar mensen wonen en zakendoen. De stad is een succes omdat de stedenplanners geweldige intra-gebouwendiensten ontworpen en gebouwd hebben (zoals water, electriciteit, telecommunicatie en transport), én omdat de gebouwenplanners (architecten) geweldige gebouwen hebben neergezet. Exclusief investeren in één van de twee zou leiden tot een mislukking. Zelfs het meest fantastische gebouw is waardeloos in een stad zonder de onderliggende diensten die in de algehele omgeving succes mogelijk maken.

Hetzelfde geldt in het ecosysteem van een bedrijf. Uitsluitend investeren in SOA op bedrijfsniveau (de stad) is alleen zinvol als de architectuur van de individuele componenten en diensten (gebouwen) ook passend ontworpen en gebouwd zijn. Omgekeerd kan exclusief investeren in applicatie-architectuur uitdraaien op gemiste kansen in de context van SOA, wat vaak leidt tot verdubbeling van de inspanning.

Dit viel me op toen ik ooit met een groot bedrijf samenwerkte. Ze hadden echt zeer indrukwekkend werk verricht op het gebied van applicatie-architectuur. Er werd veel inspanning geleverd aan domeingedreven ontwerp en Agile-ontwikkeling. Binnen de applicatiesilo’s zelf waren elegante en effectieve domeinmodellen ontworpen om snel en expressief programmeren mogelijk te maken om bedrijfsdoelen te bereiken. Jammer genoeg werd de investering te weinig gebruikt wanneer er interactie nodig was buiten de applicatie om. Door een combinatie van het technologische erfgoed en de onverbiddelijke benadering van deadlines was er sprake van te veel duplicatie. De zorgvuldig vervaardigde domeinmodellen liepen het risico te worden ondermijnd, aangezien ze niet de enige lijn waren waar data vandaan kwam en in voortbestond. De situatie maakte het aannemelijk dat het kleed onder de voeten van de applicaties vandaan zou worden getrokken.

Toch liep deze organisatie voorop. Zoals ik al zei hadden ze erg goede applicatie-architectuurtoepassingen geïnstalleerd. Het enige overgebleven werk was het uitbreiden van deze toepassingen naar het SOA-niveau van het bedrijf.

Ik ben applicatie-architect geweest en ik kan met zekerheid zeggen dat er een “wij tegen zij cultuur” kan heersen tussen SOA- en applicatie-architectuurgroepen. Dit kan gedeeltelijk te maken hebben met de ogenschijnlijke verwantschap met zowel technologie- als bedrijfsgroepen. Het is een noodzaak dat SOA dicht bij het bedrijf staat – in grotere mate dan in een traditionele applicatie-architectuur, waar analisten en architecten voorzichtig informatie proberen los te peuteren bij domeinexperts. SOA-architecten moeten veel dichter bij en ten dienste van het bedrijf staan op een hoger en minder aantrekkelijk niveau.

Het “bedrijf” (in tegenstelling tot een afdeling of bedrijfslijn) is soms lastig te conceptualiseren. Dit wordt nog verder bemoeilijkt door het feit dat veel ontwikkelaars de neiging hebben deze vage niet-functionele vereisten, die vaak van cruciaal belang zijn voor een succesvol SOA, als iets onbelangrijks weg te wuiven.

Reageer