Op weg naar Pakketsoftware 2.0

SaaS software ontwikkeling

i

Op weg naar ‘Pakketsoftware 2.0’

Rol van standaard

Software als Service is een combinatie van service-oriented

softwarepakketten

architecture en Software as a Service en is erop gericht de

in Software als

regie weer terug te brengen bij de business als het gaat om

Service

het toepassen van software. De auteur gaat in op de rol van standaardsoftwarepakketten binnen het concept van Software als Service.

Leen Blom

informatie / juli|augustus 2008

1. In een open-sourcecontext zullen veel gebruikers zich ook vaak conformeren aan wat beschikbaar is en niet zomaar aanpassingen doen.

10

Er wordt veel geschreven over business process management en service-oriented architecture (SOA) en de voordelen hiervan voor de business, zoals flexibiliteit en lagere kosten. ICTRegie (2007) doet ook onderzoek naar Software als Service (SaS) als combinatie van service-oriented architecture en Software as a Service (SaaS). Dit is erop gericht de regie weer terug te brengen bij de business als het gaat om het toepassen van software. De vraag is dan welke plek standaardsoftwarepakketten innemen in deze veranderingen. Spelen ze nog een rol of doen we ze af met het begrip ‘bestaande wereld’ en investeren we alleen nog in nieuwe toepassingen? Standaardsoftwarepakketten zijn zeker nog geschikt voor de wereld van Web 2.0. Ze zijn, mits gebaseerd op een service-oriented architecture, belangrijke bouwstenen voor Software als Service en zullen uiteindelijk zelf uitgroeien tot ‘Pakketsoftware 2.0’. Dat de transitie geen eenvoudig proces is, wordt duidelijk aan de hand van een praktijkvoorbeeld.

Definities Standaardsoftwarepakket Er is sprake van een standaardsoftwarepakket (Donatz & Van Outvorst, 2003) als een applicatie

is ontwikkeld voor meerdere overeenkomstige gebruikers. Kenmerken: • De afnemer van het pakket heeft niet direct invloed op de functionaliteit. De functionaliteit is in de basis voor alle afnemers hetzelfde. • De broncode van het pakket is eigendom van de leverancier.1 In de praktijk wordt als belangrijkste tegenhanger het begrip ‘maatwerksoftware’ gebruikt. Service-oriented architecture (SOA) Een service-oriented architecture is een organisatiebrede omgeving gebaseerd op strikte interfaces (Natis, 2003) waarin bedrijfsprocessen, informatie en systemen zijn opgebouwd uit services: afgebakende, autonome activiteiten met een complete businessfunctie. Een service is taak ondersteunend, de integrale procesondersteuning wordt bereikt door services te orkestreren. Dit is anders dan een traditionele architectuur waarin vanuit een integrale procesgedachte activiteiten worden aangestuurd en waarin de systemen integraal procesondersteunend zijn. Koppelingen tussen systemen worden tot stand gebracht voor elke specifieke taak (Oord & Van Ginneken, 2005).

Samenvatting Leveranciers van standaardsoftwarepakketten zullen een grote rol spelen in SOA, Software as a Service (SaaS) en Software als Service (SaS). Zij hebben veel kennis van de processen en wanneer zij de juiste services bieden, krijgen bedrijven snel de juiste software en kunnen dankzij de flexibele structuur direct inspelen op veranderingen. SaS levert vooral rendement op bij voldoende schaalgrootte en dit is alleen mogelijk met standaardsoftwarepakketten.

2. Voor definities van ‘coarse-grained’ en ‘fine-grained’, zie http://en.wikipedia. org/wiki/ Granularity.

