Van nature sta ik sceptisch tegenover schijnbaar logische principes, en zeker als het enterprise architectuur betreft. Een veel gehoord principe is bijvoorbeeld 'buy before build'. Dit gaat om een of andere reden vaak gepaard met een grote aversie tegen maatwerk en wordt dan eigenlijk vertaald als 'alles behalve maatwerk'. Iedereen kent de grappen wel over het 'parametriseren' of 'configureren' van softwarepakketten; alles om het m-woord te ontwijken. Maar in een soa-omgeving kun je niet volstaan met de inzet van commercial off-the-shelf (COTS) pakketten. Als je soa wilt, is maatwerk onvermijdelijk. Een principe als 'buy before build' klinkt op het eerste gezicht best aardig, maar ik zal hier proberen te onderbouwen dat het eigenlijk nergens op slaat, zeker niet in een soa-omgeving.
Configuration vs. customization
Als vuistregel zou je kunnen zeggen dat configuratie een kleine wijziging is welke je middels de gewone grafische interface kunt doen en het is maatwerk als er code bij komt kijken, met een bijbehorende consultant. Maar iedereen weet dat dit niet zo simpel is en in een soa-omgeving wordt het er allemaal niet duidelijker op. Heb je bijvoorbeeld je bedrijfsregels in een aparte rules engine gestopt? In hoeverre kan de business dan zelf regels wijzigen?
Heb je je bedrijfsprocessen in een bpm-tool of iets dergelijks ondergebracht? Dan doemt de vraag op hoe de processen tot stand zijn gekomen en zijn uitgewerkt. Heeft de business verstand van BPEL? Zijn deze door ontwikkelaars geprogrammeerd? Welk deel is geconfigureerd? Mogen we BPEL-processen nu gewoon maatwerk noemen? De scheidslijn tussen configuratie en maatwerk is onduidelijk en laten we dat gewoon accepteren.
Verschillende soorten pakketten
Het probleem met standaardpakketten in een soa-omgeving is het gebrek aan onderkenning van de verschillende soorten pakketten en de afbakening van de verantwoordelijkheden die specifieke pakketten binnen de gehele architectuur op zich moeten nemen.
Er zijn verschillende soorten pakketten op de markt, waarbij goed moet worden bedacht dat veel pakketten slechts 'halffabrikaten' zijn. Met klassieke crm- of erp-pakketten als Siebel of SAP kun je al je bedrijfsprocessen ondersteunen door gebruik te maken van modules die specifiek op jouw soort organisatie van toepassing zijn. Een dergelijk pakket is feitelijk ook bedoeld om als basis voor het bedrijf of de afdeling te dienen. Een ecm-pakket (bijvoorbeeld Documentum) kan vaak ook als basis dienen voor een organisatie, maar heeft al een iets infrastructureler karakter. Al deze pakketten zijn dusdanig ontworpen dat ze in de loop der tijd steeds meer functionaliteit bieden. Er is geen enkele leverancier die zijn softwareproduct niet voortdurend uitbreidt en dit betekent dat de pakketten qua functionaliteit naar elkaar toegroeien. Het veelgenoemde zaaksysteem in gemeenteland kan bijvoorbeeld ingevuld worden met een crm-pakket als basis, maar net zo goed met een ecm-pakket.
Het probleem met traditionele pakketten
Tussen de standaardpakketten en de best-of-breed benadering zoals die veelal in soa-omgevingen voorkomt, bestaat een groot spanningsveld. Probleem hierbij is dat pakketten vaak gebaseerd zijn op één grote database waarbij bedrijfsprocessen en bedrijfsdata niet goed gescheiden zijn. Integratie met andere componenten is op zowel technisch als functioneel niveau erg lastig. Ook de mooie grafische interfaces van pakketten zijn lastig te integreren met legacy-systemen. Bovendien heb je bij grotere leveranciers weinig invloed op de release cycle. Tel daarbij op dat pakketten doorgaans niet uitblinken in transparantie, open standaarden en publiekelijk toegankelijke documentatie en je komt tot de conclusie dat er best wel nadelen aan pakketten kleven.
Een ander issue met deze grote traditionele pakketten ligt op het gebied van het implementatieproces. Het is erg lastig om 'Agile' te blijven als er een miljoenen kostend pakket moet worden uitgerold. Ook binnen soa wordt algemeen aanvaard dat het verstandig is om klein te beginnen en later uit te breiden. Het principe van 'you ain't gonna need it' is moeilijk te hanteren bij de uitrol van pakketten. Het bereiken van 'Agility' tijdens het implementatieproces is één ding, maar de binnen SOA zo gewenste 'business Agility' is waar het echt om gaat. Ik vraag me toch af hoe dat gaat met de grote standaardpakketten. Een nieuwe versie uitrollen is zo eenvoudig nog niet.
Soa-suites
Middlewarepakketten zoals een applicatieserver, servicebus, MS Biztalk, etc. of portalservers, mdm-oplossingen, etc. zijn van een andere orde als de eerder genoemde pakketten. Zonder maatwerk heb je aan deze pakketten helemaal niets. Deze producten komen uit de soa- of integratiehoek, zijn vaak onderdeel van een soa-suite en kennen binnen de leveranciersbedrijven ook een gezonde spanning met de andere afdelingen. Zo zal een IBM-medewerker op de WebSphere-afdeling anders reageren op de vraag waar je het beste je bedrijfsprocessen kunt modelleren dan een IBM-medewerker uit de FileNet-hoek. Een middlewarepakket heeft geen fancy grafische interface waar beslissers uit de business voor zullen vallen.
Conclusie
Het principe van 'buy before build' klinkt best aardig, maar 'bezint eer ge begint' klinkt nog beter. Ik ben geen voorstander om een complexe ESB van scratch af aan te maken, maar om nu te zeggen dat er met het kopen van een product geen maatwerk meer nodig is, gaat veel te ver.
Voor kleinere organisaties is het zeker ook logisch om een pakket te gebruiken voor de bedrijfsvoering. Het probleem dient zich natuurlijk aan bij het groter worden van organisaties en de integratie van verschillende onderdelen. Dat wil zeggen, als de ontzuiling zijn intrede doet en soa begint. In een soa betekent het principe van 'buy before build' niet dat je maatwerk kunt vermijden. Soa is maatwerk.
Beste Friso,
Het probleem is hier gewoon dat ‘buy before build’ geen principe is maar een uitgangspunt of een intentie alleen helaas wordt gelabeld als principe. Binnen de IT en enterprise architectuur hanteert men vaak een foutieve definitie betreffende principes, waardoor alles wat lijkt op een richtinggevende uitspraak tot principe wordt gebombardeerd. Ook al spreekt men buy before build af, lukt het vaak niet, want het is een intentie en geen werkingmechanisme. Men organiseert niets om het echt af te dwingen of te reguleren.
Een principe is, (en dat blijkt uit mijn promotieonderzoek), de gehandhaafde wijze waarop iets werkt, in elkaar steekt of gebeurt, in een bepaalde context, met een bepaald resultaat tot gevolg.
In mijn in artikel http://research.paauwe.info/downloads/Paauwe-Research-Gemeente-Maastricht-Het-architectuurprincipe-Appl-1-in-beeld%20gebracht.pdf laat ik een voorbeeld zien van een uitgangspunt dat is gelabeled als principe, maar veel effectiever kan worden geformuleerd als echt principe door je te focussen op een gehandhaafde werking.
Een principe is dus niet buy before build, maar bijvoorbeeld wel ‘De stelselmatige inzet van standaard software-oplossingen leidt binnen organisaties, waar software ontwkkeling geen core competence is, tot goedkoper beheer en betere integratie dan de stelselmatige inzet van maatwerksoftwareoplossingen en zelfbouw softwareoplossingen’. Dit principe beschrijft veel meer een werking binnen een bepaalde context dan het ‘buy before build’.
In jouw betoog diep je het in feite nog verder uit, waarbij je een context van middleware versus bedrijfssoftware aangeeft. Ik denk dat je nog een kleine stap verwijderd bent van het formuleren van een goed principe.
Friso maakt een scheiding tussen maatwerk en geen maatwerk, waarbij hij ervoor waarschuwt dat grote standaard paketten zichzelf onder “geen maatwerk” scharen, terwijl dat in werkelijkheid anders is, en SOA suites per definitie onder maatwerk vallen. Friso beweert, en daarin geef ik hem gelijk, dat je niet kunt verwachten dat standaard paketten zonder configuratie, lees maatwerk, zullen werken.
Ik denk echter dat maatwerk in een SOA suite ook niet zonder slag of stoot geïmplementeerd is, en ik heb ook al heel wat ontwikkelafdelingen sip zien kijken na de uitrol van een nieuwe versie van WebSphere (de interne mensen dan, niet de externe consultants).
Een ontwikkeling die ik wel bij de grote pakketleveranciers zie, maar niet in het stukje van Friso, is dat zij zich steeds meer ontwikkelen tot platformleveranciers, dus opschuiven richting Biztalk, WebSphere en dergelijke – rijke toolsuites met libraries die je aan elkaar kunt knopen in je favoriete ontwikkeltaal (ABAP, Java, noem maar op). Daarmee verdwijnt het onderscheid tussen maatwerk en standaard, SOA en pakket.
Zoals het klokje thuis klinkt, vind ik het toch het beste klinken.