Business process management (bpm) op een service oriented architecture (soa) lijkt de volgende fundamentele technologieontwikkeling te zijn in bedrijfssystemen. De transformatie van logge erp-systemen naar bpm op een soa vertoont gelijkenissen met de uitfasering van mainframes in het microcomputing-tijdperk. Nieuwe ontwikkelmethodologieën en teamwork in de hele keten – van behoefte tot uitvoering – zijn echter belangrijker dan technologische innovatie voor de succesvolle shift van erp naar bpm op een soa.
De termen soa en bpm domineerden in de afgelopen tien jaar de ict-sector, net zoals erp de jaren negentig. De soa/bpm-retoriek werd al vrij snel omarmd door het management. Een 'flexibel, aanpasbaar systeem dat tegen lage kosten en zonder veel inspanning bedrijfsinnovaties mogelijk maakt' klonk directies als muziek in de oren. Zeker na een tijdperk waarin monolithische erp-systemen hun bedrijfslogica eerder opdrongen dan innovatie stimuleerden. Toch zijn veel organisaties nog steeds om erp heen opgebouwd. Betekent dit dat soa en bpm hun hoge verwachtingen niet kunnen waarmaken? Of is het slechts een kwestie van tijd voordat deze voorgoed doorbreken? Beide vragen zijn met nee te beantwoorden. Er is behoefte aan een ontwikkelmethodologie die het volledige potentieel haalt uit deze technologieën.
De oertijd
Als we terugkijken in de tijd is de fase waarin bedrijfsinformatiesystemen zich bevinden te vergelijken met de laatste jaren van de mainframes. Dit waren 'dinosauriërs' die volledige serverruimtes in beslag namen en gebouwd en geprogrammeerd werden voor zeer specifieke toepassingen. De huidige Jurrasic Park is minder duidelijk zichtbaar, omdat het monolithische kernsysteem op een verdeelde infrastructuur draait.
Door microcomputers verschoof informatieverwerking van gecentraliseerd naar gedistribueerd; de complexiteit werd echter niet minder. Het gebrek aan integratie leidde tot steeds hogere computingkosten door ontwikkelingcontracten op afdelingsniveau. Sterker nog: door de verspintering van de informatievoorziening in het microcomputingtijdperk kregen bedrijven steeds meer te maken met inconsistente en incomplete data.
Nieuwe dinosaurussen
Als we de stadia van bedrijfsinformatiesystemen onder de loep nemen, blijkt dat de reactie op het chaotische microcomputingtijdperk verschillend verliep op logisch (applicatie)- en infrastructuurniveau (zie nevenstaand schema).
Op infrastructuurniveau werden microcomputers opgenomen in netwerken en samengevoegd tot homogeen lijkende infrastructuren. Grid-computing en virtualisatie zorgen voor nagenoeg volledige transparantie van de infrastructuurlaag. Tegenwoordig gaat de omschrijving van een computer als fysieke machine niet meer op. De vraag verschuift van 'hoe krijg ik data van A naar B' naar 'op welke node is deze taak het best uit te voeren'. Cloud computing biedt het antwoord op deze vraag.
Op applicatieniveau was de reactie op microcomputing niet 'gedistribueerd en georkestreerd', maar werd teruggegrepen op het 'centrale en geïntegreerde' aspect van mainframes. Wel kunnen standaard erp-systemen vaak de specifieke eisen van bedrijven niet volledig ondervangen, waardoor veel bedrijven nog steeds ook op maat gemaakte bedrijfssystemen inzetten. Dit ondersteunen erp-leveranciers door hun platformen aan te vullen met eai-functionaliteit (enterprise application integration) om dergelijke 'perifere' systemen aan hun kernsysteem te koppelen. Dit verhoogt de lock-in en heeft als gevolg dat deze systemen steeds lastiger te beheren zijn.
De belofte van bpm en soa
Soa en bpm beloven hetzelfde te bereiken op applicatieniveau als computernetwerken op het infrastructuurniveau: van 'centraal en geïntegreerd' naar 'gedistribueerd en georkestreerd'. Hierdoor zou de intransparante, logische kerncomponent niet meer nodig zijn en de ontwikkellogica van 'buy' naar 'build for reuse' kantelen. Grote erp-systemen bepalen door de geïntegreerde logica vaak hoe een bedrijf moet werken. Bij soa en bpm kan een bedrijf zelf bepalen hoe het wil werken. Dan is het wel zaak om de eigen bedrijfslogica expliciet te maken en op te nemen in soa en bpm. Hierdoor wordt wel de werkelijke complexiteit van de onderneming zichtbaar. Hierin ligt misschien ook een verklaring voor het feit dat het bedrijfsleven soa en bpm nog niet massaal heeft omarmd: het besef dat meer controle en flexibiliteit gepaard gaan met meer complexiteit . De zoektocht naar een technologie die op basis van automatisering deze complexiteit wegneemt is nutteloos, aangezien de complexiteit zich op logisch en niet op technologisch niveau bevindt.
Soa en bpm zorgen voor fantastische uitdagingen voor methoden op het vlak van systeemontwikkeling en -beheer. Ten eerste moet eenvoudiger zijn te identificeren wat bestaande services precies doen, wie ze gebruiken, waar ze draaien en wie verantwoordelijk is voor het halen van prestatie-eisen. Ten tweede is het zaak nieuwe services samen te stellen op basis van bestaande services of volgens afgesproken standaarden te ontwikkelen. Ook is het belangrijk dat de cyclus van behoefte tot geïmplementeerd systeem wordt verkort, anders gaat soa aan ontwikkelkosten ten onder.
The missing link
De eerste twee eisen zijn in te vullen met een enterprise architecture-aanpak die wordt ondersteund door een geïntegreerde architectuur- en ontwerp-repository. Een enterprise architecture vormt in essentie het fundament voor een veranderingsproces dat een evolutie van de organisatie en de ondersteunende informatiesystemen mogelijk maakt. De repository biedt in deze toegang tot de bedrijfssystemen en laat zien welke aspecten daarvoor zijn te gebruiken door verschillende belanghebbenden: managers, gebruikers, analisten, ontwerpers en architecten.
De derde eis – het versnellen van het proces van behoefte tot oplossing – vereist ook een verandering in de ontwerp- en implementatiestromen. De ruis die er vaak is tussen de 'owner' en de systeemontwerper moet worden weggenomen. Traditioneel worden eisen van de business verzameld en volgens ingevuld met behulp van ict. In bpm kan een substantieel gedeelte van de functionele specificatie door de business overgenomen worden. Het resultaat is dan gebaseerd op een gezamenlijke specificatie, die is verrijkt tot een logisch design en doorontwikkeld in een uitvoerbare taal. Deze ontwikkeling vereist kennisopbouw en -ontwikkeling binnen de organisatie
Concluderend kunnen we stellen dat het succes van bpm op een soa niet afhankelijk is van technologische innovatie. Het staat of valt met nieuwe ontwikkel methodologieën en en teamwork in de volledige keten van bedrijfsbehoefte tot uitvoering.
Alexander Bielowski, senior bpm-consultant IDS Scheer
Ook na het tijdperk van SOA BPM en cloud computing zullen er nog steeds mainframe applicaties bestaan. Dat is ook niet erg, zolang het proces daar maar geen last heeft en de beheersbaarheid en kosten daarvan voorspelbaar zijn. Door ontkoppeling van statische applicaties functies uit alle generatie van applicaties en koppeling door dynische processen is uitfaseren van applicaties niet meer noodzakelijk als het gaat om ‘out dated technology’, maar zijn alleen business drivers bepaald wat wel en niet meer past in het applciatie landschap van morgen.