Service Oriented Architecture / Opinie
Implementeer geen SOA
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...
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.
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?
SOA = "Start of Authority", "S*xueel Overdraagbare Aandoening", "Service Oriented Architecture", "Samen Overlegggen Afgeschaft" of toch "Server OpenSource Agreement"?
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.
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.
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.
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.
- 10:39 Oracle koopt SOA-beheeroplossing in
- 11:27 Macaw levert SOA aan De Goudse Verzekeringen
- 10:57 Google komt met eigen browser
- 10:03 'IBM kan software niet integreren'
- 09:21 Oracle kiest voor ontwikkeling BEA's Weblogic
- 15:54 Architectuur eerst, dan Service Orientatie
- 15:38 SAP zet volgende stap in SOA-strategie
- 20:00 Non-functionele eisen belangrijk bij testen SOA
- 09:54 Universiteitsteam Groningen wint...
- 08:52 SOA heeft gemeenschappelijke taal nodig
Service Competence Center versnelt implementatie SOA
De keus voor SOA is ingrijpend, maar hoe moet de organisatie ingericht worden om SOA goed te implementeren? Hoe wordt de nieuwe architectuur maximaal benut en aangestuurd? In deze whitepaper wordt beschreven hoe het instellen van een Service Compentence Center deze doelstellingen kan verwezenlijken.... Download nu
Vijf principes voor succesvolle SOA-implementatie
De keuze voor SOA is ingrijpend, maar welk fundament moet er zijn of komen om tot een succesvolle SOA-implementatie te komen? Op basis van 100 Case Studies zijn de vijf belangrijkste eisen gedefinieerd, die uitgebreid worden toegelicht in deze whitepaper.... Download nu
Meer SOA whitepapersComputable Events SOA
Computable organiseert in 2008 weer verschillende events met praktijkgerichte informatie over actuele onderwerpen in de ICT:
Webcast
SAP zet volgende stap in SOA-strategie
18-08 15:38 SAP heeft versie 7.1 van SAP Netweaver Process Integration (SAP Netweaver PI) vrijgegeven. SAP Netweaver PI is een softwarecomponent binnen het aanbod van soa-middleware en...
Meer soa productenCoca-Cola verkort tijd interne begripsvorming
10-07 13:40 Tijdens de grote SAP-conferentie Sapphire in mei 2008 in Berlijn heeft Alexander Grobe, innovatiespecialist bij Coca-Cola, een presentatie gehouden over zijn ervaringen met ARIS...
Meer soa casesCordys is geen Jan Baan-club meer
31-07 09:18 De Nederlandse BPM-leverancier Cordys timmert sinds 2001 aan de weg met zijn business process management-oplossingen. Inmiddels willen de eerste klanten over hun ervaringen met...
Meer soa achtergrondArchitectuur eerst, dan Service Orientatie
22-08 15:54 De manier om snelle wijziging in de werkwijze van de organisatie mogelijk te maken. Zo is service oriented architecture (soa) bij de introductie neergezet. Simpelweg door te...
Meer soa opinie

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