Bedrijven gebruiken vaak een mix van zelf ontwikkelde software en standaardsoftwarepakketten. Deze situatie is volgens een natuurlijk proces ontstaan door het samenvoegen van bedrijven, het opzetten van nieuwe diensten of simpelweg door de groei van de onderneming. Als de organisatie echter opnieuw nadenkt over de gewenste informatievoorziening en in kaart brengt wat men in huis heeft aan ondersteunende software, wordt duidelijk waarom ICT-afdelingen het moeilijk hebben. Al deze software heeft zo zijn eigen karakteristieken en vergt in het beheer andere processen. Een standaardsoftwarepakket moet bijvoorbeeld een op het bedrijf toegesneden implementatietraject doorlopen, met parametrisering en customization, en vaak worden nog delen als maatwerk toegevoegd. We zien een verschuiving naar een groter gebruik van standaardsoftwarepakketten. In de periode van 2002 tot en met 2005 is het aandeel van maatwerk in Nederland teruggelopen van 32 naar 23 procent (Den Besten, 2006). Standaard of maatwerk, het staat vast dat er een stroom van softwareaanpassingen op gang komt na de eerste implementatie. Een wettelijke maatregel of een nieuwe business opportunity vraagt om flexibiliteit om veranderingen op te vangen en de time-to-market kort te houden. Veel geld wordt gestoken in de instandhouding, waardoor er weinig overblijft om de verplichte aanpassingen te realiseren. Helaas is het aanpassen van software een dure en tijdrovende klus geworden. In relatie tot standaardsoftwarepakketten en de vereiste flexibiliteit zijn in onze ervaring twee aspecten belangrijk: de scope van de functionaliteit en de mate van standaardisatie ofwel de toepasbaarheid van de functionaliteit.

Scope De scope betreft de mate waarin de totale functionaliteit van de software de bedrijfsprocessen

afdekt. Totaal betekent hier inclusief de variatie in functionaliteit die met parametriseren en customizing te bereiken is. Er kan sprake zijn van een zeer specifieke component die slechts één bedrijfsfunctie bedient, de scope daarvan is dus smal. Grote ERP-pakketten dekken processen af uit een gehele bedrijfstak, deze software heeft een brede scope. De kans dat veranderingen in de bedrijfsvoering software met een brede scope raken, is uiteraard groter dan bij software met een smalle scope. Een brede scope vereist meer flexibiliteit om de software aan te passen. Scope is gerelateerd aan maar niet synoniem met granulariteit, wat een implementatieaspect is waarbij functionaliteiten worden samengevoegd in één component (Steghuis, 2006). Veel software is monolithisch: de scope van de functionaliteit is breed en de granulariteit laag (coarse-grained)2. De scope kan op de volgende manier worden onderverdeeld (oplopend): • taakgericht: afgebakende functionaliteit voor één taak; • procesgerichte functionaliteit: functionaliteit voor een specifiek bedrijfsproces of een afdeling; • bedrijfsbrede functionaliteit: dekt processen af binnen de onderneming of instelling; • domeinbrede functionaliteit: dekt processen af van gelijksoortige bedrijven, bijvoorbeeld bedrijven die in dezelfde branche actief zijn.

Toepasbaarheid De mate van standaardisatie of toepasbaarheid is van belang omdat bij standaardisatie de functionaliteit wordt gebruikt door meer dan één partij. De snelheid waarmee een aanpassing kan worden doorgevoerd, is lager, maar de kans dat dit nodig is, is kleiner omdat de functionaliteit rijker is. Standaardisatie beïnvloedt de flexibiliteit dus op het aspect snelheid van de aanpassing. Wat betreft toepasbaarheid kan de volgende onderverdeling worden gemaakt (oplopend): • specifiek: functionaliteit voor specifieke processen binnen één organisatie;


Continu veranderen vereist flexibiliteit

11

SaaS

i

functionaliteit; flexibiliteit legt het hier af tegen stabiele standaardfunctionaliteit; • linksboven: brede scope en specifieke functionaliteit; deze combinatie komt in de praktijk weinig voor.

Op weg naar ‘Pakketsoftware 2.0’ • herbruikbaar: functionaliteit voor specifieke processen binnen meerdere organisaties in een specifieke branche; • generiek: functionaliteit die bij veel bedrijven toepasbaar is onafhankelijk van de branche, bijvoorbeeld financiële pakketten en kantoorautomatisering.

