Two and a half speed IT

We kennen ondertussen allemaal de publicaties van Gartner, McKinsey en de overige invloedrijke analisten en adviesbureaus over two-speed en bi-modal it. Zo’n architectuur waarbij je de robuuste, niet snel veranderende processen in je back-end systemen op orde hebt en daar bovenop een wendbare laag creëert om aan de snel veranderende klantvraag te kunnen blijven voldoen.

Deze wendbare laag wordt vaak met een platform ingevuld, en meer en meer is dit een cloudplatform. Deze oplossingen zijn meestal grafisch georiënteerd, waarmee modelleren het nieuwe programmeren wordt. Het doel is dan dat door middel van dit platform sneller nieuwe of veranderende klantprocessen kunnen worden geïmplementeerd. Vaak heeft men hierbij als tweede doelstelling dat deze processen bij voorkeur door de business ‘power users’ in elkaar kunnen worden geklikt. Zodat men niet op die langzame it-afdeling hoeft te wachten.

De rol van middleware

In dit soort omgevingen is het cruciaal om de data-architectuur en integratiemogelijkheden op orde te hebben. Daar zit vaak het grote probleem. De data-architectuur, bij elk bedrijf waar ik tot nu toe rond heb gelopen, is vaak op z’n zachtst gezegd een rommeltje. Door er master data management (MDM) en operational data stores (ODS) en data quality services (DQS) tegen aan te plakken worden de onderliggende echte problemen vaak gemaskeerd.

Een goede oplossing voor data (integriteit) in combinatie met een service oriented architecture is de heilige graal. Wellicht dat blockchain hier wel iets kan gaan betekenen in de niet al te verre toekomst. Maar dat is een ander, ook interessant onderwerp; voor later. Vooralsnog doen we het hier vaak met een enterprise service bus. Maar steeds vaker horen we hier over dat dat een bottleneck vormt, een centraal beheerde molog is en specialisten niet te vinden zijn.

API’s to the rescue?

Sinds een paar jaar bevinden we ons echter in het api tijdperk. Alles heeft een api. Dat is super, met name als het gaat om de vele SaaS-applicaties die we gebruiken. Die kunnen we dan lekker makkelijk klik-klak-klaar integreren in onze overige processen.

De volwassenheid van dit soort api’s wil echter nog wel eens te wensen over laten. Puberteit is een beter woord. Eigen, on premises-applicaties worden ook steeds vaker voorzien van api’s. En als we nieuwe, op microservices architectuur gebaseerde oplossingen ontwikkelen, communiceren deze services met elkaar via api-calls.

Maar waar zit dan de proces logica? De service compositie logica die je normaal gesproken in de ESB onderbrengt? En gaan deze api’s daadwerkelijk rechtstreeks met elkaar communiceren? Synchroon? Waarmee we in feite weer silo applicaties creëren? Of toch maar liever asynchroon via pub/sub oplossingen? Lichtgewicht service bussen? Api Management?

De vertragende factor

Feit is dat we middleware nodig zullen blijven hebben. Liefst natuurlijk zo lichtgewicht mogelijk. Het is echt nooit de bedoeling geweest dat ESB’s silo’s werden. Het feit dat we met zo’n divers landschap aan applicaties en bijbehorende uitwisselingsformaten en –protocollen te maken hebben, heeft gezorgd voor veel te veel logica in onze service bussen. En men heeft vaak BPM met proces orkestratie verward.

Liefst routeren we natuurlijk gewoon alleen canonieke berichten via de bus. Maar dat blijkt vaak nog een stapje te ver, een utopie eigenlijk. En dus zitten we met een centraal stuk middleware dat onderhouden wordt door specialisten. Die schaars zijn. En die onze time to market van nieuwe of veranderende klantprocessen ernstig vertragen.

Api’s verstandig opzetten

Gaan api’s daar verandering in brengen? Ik denk deels. Dit zit hem met name in het feit dat meer en meer applicaties en nieuw te ontwikkelen oplossingen op basis van api’s kunnen communiceren. Dat is tenminste een (defacto) standaard. En als we die api’s verstandig opzetten (zoals ooit de bedoeling was met SOA, maar dat hebben we met z’n allen een beetje verpest; de acht principes van service ontwerp zijn een beetje vergeten), zijn ze goed te gebruiken om oplossingen snel mee te kunnen creëren. Zelfs door de business ‘power users’. 

Dat neemt niet weg dat aandacht voor goede data architectuur, microservices met ingebouwde business rules, betrouwbare, idempotente API’s, goede design- en runtime governance, etc. zeer belangrijk zijn. En daar zijn helaas toch nog steeds specialisten voor nodig.

Here we come!

Door nu in elk Agile-ontwikkelteam dat zich bezig houdt met het creëren van oplossingen een ontwikkelaar met integratie ervaring op te nemen is dit probleem grotendeels op te lossen. Hij of zij zal ook de linking pin zijn met het centrale integratie team (ICC), waar onder architectuur de juiste api’s zullen worden ontwikkeld en ontsloten. 

Omdat in de integratie middleware grotendeels met standaard patronen wordt gewerkt en er maar één smaak van ontsluiten van services is (namelijk: api’s), zijn ook hier de architectuur bouwblokken sneller op te leveren. In het Scaled Agile Framework (SAFe) noemen we dit de Architectural Runway. En die is nodig om oplossingen voor de business te kunnen blijven realiseren. Two and a half speed it, here we come!