Bedrijven moeten SOA-leveranciersonder druk zetten
De huidige marktsituatie stelt bedrijven echter voor complicaties die een succesvolle SOA-implementatie kunnen bedreigen en stelt afnemers voor nieuwe vraagstukken (zie kaders).
Allereerst blijkt dat de SOA-pakketten van leveranciers vaak gebaseerd zijn op een verzameling van verschillende producten die door middel van acquisities bijeen zijn gebracht. Als gevolg hiervan kan de integratie tussen de verschillende componenten binnen een pakket uiterst moeizaam verlopen. Daarnaast varieert het volwassenheidsniveau van de verschillende componenten in deze oplossingen. Tot slot is de implementatie van de (SOA-)open standaarden tussen de verschillende leveranciers niet altijd uniform gedefinieerd, waardoor de beloofde interoperabiliteit in gevaar komt.
Organisaties staan in deze situatie voor een dilemma: wachten tot de technologie en leveranciersconsolidatie verder zijn uitgekristalliseerd of nu starten met de SOA-implementatie. In het eerste geval missen zij de kans om op korte/middellange termijn te profiteren van de voordelen van een service oriented architecture. In het laatste geval zijn er twee mogelijkheden: men besluit te selecteren uit de verschillende producten om optimaal aan te sluiten bij de bestaande lagen in de enterprise-architectuur en mee te groeien met de al gekozen leveranciers, of men besluit te starten met een volledig nieuwe SOA-stack (alle benodigde componenten opnieuw selecteren, geen gebruik van bestaande componenten) om minimale hinder te hebben van leverancierskeuzes die in het verleden zijn gemaakt.
Omdat leveranciers hun portfolio’s uitbreiden ontstaat overlap met al aanwezige functionaliteit in de enterprise-architectuur. Bedrijven zullen dus vaker moeten kiezen: of de benodigde SOA-functionaliteit wordt ingevuld met bestaande componenten (waarvan er meerdere binnen de organisatie aanwezig kunnen zijn) of de introductie van een extra functioneel identieke component is gerechtvaardigd.
Risico’s
In deze marktomstandigheden, die naar verwachting op korte termijn niet zullen veranderen, is er geen eenduidige oplossing voor de geschetste problematiek (zie kaders). Enkele richtlijnen om de risico’s bij leveranciersselectie en SOA-implementatie beheersbaar te houden zijn de volgende.
• Organisaties die een SOA willen implementeren moeten de leveranciers gedetailleerde referenties vragen, om vooraf de voorgestelde oplossing op waarde te kunnen schatten. Men moet de referenten naar positieve en negatieve ervaringen vragen.
• Organisaties kunnen de leverancier(s) vragen aan te tonen dat de oplossing werkt in de bedrijfspecifieke situatie, waarbij gedetailleerd aangegeven wordt met welke technologie geïntegreerd moet worden.
• Bedrijven moeten vroeg in het project toetsen of de beoogde oplossing werkt met een ‘proof of concept’-aanpak. Dit biedt goed inzicht in de haalbaarheid en stelt de leverancier in staat om problemen snel te identificeren, waardoor meer tijd overblijft om ze te verhelpen. Als het niet lukt om in 4-8 weken een werkend proof-of-concept te hebben voor een representatief proces dat gebruik maakt van minstens drie bestaande systemen, moeten bedrijven goed opletten of ze wel de juiste oplossing realiseren.
• Organisaties moeten streven naar minimalisatie van functioneel identieke componenten in de enterprise-architectuur.
Evolutie
Een SOA biedt ongekende mogelijkheden om de bedrijfsvoering te optimaliseren, mits de beschreven uitdagingen structureel worden aangepakt. De huidige consolidatie in de markt van SOA-leveranciers en de niet eenduidige implementatie van open standaarden, stellen organisaties voor nieuwe vragen en integratieproblemen en vormen een risico bij de implementatie van een service oriented architecture. De kortetermijnrisico’s en integratieproblemen bedreigen het succes van de implementatie. De langetermijn-risico’s bedreigen de waarde van de gemaakte investering en de mogelijke noodzaak voor aanvullende investeringen. Gezien de huidige marktbewegingen en de doorgaande evolutie van SOA-standaarden, wordt niet verwacht dat deze risico’s op korte termijn zullen afnemen.
Geert Batterink (geert.batterink@accenture.com) is consultant, Guru Manja (guru.manja@accenture.com) senior manager en Michael Widjaja (michaelwidjaja@accenture.com) partner bij Accenture, een wereldwijd bedrijf voor managementconsulting, technologyservices en outsourcing. Zij houden zich bezig met architectuur- en integratievraagstukken en implementaties, waaronder SOA.
Markttrends en complicaties
Een servicegeoriënteerde architectuur (SOA) is een nieuw paradigma en integreert afzonderlijke systemen, applicaties, processen en bedrijven op basis van open standaarden. Een SOA biedt de mogelijkheid om nieuwe bedrijfsprocessen of toepassingen te assembleren uit afzonderlijke bouwstenen van bestaande systemen en applicaties (services). De aanwezige technologie en applicaties kunnen veelal worden hergebruikt en investeringen uit het verleden kunnen optimaal worden ingezet.
Service Oriented Architecture
Complicatie 1: Achtergrond SOA-leveranciers verschillend
SFlbLeveranciers van verschillende achtergronden streven ernaar om met behulp van acquisities een volledig SOA-productportfolio te realiseren. Zowel traditionele ERP-leveranciers, applicatie- en databaseplatformleveranciers, middleware- en integratiesoftwareleveranciers, als nichespelers begeven zich op de SOA-markt. Na een overname is het marketingmateriaal meestal snel aangepast, echter de integratie van de nieuwe aanwinst met het bestaande productportfolio heeft meer voeten in aarde. De overgenomen producten zijn soms vanuit een andere visie ontwikkeld, geschreven in een andere ontwikkeltaal of maken gebruik van andere versies van de (SOA-)open standaarden. Dit vergroot de integratiecomplexiteit. Bovendien kunnen leveranciers die recentelijk een overname hebben gedaan, moeite hebben om consultants en implementatiespecialisten met de juiste combinatie van kennis en vaardigheden te leveren om tegenslagen bij de implementatie snel en adequaat op te lossen.
SClB
Complicatie 2: Volwassenheidsniveau SOA-componenten binnen pakket sterk verschillend
Door de verwachte groei in de SOA-markt proberen zowel de traditionele IT-leveranciers als de nichespelers in deze markt een totaaloplossing te bieden voor alle functies die binnen een servicegeoriënteerde architectuur nodig zijn. In alle gevallen leidt dit momenteel tot een situatie waarin het volwassenheidsniveau van de verschillende bouwstenen sterk verschilt. Sommige componenten zijn gebaseerd op bewezen technologie, terwijl andere nog in de kinderschoenen staan.Bedrijven die een SOA implementeren met een enkele leverancier lopen het risico onvolwassen componenten te adopteren. Dit kan leiden tot extra implementatiekosten. Daarnaast bestaat het risico dat deze oplossing überhaupt niet zal werken. Bovendien brengt dit een verhoogd afbreukrisico met zich mee indien de leverancier besluit om niet verder te investeren in deze relatief onvolwassen componenten.Een alternatief lijkt om uitsluitend behoorlijk volwassen componenten van verschillende SOA-leveranciers te gebruiken. Dit alternatief zal echter leiden tot complexe beheer- en onderhoudsvraagstukken.SClB
Complicatie 3: Interoperabiliteit bij open standaarden niet vanzelfsprekend
SFlbNagenoeg alle SOA-leveranciers hebben in hun producten de open standaarden geïmplementeerd. In de praktijk blijkt echter dat de daadwerkelijke implementatie van deze standaarden (versies, implementatiedetails) per leverancier kan verschillen en de veronderstelde eenvoudige integratie bemoeilijkt.
Dit probleem speelt bij veel implementaties omdat geen enkele SOA-leverancier momenteel alle functionele componenten met het juiste volwassenheidsniveau kan bieden. De meeste SOA-oplossingen bestaan daarom uit een combinatie van producten van verschillende leveranciers. Deze problematiek heeft betrekking op technische details, waardoor diepe – en dus schaarse en dure – technische kennis noodzakelijk is om implementatieproblemen op te lossen.
Nieuwe SOA-implementatievraagstukken
Vraagstuk 1: Traditionele leveranciersselectie volstaat niet in SOA-context
Veel bedrijven hanteren bij de selectie van een IT-leverancier strakke en traditionele richtlijnen, meestal resulterend in de selectie van één pakket waarmee een bedrijfsbrede oplossing wordt beoogd. Omdat er voor een SOA-oplossing veel verschillende functionele bouwstenen nodig zijn en de productportfolio’s van de leveranciers continu aan verandering onderhevig zijn, is het voor organisaties in de praktijk niet vooraf te bepalen welke (combinatie van) leverancier(s) de beste of meest pragmatische keuze is.
In andere gevallen heeft het bedrijf een lijst met voorkeursleveranciers samengesteld en streeft naar minimalisatie van het aantal betrokken leveranciers. Omdat een SOA veel verschillende bouwstenen nodig heeft en geen enkele leverancier die allemaal kan leveren, zijn in veel gevallen toch meerdere leveranciers nodig. Hiermee staan bedrijven weer aan het begin van het geschetste dilemma. SClB
Vraagstuk 2: Toename identieke componenten in enterprise-architectuur
Bedrijven krijgen meerdere identieke functionele componenten in hun enterprise-architectuur als gevolg van de portfolio-uitbreidingen van SOA-leveranciers. Een typisch voorbeeld hiervan zijn de componenten die portal- en Business Process Management-functionaliteit leveren en die in de meeste leveranciersportfolio’s aanwezig zijn.
Mogelijk heeft een bedrijf vijf jaar geleden een ERP-systeem geïmplementeerd en drie jaar geleden een enterprise-architectuur-integratietraject afgerond. Beide leveranciers hebben inmiddels hun portfolio uitgebreid met SOA-functionaliteit en de bijbehorende portal- en BPM-componenten. Van welke leverancier kan het bedrijf het beste de SOA-componenten gebruiken en hoe interoperabel zijn deze? Kan dit bedrijf ook de bestaande portalcomponent uit de enterprise-architectuur gebruiken? Hoe bewaakt dit bedrijf de uniformiteit van de enterprise-architectuur?