Scope en toepasbaarheid in verband met elkaar Hoe breder de scope, hoe groter de kans dat de noodzakelijke functionaliteit aanwezig is. Deze redenering gaat in zoverre op dat de kans dat er te veel aan functionaliteit aanwezig is, ook groter is. Belangrijker is om te zien welke correlatie de twee aspecten hebben ten aanzien van flexibiliteit. Als we beide begrippen tegen elkaar uitzetten, zijn grofweg vier kwadranten te onderscheiden (zie figuur 1): • linksonder ‘maatwerk’: kleine scope en specifieke functionaliteit, flexibiliteit is zeer hoog; • rechtsonder ‘generiek’: kleine scope en generieke functionaliteit, flexibiliteit wat lager door de hoeveelheid implementaties; • rechtsboven ‘ERP’: brede scope en generieke

SOA wordt gepositioneerd als een manier om de gewenste flexibiliteit te bereiken waarbij tegelijkertijd de totale instandhoudingskosten dalen.3 Enige nuancering is wel op zijn plaats, want een goede businesscase blijft noodzakelijk (Oord & Van Ginneken, 2005). Het begrip SOA is gebaseerd op eerdere inzichten op het gebied van software-engineering, zoals modulair ontwerpen, component-based development en het gebruik van middleware. Feitelijk hebben we het over fasen in de kennis van software-engineeringprincipes. Top-down zijn de grenzen van de functionaliteit en de gegevens daaronder steeds nauwer getrokken en is men in de technische implementatie ook deze begrenzingen gaan hanteren (Matthews & Guttman, 2006). Bottom-up is een beweging zichtbaar van componenten met een hoge granulariteit (fine-grained) en hoge koppeling zoals routines en objecten, naar componenten die groter zijn en veel losser gekoppeld. Deze laatste vorm is kenmerkend voor services. Op welke wijze speelt SOA een rol in de wereld van standaardsoftwarepakketten? In eerste

inflexibel

scope functionaliteit

domein

ERP suites (Microsoft, Oracle)

bedrijf maatwerk


proces

12

bedrijfsprocesspecifieke pakketten

gespecialiseerde pakketten (CRM, finance) gespecialiseerde software zoals AutoCad

zeer specifiek maatwerk taak

zeer flexibel

flexibel herbruikbaar

specifiek

toepasbaarheid functionaliteit

Figuur 1. Functionaliteit en flexibiliteit

generiek

3. Door de meeste ICT-leveranciers, bijvoorbeeld LogicaCMG op www.logicacmg. com/nl/careers/ artikel_SAP_en_ SOA.asp

posite services, die worden opgebouwd uit andere services. Standaardsoftwarepakketten worden dan gevormd door een suite van services die op een standaardmanier zijn georkestreerd (de referentieprocessen). Deze orkestratie is tijdens de implementatie aan te passen aan de bedrijfssituatie. Een en ander dient te worden geïntegreerd door procesmanagers en/of een enterprise service bus. Hierover is al veel gepubliceerd (zie onder andere Erl, 2007); dit wordt in dit artikel niet verder uitgewerkt. Standaardsoftwarepakketten als suites van services passen uitstekend in een Web 2.0-wereld waar gebruikers naar believen functionaliteiten koppelen en via moderne technieken ontsluiten. Referentieprocessen geven hierbij een goede ‘quick start’, maar gebruikers zijn in staat deze aan te passen aan de eigen behoeften.

