Soa komt niet zo snel van de grond als de softwarevendors hadden gehoopt en het kan nog wel een jaar of drie duren. Niet alleen vanwege scepsis of de angst om als too early adopter aan een hype mee te doen, maar vooral omdat het soa-concept te technisch is.
Een techneut kun je nog wel uitleggen wat soa is en wat het voor de ict-organisatie kan betekenen. Maar leg het maar eens uit aan iemand uit de business… Jazeker, de soa-adaptatie bottleneck ligt bij de business. Daar is immers niemand te vinden die zijn handtekening wil zetten onder een implementatiecontract van een miljoen euro dat geen keiharde garanties geeft over de opbrengsten en die zogenaamde agility. En helaas, die garanties zijn er nu eenmaal niet. Een effect dat deze bottleneck nog eens versterkt is dat sommige soa-initiatieven, die door de ict-afdeling van andere bedrijven werden gestart, jammerlijk zijn mislukt.
Of het nu aan veranderende prioriteiten, te weinig commitment vanuit de business of een teveel aan hooi op de vork te wijten is, doet er niet toe. Wat belangrijk is, is dat daarmee 'bewezen wordt' dat je maar beter niets met soa te maken kunt hebben. Het is veiliger om anderen de kastanjes uit het vuur te laten halen.
Soa is net een groep provo's. In het begin wil je er niet bij horen, want tegen de tijd dat de hele maatschappij erdoor veranderd zou kunnen zijn, werk je toch al ergens anders of ben je met pensioen. Zeg nu zelf: als je directeur van een business line was met een bonusplan met de looptijd van één jaar, zou jij dan aan soa beginnen?
Toch is er een aantal organisaties wél in geslaagd om een sucessvolle, omvangrijke soa-implementatie te realiseren. British Airways, Vodafone, Lufthansa Cargo en Volkswagen Financial Services leren ons dat om succevol te zijn op het volgende gelet moet worden:
* Een soa-implementatie volgt een evolutie en niet een revolutie (big bang-scenario's of volledig uitgekristalliseerde soll-scenario's zijn dodelijk).
* Zonder soa-governance is hergebruik beperkt en ontstaat vanaf dag één een gebrek aan overzicht.
* Zonder een soa center of excellence zal de organisatie onverstoorbaar verder gaan met
niet soa-dingen.
* Een onbedachtzaam aangeschafte enterprise service bus (esb) is als een bypass-operatie met random gekozen materialen. Soms gaat het goed…
Maar met dit lijstje in de hand vindt je nog geen business unit die een 'budget voor soa' heeft. Dus hoe kom je dan aan funding voor een serieus project? Het antwoord is: ga op zoek naar brand! Geen uitslaande brand van systemen die gisteren al iets moesten doen dat volgende week pas gerealiseerd kan zijn (als je alles kort door de bocht doet). Nee, je kunt beter op zoek gaan naar een smeulend vuurtje, dat straks een uitslaande brand kan worden. En de business blijkt erg gevoelig voor goeie oplossingen die zo'n brand kunnen voorkomen, vooral als de mogelijke (financiële) omvang van het toekomstige vuur nog eens wordt benadrukt. Opeens is er een budget. Niet voor soa natuurlijk, maar voor het oplossen van het probleem. En jij als architect of ict-professional, jij gebruikt gewoon de modernste technologie om dit belangrijke probleem op te lossen…
Binnen Systemation is dit uiteraard ook een bekend probleem en gelukkig hebben we er ook een oplossing voor.
De benadering die Systemation bij onze klanten succesvol toepast is de zogenaamde ‘Fast SOA’-aanpak.
Deze aanpak begint bij iets wat zichtbaar is voor de business, de user interface. Door integratie van de user interfaces van de verschillende applicaties met behulp van Enterprise Mashup technologie volgens SOA principes aan te pakken geef je de business een direct en ook goed meetbaar resultaat. Op deze wijze creeer je ruimte om onder water de o zo noodzakelijke, maar veelal onzichtbare SOA infrastructuur wijzigingen te doen.
Het door Systemation gebruikte Enterprise Mashup platform is in staat om door middel van user interface prototyping, dicht bij de business, maar wel onder volledige controle van de centrale IT afdeling nieuwe toepassingen te realiseren. Hierbij wordt gebruik gemaakt van een bibliotheek van herbruikbare user interface componenten. Deze componenten hebben vergelijkbare voordelen als webservices, maar ze zijn, in tegenstelling tot webservices, wel direct zichtbaar en bruikbaar voor de business. Door deze snelle, kort cyclische benadering houd je de business tevreden en geef je de IT meer lucht.
De “Fast SOA” aanpak kent twee toepassingen: Het blussen van brandjes, in de vorm van het realiseren van business wensen die niet in de reguliere project kalender passen en het overbruggen van de verschillende technologie generaties, de creatie van een composite applicatie op basis van mainframe, client server en webapplicaties.
Edwin van Asch
Solution Architect
Systemation
Ik geef Ferry gelijk als hij aangeeft dat SOA te technisch is, beter gezegd: te technisch wordt benaderd. SOA is een architecturele benadering en kenmerkend voor hedendaagse architecturele benaderingen is dat ze starten vanuit een bedrijfsmatig perspectief. Archimate is een voorbeeld van een dergelijke architecturele benadering.
SOA is nu in de meeste gevallen identiek aan web services, terwijl een ESB een invulling met techniek is om web services te realiseren. Natuurlijk sluit dit de niet aan bij de bedrijfsvoering. Wat begrijpt een manager nu van een web service? Hij ziet mogelijk alleen de hoge kosten om een ESB aan te schaffen en in te richten, terwijl hij de voordelen niet duidelijk zijn. Waarom zou hij over moeten gaan?
Ik ben het eens met de evolutionaire benadering. Deze is al een tijdje op gang gekomen, maar heeft nog niet volledig vorm gekregen. Het is de ommezwaai van een productgerichte naar een dienst georienteerde samenleving. Diensten komen centraal te staan. De overheid kan hier een voortrekkersrol in nemen door ook zijn dienstverlening op de juiste wijze met technische voorzieningen te onstluiten. Dit wil ook nog wel eens spaak lopen als de overheid zijn mogelijk smeulend vuurtje bij nader inzien toch maar weer met klassieke middelen invult.
Een ander probleem is dat je een techneut wel kunt uitleggen wat een SOA is, maar hij/zij tijdens de ontwikkeling van programmatuur een SOA zal genereren. Welke dat is en in hoeverre die aansluit bij de bedrijfsvoering is daarmee niet duidelijk. Huidige ontwikkelhulpmiddelen zijn niet gericht om als eerste diensten te ontwikkelen, waarna software deze moet ondersteunen. Het is juist andersom. Kortom, een dienstgerichte benadering moet zowel bij de business als ook in de techniek nog doorgevoerd worden.
Een brandend platform? Dat is zeker een mogelijkheid om een SOA traject te beginnen.
Maar er zijn nog andere mogelijkheden voor een succesvolle SOA introductie. Enerzijds zijn er tactische als wel strategische mogelijkheden. Anderzijds kun je kijken naar mogelijkheden die door IT of juist door business worden gedreven. De kruising van deze twee assen geeft verschillende mogelijkheden: point-to-point applicatie integratie is een typische tactische IT gedreven oplossing. Compliancy en auditing is meer een business tactische gedreven oplossing waar SOA bij helpt. Een strategische business-gedreven mogelijkheid is dan een composite oplossing die verschillende backend functionaliteiten aan elkaar breit tot een nieuw businessproces.
SOA moet in zo?n traject gepositioneerd worden als hulpmiddel en niet als oplossing om tot succes te komen. Begin op kleine schaal en dan langzaam uitbreidend naar andere delen van de applicatie en naar andere systemen. En dat is misschien net de vonk die nodig is?
Bedrijven met een complexe IT architecturen en verschillende systemen hebben geen keus: ze zullen op den duur hoe dan ook een SOA moeten implementeren. Een CIO of IT manager die blijft doorgaan op de huidig strategie, b.v. door het onderhouden van verschillende overlappende systemen zal tot conclusie komen dat hij / zij nooit een budget zal hebben om zijn / haar business architectuur te laten evolueren door b.v. nieuwe functionaliteiten kunnen adopteren. Bedrijven die geen SOA implementeren zullen niet meer competitief blijven en zullen minder relevant worden in hun marktsegment.
Misschien zou het eens interessant zijn om het zakelijk draagvlak te peilen als het aantal buzzwoorden wordt ingeperkt.
SOA = “Start of Authority”, “S*xueel Overdraagbare Aandoening”, “Service Oriented Architecture”, “Samen Overlegggen Afgeschaft” of toch “Server OpenSource Agreement”?
Zoals de schrijver al aangeeft moet je SOA niet willen inzetten om een uitslaande brand te blussen. Ook is de inzet niet gewenst als je inderdaad binnen een jaar wilt scoren.
SOA is een wijze van architectuur waarmee je nieuwe software gaat ontwikkelen of reenginering toepast op legacy software. Dit impliceert automatisch dat scoren op korte termijn er niet in zal zitten. Pas als een aanzienlijk deel van de in gebruik zijnde software op basis van SOA ontworpen is, kan er geld terug verdiend gaan worden omdat de herbruikbaarheid, onderhoudbaarheid en toepasbaarheid van onderdelen sterk verbeterd wordt.
Voor scoren op de korte termijn (het blussen van een uitslaande brand) kan je beter kiezen voor wat op dat moment beschikbaar is zonder je daarbij de vraag te stellen of die oplossing past in je lange termijn strategie.
Ik ben het eens met de schrijver. De business interesseert het niet welke technologie er gebruikt wordt hun problemen op te lossen. Het licht dus meer voor de hand een bestaand probleem op te pakken en
vandaar te evolueren naar een SOA architectuur.
Deze problemen zijn zeker te vinden binnen de business en zijn vaak gerelateerd aan functionaliteit die nodig is maar niet geboden kan worden. Dit kan zijn omdat hiervoor het ERP systeem te zwaar aangepast moet worden maar ook gewoon omdat de oplossing te veel verschillende ‘Systems of Record’ nodig heeft. Vaak zal je zien dat dit soort oplossingen juist concurrerende en innovatieve processen in de business ondersteunen
Vanuit deze strategie kan een klant evolueren naar een SOA raamwerk zoals Ferry in zijn artikel schreef.
Met interesse heb ik het artikel gelezen. De gesignaleerde uitdaging om Lines of Business beter aan te haken is een terechte constatering. De signalen en de aanpak geven echter blijk van verouderde opvattingen. Het versterkt alleen maar het wij-zij gevoel tussen business en IT. Het verstoort daarmee de noodzakelijke open dialoog. De openheid is nodig om het onderlinge vertrouwen te vergroten.
Het artikel ?Architectuur eerst, dan Service Ori?ntatie? geeft een aantal oorzaken waarom business zich daarom met IT bemoeit. Hetzelfde artikel biedt ook een oplossingsrichting voor de impasse. Uiteindelijk zit de crux in de intentie en toewijding van betrokken mensen om samen op een effectieve manier (bijvoorbeeld met service ori?ntatie) de bedrijfsdoelstellingen te halen. Daar past geen brand of smeulend vuurtje bij, want dat geeft alleen maar ramptoerisme en schade. Daar is uiteindelijk niemand bij gebaat. De oude volkswijsheid blijft namelijk gelden : Voorkomen is beter dan genezen.
Het is een cynische manier om er tegenaan te kijken, maar ik denk dat Bijl wel gelijk heeft, als het niet voldoende brand heeft niemand er geld voor over om te blussen. Komt nog bij dat techneuten in de dagelijkse operatie er ook nog eens goed in zijn om brandjes te blussen, dus om de noodzaak voor echte structurele wijzigingen lekker uit te stellen. Iets laten branden en hopen dat er echt iets verandert, is dan een mogelijkheid.
Of je hiermee ook ooit een echte service orientatie bereikt? Zooloog Dan-Erik Nilsson heeft gedemonstreerd dat het mogelijk is om het menselijk oog in kleine stapjes, via evolutie, tot stand te laten komen (http://www.pbs.org/wgbh/evolution/library/01/1/l_011_01.html). Dus wie weet.
@Edwin van Dis, 05-09-2008 11:29
Architectuur eerst en dan Service Orientatie is een stoptrein die niet voorbij het eerste station komt. Werken onder architectuur kost immers geld, maar levert het op korte termijn ook iets extra’s op?
Er zijn legio voorbeelden waaruit blijkt dat mensen uit twee kampen onder druk van naderend gevaar opeens toegewijd samen kunnen werken want inderdaad: voorkomen is beter dan genezen.