Mensen zijn geneigd om dingen in hokjes te stoppen. Met bedrijfssoftware werkt dat net zo. De meeste bedrijven kiezen specifieke softwarepakketten of men ontwikkelt maatwerk. Dat klinkt overzichtelijk, maar een organisatie werkt in de praktijk niet in gescheiden hokjes. Moderne bedrijven zijn veel beter af met een softwareplatform waarop alle bedrijfsactiviteiten naadloos integreren en zich snel kunnen aanpassen aan de veranderende omgeving.
De meeste mensen associëren software-implementatie met het implementeren van een softwarepakket. Dat is vaak een langdurig proces, dat begint met het opstellen van de requirements. Hieruit volgt al snel een zeer lange lijst, omdat iedereen bang iets te vergeten dat later mogelijk nodig is. Vervolgens wordt een pakket uitgezocht dat het beste aan die eisen voldoet. En pas na de selectie volgt de daadwerkelijke implementatie. Dan moet blijken of het pakket ook echt aansluit op wat de organisatie nu en in de toekomst nodig heeft.
De praktijk leert dat dit zelden het geval is. Als gevolg moet het bedrijf concessies doen en zichzelf aanpassen naar het pakket, het pakket anders configureren of maatwerk ontwikkelen. Kortom: de concessies starten al bij de implementatie. En als alles dan eenmaal is ingevoerd, volgt de beheerfase. Dit kan behoorlijk in de papieren lopen, zeker als er veel aan het pakket gesleuteld is, of er veel koppelingen zijn met andere pakketten. Zo bouwen veel bedrijven een architectuur op met tal van onderling gekoppelde softwarepakketten die veel beheer vragen. Een kaartenhuis, dat niet flexibel kan meebewegen met verandering.
Deze hokjescultuur past volgens mij niet in de dynamische wereld van nu, waarin bedrijven steeds sneller en flexibeler moeten veranderen. Het is echter de gangbare werkwijze, omdat er geen alternatieven zijn die een andere manier van werken mogelijk maken.
Modelgedreven software
De kracht van bedrijfssoftware zit tegenwoordig vooral in personalisatie, flexibiliteit en efficiency. Dat is al vrij lastig te realiseren met softwarepakketten in het algemeen, en al helemaal als je er meerdere aan elkaar koppelt. Modelgedreven software biedt een alternatief voor deze ouderwetse monolithische it-architecturen. Echter tot voor kort was model gedreven software een oplossing om snel maatwerk te ontwikkelen. Het was een tool voor de business die daarmee lacunes in het softwarelandschap snel kon opvullen met kleine applicaties.
Er zijn tegenwoordig diverse aanbieders van zogeheten low-code ontwikkelplatformen. Deze zijn echter niet geschikt voor bedrijfskritische high-performance applicaties, omdat de gebruikte technologie behoorlijke beperkingen kent. Hierdoor zijn ze niet geschikt om gerenommeerde erp-oplossingen van bijvoorbeeld SAP of Microsoft te vervangen. Ook zijn ze niet ingericht op het hergebruik van modellen. Hierdoor moet ieder model individueel worden onderhouden, net als bij traditioneel maatwerk.
Een nieuwe trend op dit gebied is door Gartner geïdentificeerd: Architected model-driven development, een methode om kleine stukjes ‘model’ naadloos samen te voegen tot een geïntegreerde applicatie. Deze flexibele integratie van verschillende functionele modellen wordt ook wel ‘model weaving’ genoemd. Deze stukjes model zijn herbruikbaar en kunnen centraal onderhouden worden, net als pakketsoftware. Dit biedt bedrijven een fijnmazige modulaire en flexibele manier om bedrijfskritische applicaties te realiseren die ook nog eens voortdurend aangepast kunnen worden aan nieuwe ontwikkelingen of inzichten. Met dit type modelgedreven software kunt u als organisatie naar een situatie waarin u de bedrijfssoftware en processen continu kunt verbeteren. Dat is een scherp contrast met veel bestaande enterprise it-architecturen, waar elke aanpassing al snel uitmondt in een hoofdpijndossier.
Continue verbetering
De smartphone en appstore hebben de telefoon, de rekenmachine, het navigatiesysteem en de zaklamp uit hun hokjes gehaald en in een nieuw kader geplaatst. Het geeft ons de mogelijkheid om vanuit één platform de apps te selecteren die we nodig hebben. Of weer te verwijderen als ze niet meer nodig zijn. De telefoon past zich daarmee continu aan naar onze behoeften.
Hetzelfde staat te gebeuren voor bedrijfssoftware. De ontwikkeling van functionaliteit gaat sneller, goedkoper en met een hogere kwaliteit op basis van modelgedreven ontwikkeling. Model-weaving maakt bedrijfsapplicaties flexibel en nauw aansluitend op het onderscheidend vermogen van het bedrijf. Bovendien biedt het een manier om met een kleine applicatie of een enkel bedrijfsproces te beginnen en gaandeweg functionaliteit toe te voegen.
Met architected model-driven software kunt u als organisatie loskomen van de traditionele hokjescultuur in de zakelijke softwarebranche. Het biedt een pad om daadwerkelijk te investeren in het continu verbeteren van uw organisatie in plaats van uw lot te verbinden aan een inflexibel traditioneel applicatielandschap.
Er zijn een paar kanttekeningen te plaatsen bij dit verhaal.
1. Het model dat een bedrijf van de plank kan pakken, bijv. voor het verwerken van orders, moet dan of zo algemeen zijn dat het voor ieder bedrijf te gebruiken is of er moeten zoveel modellen voor order invoer op de plank liggen dat elk bedrijf het bij hem passende model kan selecteren.
2. Alle modellen moeten naadloos met elkaar kunnen communiceren wordt lastig. Als er meerdere modellen zijn voor één proces en deze moeten elkaar kunnen vervangen, dan moeten er heel veel koppelingen worden gemaakt. Zowel binnen één proces als met aanpalende processen/functionaliteiten.
3. Het vervangen van een model kan niet worden vergeleken met een vervangen van een app. Apps waarin geen gegevens worden opgeslagen kunnen hier sowieso niet worden vergeleken. Dan even proberen met een praktijkvoorbeeld een vergelijking tussen een app waar wel gegevens in worden opgeslagen en een model waarin dat ook gebeurd. Een praktijkvoorbeeld: ik gebruik een app voor het hardlopen en daar definieer ik een favoriete route. Vervolgens komt er een betere nieuwe app op de markt. Deze wil ik gebruiken. Ik installeer de nieuwe app en verwijder de oude en daarbij ben ik mijn favoriete hardloop route kwijt, omdat deze niet kon worden overgenomen. Jammer, maar niet onoverkomelijk.
Als ik dit doortrek naar een model voor order invoer en ik vervang een oud model door een nieuw model en ik zou de gegevens niet kunnen overnemen dan zijn ‘oude’ ordergegevens niet meer benaderbaar. Lijkt mij redelijk desastreus voor een bedrijf.
Een model ontwikkelen voor een functionaliteit waar ieder bedrijf mee uit de voeten kan, is nog wel een klusje. Mocht dat onverhoopt niet lukken en er zijn meerdere modellen voor een functionaliteit dan zouden al deze modellen elkaars bestaande data moeten kunnen benaderen/importeren, anders ben je gegevens kwijt. Ook dit is een nog wel een klusje.
AMD zou een ideale situatie zijn, maar ik denk dat er nog wel wat hindernissen moeten worden genomen voor dat een organisatie een model van de plank kan pakken en als het niet voldoet, kan vervangen door een ander model.
Zou een oplossing liggen in een goede architectuur op basis van de te automatiseren processen?
Helaas staat model-gedreven nu juist haaks op enterprise architectuur.
Als gevolg van een aanhoudend wetenschappelijk denken in data, logica, regels, processen, systemen en…. (formele, mathematische en visuele) modellen is het schitterende idee van Service Oriented Architecture nog steeds niet van de grond gekomen.
Terwijl mensen toch in de eerste plaats denken en handelen in natuurlijke taal.
Service Oriented Architecture is een goede tweede; de eerste plaats lijkt me voorbehouden aan Primary Proces (Oriented) Architecture… misschien houdt de wetenschap niet van Primaire Processen?