instantie denkt men aan het integreren van bestaande functies door deze als services beschikbaar te stellen (wrapping) (Natis, 2003). Deze methodiek verbetert de flexibiliteit echter niet en door het toevoegen van een technische schil nemen de kosten toe. Dit is alleen toepasbaar bij de eerste implementatieprojecten van workflowmanagementsystemen of business process management. Voor een goede ondersteuning van de SOA-architectuur moeten leveranciers van standaardsoftwarepakketten echter terug naar de tekentafel. Zij moeten niet alleen de functionaliteit, maar ook de architectuur standaardiseren. Functionaliteiten moeten beschikbaar zijn als services: echte componenten met zowel businesslogica als gegevens. De consequentie hiervan is dat gegevensmodellen ontvlochten moeten worden en proceslogica losgeweekt. De kennis van de leveranciers over deze processen is een voordeel voor de afnemers. Het is dus essentieel dat deze processen beschikbaar komen als referentieprocessen, bij voorkeur geformuleerd in moderne talen zoals BPMN en BPEL. Standaardsoftwarepakketten zullen moeten worden ontrafeld in een verzameling (suite) van services. Als we hetzelfde schema als in figuur 1 gebruiken, is te zien dat services, door hun smalle scope, in de kwadranten met flexibiliteit vallen (zie figuur 2). Om de flexibiliteit in de praktijk waar te maken dienen services zich daarom te beperken tot de scope van een deelproces, in onze visie ook de com-

Praktijkcase Centric IT Solutions is leverancier van standaardsoftwarepakketten voor diverse branches, waaronder de lokale overheid. Enkele jaren geleden is een omvangrijk programma gestart om deze pakketten klaar te maken voor de toekomst, waarin SOA de basis is en BPM een hoofdrol speelt.

Hoe worden de beloften van SOA werkelijk ingevuld? Het is duidelijk geworden dat de beloften van SOA vooral uitgaan van een situatie na transitie.

inflexibel ERP referentieprocessen Suites (Microsoft, Oracle)

bedrijf

referentieprocessen gespecialiseerde pakketten (CRM, finance) composite bedrijfsprocesspecifieke composite pakketten services services

maatwerk eigen processen proces

zeer specifiek eigen maatwerk services taak

referentieprocessen

specifiekespecifieke services services

gespecialiseerde standaardstandaardsoftwareutility zoals services services AutoCad services

zeer flexibel specifiek

flexibel herbruikbaar toepasbaarheid functionaliteit

Figuur 2. Functionaliteit in een SOA-context

generiek


scope functionaliteit

domein

13

SaaS

i


Het blijkt moeilijk om in de transitie ten aanzien van standaardsoftwarepakketten quick wins te definiëren voor zowel de klant als de leverancier. Forse investeringen zijn nodig om de basisarchitectuur neer te leggen, die in eerste instantie geen functionele toegevoegde waarde biedt. Daarnaast blijkt de methodische kant van het ontwikkelen van services in een experimenteel stadium, waardoor een leverancier veel pionierswerk moet verrichten. Er zijn twee voorbeelden te noemen die een goede start vormen van een methodische aanpak: • De methode die wordt beschreven in het proefschrift ‘A Method for Component-Based and Service-Oriented Software Systems Engineering’ (Stojanovic, 2005). • Semantische webservicemethoden zorgen voor een betere manier om tot de juiste services te komen, door ze niet als applicatiediensten maar als een combinatie van bedrijfskundige aspecten en informatieaspecten te zien (Vrijkorte & Bastiaansen, 2006).

14

De rol van open standaarden (zie voor een definitie Van den Assem e.a., 2007) is van groot belang bij het ontwikkelen van standaardservices of standaardsuites. Het gaat daarbij niet alleen om technologiestandaarden zoals SOAP en WSDL, maar vooral om uitwisselingsstandaarden, zoals het in Nederland toegepaste Standaard UitwisselingsFormaat (StUF) (EGEM i-teams, 2008). Omdat standaardsoftwarepakketten in verschillende omgevingen worden toegepast en interoperabiliteit essentieel is, moeten meer van dit type standaarden worden gedefinieerd. We zien gelukkig dat dit in meer branches gebeurt, zoals in de gezondheidszorg. Daar werkt de beheerder van de HL7-standaard (Health Level Seven, 2008) samen met de Object Management Group in het Healthcare Service Specification Project (HSSP) aan een proces tot het standaardiseren van services (Van der Zel & De Bel, 2007).

Het bepalen van services en het onderscheid tussen generieke en specifieke services Zoals al is aangegeven zijn voor het ontwerpen van

geschikte services eigenlijk nog weinig methoden beschikbaar. Er is wel aanbod van consultancybedrijven in de vorm van bijvoorbeeld Service Identification Toolkits (Accenture, 2007). Deze methode kent een top-down benadering vanaf missie - visie - strategie. Voor de ontwikkeling van een standaardsoftwarepakket is dit echter moeilijk, want er kan niet worden uitgegaan van één situatie zoals dat bij maatwerkontwikkeling wel het geval is. Het ontwikkelen van een goede referentiearchitectuur van de processen van de totale klantengroep (ook toekomstige) is daarom noodzakelijk. Voor standaardsoftwarepakketten, nu standaardsuites genoemd, maakt Centric het volgende onderscheid: • specifieke services: services met een toepassing voor een specifiek proces of een taak binnen een proces; • generieke services: services die algemeen toepasbaar zijn, bijvoorbeeld voor CRM; • utility services: services die algemeen toepasbaar zijn, bijvoorbeeld voor beveiliging, autorisatie of documentmanagement. Deze volgorde bepaalt de make-or-buybeslissing. Specifieke services ontwikkelt Centric zelf, voor generieke services wordt gekeken naar beschikbare services op de markt. Utility services zijn steeds vaker beschikbaar bij organisaties en maken geen deel uit van de nieuwe standaard softwarepakketten.

»Software als Service is alleen levensvatbaar als de basis wordt gevormd door nieuwe standaardsuites met een SOA-structuur

«

Welke zaken moet men in de praktijk regelen? • Tests en configuratiemanagement worden belangrijker in een SOA-omgeving. De interfacedefinitie zegt iets over de technische integreerbaarheid, maar in de praktijk zijn meer dingen van belang. De semantiek of inhoudelijkheid van de gegevens die worden aangeboden en afgenomen, moet eenduidig zijn voor de afnemers van de service. Tests moeten dit aspect meenemen. Daarnaast moeten services los te testen zijn, waar-

Welke organisatorische maatregelen zijn nodig in een organisatie die op meerdere plaatsen aan services werkt? Ontwerpen moeten servicegericht worden opgesteld en ontworpen services moeten op een centraal punt worden gemeld (Van Heur, 2007), getoetst en geregistreerd. Dit voorkomt dat services maar eenmalig worden gebruikt en er nieuwe point-to-point oplossingen ontstaan. Deze centrale organisatie dient het mandaat te hebben om wijzigingen voor te stellen, hergebruik af te dwingen en richtlijnen te kunnen uitvaardigen.

Samenvattend Standaardsoftwarepakketten ontwikkelen op basis van SOA is op dit moment nog een combinatie van het ontwikkelen van best practices en het volgen van genoemde methoden. Interoperabiliteit, noodzakelijk voor de gewenste flexibiliteit, is technisch gezien inmiddels goed mogelijk, maar er is grote behoefte aan uitwisselingsstandaarden die door de markt worden geaccepteerd en toegepast. Servicegericht denken is op zich al een omslag, maar voor leveranciers van standaardsoftwarepakketten komt daar nog bij de complexiteit van de verschillende omgevingen waarin ze deze pakketten moeten opnemen. Dit vereist een meerjarentransitie waarin de software migreert naar een SOA-structuur en tegelijkertijd wordt aangepast voor noodzakelijke functionele wijzigingen. In de visie van Centric zullen leveranciers van

standaardsoftwarepakketten een grote rol gaan spelen in de wereld van SOA, Software as a Service (SaaS) (Vermeulen, 2006) en straks Software als Service (SaS) (ICTRegie, 2007). Zij hebben immers veel kennis van de processen en door het beschikbaar stellen van de juiste services worden bedrijven (hun klanten) niet alleen snel voorzien van de juiste software, maar kunnen die ook direct inspelen op veranderingen dankzij de flexibele structuur. SaS levert vooral rendement op als er voldoende schaalgrootte is in het gebruik van de software en dit is alleen mogelijk met standaardsoftwarepakketten. Kortom, SaS is alleen levensvatbaar als de basis wordt gevormd door nieuwe standaardsuites met een SOA-structuur. Pakketsoftware 2.0 dus.

Literatuur Accenture (2007). The role of the Accenture Enterprise Architecture SOA Solution in achieving high performance. Assem, R. van den e.a. (2007). Open Standaarden en Open Source, Onderzoek ter ondersteuning van gewenste beleidsintensivering. Verdonk, Klooster & Associates. Besten, A. den (2006). Business Critical Applications in Nederland; het maatwerk voorbij? ComputerPartner 7. Donatz, R. & F. van Outvorst (2003). Functioneel beheer bij pakketten. In J. van Bon (red.), IT Beheer Jaarboek 2003. Den Haag: Ten Hagen & Stam. EGEM i-teams (2008). StUF, http://egem-iteams.nl/stuf. Erl, T. (2007). SOA Principles, www.soaprinciples.com. Evdemon, J. (2005). Principles of Service Design: Service Patterns and Anti-Patterns. Microsoft Corporation, Architecture Strategy. Health Level Seven (2008). Health Level 7, www.hl7.org. Heur, R. van (2007). Center of Excellence onmisbaar bij SOA. Computable, 21 juni. ICTRegie (2007). Roadmap Software Als Service: Visie, toekomstscenario’s en roadmap. Matthews, J. & M. Guttman (2006). SOA: Managing the Transition. Software Magazine, January. Natis, Y.V. (2003). Service-Oriented Architecture Scenario. Gartner. Oord, E. & E. van Ginneken (2005). Een service-oriented architecture verdient een business case. Informatie, november. Steghuis, C. (2006). Service Granularity in SOA Projects: A Trade-off Analysis. Scriptie Universiteit Twente. Stojanovic, Z. (2005). A Method for Component-Based and Service-Oriented Software Systems Engineering. Proefschrift TU Delft. Vermeulen, P. (2006). De Business Case voor Software as a Service. White paper IDC. Vrijkorte, B. & H. Bastiaansen (2006). Raamwerk voor semantiek in webservices: Automatische koppeling van bedrijfs systemen. Informatie, november. Zel, M. van der & E. de Bel (2007). HL7 versie3 en de Ziekenhuis Service Bus. HL7 Magazine 5.

Leen Blom is manager Research & Development bij Centric Software Engineering. Hij leidt het architectuurproject voor Centric Melodies, een meerjarenprogramma voor de transitie van de software voor de lokale overheid naar een servicegerichte architectuur. E-mail: [email protected].


voor extra voorzieningen moeten worden getroffen (zoals zogenaamde stubs en drivers). • Ontwerpers moeten ervoor zorgen dat zaken niet dubbel gebeuren, bijvoorbeeld validaties zowel voor als achter de interface. Veel valkuilen zijn inmiddels in kaart gebracht, zodat ontwerpers en ontwikkelaars worden ondersteund met SOApatterns en anti-patterns (Evdemon, 2005). • Door de decompositie van een applicatie in kleinere onderdelen, die per stuk op meer plaatsen in gebruik kunnen zijn, is het inrichten van configuratiemanagement een absolute voorwaarde. • Autorisatie moet van meet af aan meegenomen worden in ontwerp en ontwikkeling. Dat is voor standaardsoftwarepakketten extra complex omdat de leverancier niet kan uitgaan van één standaard technische infrastructuur. • Bij composite services is de quality of service gelijk aan of minder dan die van de zwakste service. Dit stelt hoge eisen aan aspecten als betrouwbaarheid en performance.

15

Op weg naar Pakketsoftware 2.0

Recommend Documents