SRA Service transitie

[martijn...@gmail.com]

Werkgroep Service Transition

Aanwezig: Erik Proper (Cap Gemini / RU, Voorzitter), Sjoerd Meihuizen
(NWO, verslag), Paul Klint (CWI), Walter Smit (Reaal), Daan Velthausz
(Surfnet), Tom Vollebergh (Achmea), Erik van Pelt (ICTRegie), Marc
Lankhorst (Telematica), Rik van Kampenhout (Atos Origin), Theodoor van
Dongen (Cordys), ??.


De discussie binnen de werkgroep draaide vooral om de vraag wat is
service transition, waar praten we nu eigenlijk over en wat zijn de
uitdagingen en knelpunten? Is het een technisch probleem of komt er
meer bij kijken? Welke vormen en lagen van transitie kunnen worden
aangeduid, en welke zijn belangrijk genoeg om in de toekomst nader te
bestuderen?

Eigenlijk zijn er in deze context twee soorten van transitie:
technisch (legacy) en bedrijfsmatig (ownership). Een voorbeeld van een
probleem op het gebied van legacy werd tijdens de discussie
aangehaald. Dit vond recentelijk plaats bij UWV: de systemen leenden
zich er niet voor om op een service gerichte manier te werken en daar
kwam bij dat men niet veel zin had om alles opnieuw te bouwen.
Uiteindelijk werd het project afgeblazen met als gevolg een enorm
financieel verlies. Legacy heeft mede door zulke gevallen en andere
slechte publiciteit een negatieve bijklank gekregen.


De discussie verschoof al gauw naar het in kaart brengen van de
verschillende vormen en niveau’ s van transitie. Er is bijvoorbeeld
transitie binnen processen, maar ook op tijdsniveau. Het ombouwen van
bestaande systemen gebeurt vaak in kleine stapjes. Het gaat om
complexe systemen dus het is zaak om de boel niet te verstoren.
Transitie komt voor op technologisch gebied, maar ook binnen
werkprocessen, machtsverhoudingen en controle. Als je die uit elkaar
laat trekken ontstaan er nog meer problemen. Hoe stuur je het zo dat
alles in balans is?


Andere belangrijke vragen die spelen als we het hebben over service
transition zijn: hoe maak je duidelijk waar je heen wil? En: hoe geef
je richting aan keuzes? Dit zijn vragen of doelen die steeds
bijgesteld moeten worden. Hoe bijvoorbeeld ook om te gaan met
onstabiele, niet bekende requirements? Je moet een vaag toekomstbeeld
hebben van wat je wil en welke factoren je moet kennen. De transitie
wordt vooral gestuurd door een sterke dynamiek. Daarom is het van
belang deze dynamiek te vervatten in een model.

Het is belangrijk om migratie gemakkelijk te maken. Gigantische
brokken software kunnen een gigantische spaghetti veroorzaken.
Eigenlijk zou een click and play scenario voor grote stukken software
ideaal zijn. Daarnaast zit de complexiteit ook vaak in het business
model. Op papier ziet migratie er mooi uit maar in praktijk werkt het
zomaar niet. Paul Klint’s uitgangspunt is dat je eerst de oude
situatie moet snappen. “Wat heb je nou?” Je moet deze kennis opbouwen,
en vanuit die kennis maak je een doelsysteem.

Als je het hebt over SaaS, dan heb je het vooral over processen tussen
bedrijven. Het is eigenlijk een groot ecosysteem: hoe organiseer je
dat systeem van bedrijven. In de praktijk blijkt dat dominante spelers
hun wil kunnen opleggen, maar als er geen centrale of dominante
partner is kan dat tot verwarring leiden.

Een meerderheid van de werkgroep voelt er voor om de best practices te
beschrijven; er zijn genoeg cases bekend. We kunnen dan de lessons
learned in generieke processen in kaart brengen. Maar ook: wat zijn de
grote problemen die opgepakt moeten worden? Hoe krijgen we dat voor
elkaar? Paul Klint stelt voor om voor de onderzoeksvragen een kapstok
te maken met daarin zowel de business en de technology vraagstukken.

Op een gegeven punt binnen de discussie kwam de werkgroep tot de
conclusie dat transitie niet het juiste woord in deze context.
Transformatie is een betere term; want het streven naar verandering is
een voortdurend proces. Transitie klinkt als iets wat een keer
plaatsvindt, terwijl transformatie minder definitief klinkt. Vandaar
ook de titel van dit document: Service-oriented Enterprise
Transformatie. SoA en SaaS zijn benaderingen, met onderliggende
enabling technologies, die enterprise transformatie drijft en
enabled.


Transformatie is vanuit een organisatie redenerend een zeer complex
proces. Je doel beweegt omdat je bijvoorbeeld nieuwe kansen ziet, en
eigenlijk ben je daarom bezig steeds dat doel te zoeken en bij te
stellen. Service Transformatie moet daarom een ontwerp hebben. Een
ontwerp waarin geld, governance, technologie – en principes met elkaar
in verbinding staan. Maar hoe robuust is mijn ontwerp, wat zijn de
realistische parameters en hoe weet ik dat mijn product aan het eind
van de rit nog bestaat? Hoe kan ik berekenen dat het werkt? Wat voor
beperkende factoren moet ik opruimen? Allemaal vragen die het waard
zijn nader te bestuderen.


In deze discussie kwam ook naar voren dat het zinnig is te denken in
termen van "goal seeking" in plaats van "goal reaching". Door de
continu veranderende socio, economische en technologische
omstandigheden zal het specifieke doel nogal eens verschuiven. Daarin
is een werkwijze die er op gericht is "in de juiste richting te
bewegen" in plaats van zich alleen of een specifiek gefixeerd toekomst
doel te richten beter op zijn plaats. In de werkgroep werd in dit
verband ook expliciet verwezen naar de ontwikkelingen op het gebied
van Six-Sigma lean. Continu optimaliseren, hereiken en bijstellen.


NB: Het feit dat de werkgroep in haar discussie eigenlijk meer op
enterprise transformatie in het algemeen uit kwam, met SoA en SaaS als
drivers/enablers, lijkt een indicatie te zijn dat er behoefte is eerst
breed te kijken naar het vraagstuk alvorens specifieke
onderzoeksvragen worden geformuleerd.


SaaS en SoA bieden zeker nieuwe uitdagingen, maar er zijn desondanks
ook relevante ervaringen op het gebied van bijvoorbeeld BPO die veel
inzicht kunnen bieden om met de nieuwe uitdagingen om te gaan.
Onderzoek naar best/bad-practices op dit gebied zou zeker wenselijk
zijn.


Ook het opleiden van de juiste mensen voor SaaS kwam aan de orde. De
ervaring van sommige binnen de werkgroep is dat nieuwe mensen vaak
traditioneel zijn ingesteld omdat ze net hebben doorgeleerd over vaste
bedrijfsmodellen. “Oude” werknemers zijn vaak flexibeler, en hechten
minder aan regels. Agility, het kunnen omgaan met constante
veranderingen bij software transformatie moet meer worden benadrukt in
opleidingen.

Een van de laatste punten van discussie ging over SOA en SaaS. SOA is
interessanter, SaaS is een delivery model, volgens sommigen. Ook werd
een nieuwe definitie van SaaS naar voren gebracht: waarom niet Sector
as a Service? Men kan beter als sector samenwerken, en de boel
standaardiseren in plaats van te concurreren.


Tenslotte had de werkgroep nog een advies aan het bestuur van de IIP
SaaS. Er zijn vele netwerken en mensen binnen een sector of discipline
kennen elkaar meestal al. Wat is de absolute meerwaarde van het IIP,
zou er misschien een SWOT analyse kunnen worden opgesteld, om daarmee
beter het netwerk te kunnen positioneren?

Hieronder een top 5 van belangrijkste punten binnen de WG:

1. Transitie = Continue

2. IST  SOLL
3. Beeld van nu naar “doel”

4. Goal Seeking: je hebt goal, hierarchy, inzicht en kansen in
ecologie. 5. Lesmateriaal
Naar de specifieke themas kan onderzoek gedaan worden, maar ook kunnen
we casussen en best/bad practices in kaart brengen.

Suggesties
Gebaseerd op de discussies in de werkgroep, en het electronische
vervolg, komen we tot de volgende suggesties voor het vervolg.

1. Er is behoefte om de discussies voor te zetten. Het NAF
(Nederlands Architectuurforum (www.naf.nl)) heeft aangegeven bereid te
zijn een SaaS werkgroep te willen faciliteren. Bij voldoende interesse
kan dit opgestart worden.
2. Het is momenteel niet makkelijk om precieze onderzoeksvragen te
formuleren. Wel is duidelijk dat SoA en SaaS vele uitdagingen
meebrengen, die zeker tot onderzoeksvragen zullen leiden. Daarom zou
het zinnig zijn om op basis van best-practices en bad-practices eerst
inzicht te verwerven, en hierbij ook relevante ervaringen op het
gebied van BPO, lean-six sigma, etc, mee te nemen. Dit zou kunnen
leiden tot:
1. Fase 1: Het is duidelijk dat er veel valt te onderzoeken
mbt SaaS en SoA. Maar om tot een goede prioriteitsstelling te komen is
meer inzicht nodig. Alvorens een veelheid aan deeltrajecten op te
starten is het nodig eerst een fact-finding fase uit te voeren. Waar
zitten de echte problemen? High yield vraagstukken? Daarom moeten we
best-practices en bad-practices onderzoeken, de mogelijkheden/belofte
van SaaS concreet maken, en in termen hiervan concrete
onderzoeksvragen formuleren.
2. Fase 2: Onderzoeksvragen prioriteren en vertalen naar
onderzoeksopdrachten (4 jarige promotietrajecten), en vervolgens de
uitvoering van deze onderzoeksopdrachten vanuit het SaaS project
aanbesteden aan Universitaire partijen. Dit kan leiden tot een aantal
parallele onderzoeksstreams. Bijvoorbeeld: benodigde modelleertalen,
generatie van applicaties en/of wrapping vanuit modellen, methode om
met "goal-seeking" om te gaan, etc. Dit vereist dat er in een SaaS
onderzoeksprogramma sprake is van een stuurgroep die expliciet
besluiten kan nemen over de uit te voeren onderzoeksopdrachten en
termen van prioriteiten en scoping, en de aanbesteding hiervan kan
begeleiden.
3. Fase 3: Uitvoering van de onderzoeksopdrachten. Hierbij
werkende volgens een model waarbij in jaarlijkse cycli wordt gewerkt
aan iteraties (gesynchroniseerd over de parallel lopende
onderzoeksopdrachten) van de onderzoeksresultaten en toetsing/
evaluatie hiervan in praktijkcasussen.
3. Het lijkt verstandig om in parallel:
1. Een laboratorium te vormen om ervaring op te doen met
bestaande technieken/aanpakken evenals de nieuwe resultaten vanuit het
onderzoek. Hierbij zouden ook toolleveranciers,
technologieleveranciers en dienstverleners expliciet bij betrokken
moeten worden om te zorgen dat bruikbaar gebleken resultaten snel
doorstromen naar de dagelijkse praktijk.
2. Awareness/onderwijs/trainingsmateriaal te ontwikkelen.
Beginnende met de vraag "wat betekent SaaS voor mij?", en uitmondende
in concrete methoden om eea aan te pakken. Onderscheid maken tussen
onderwijs, training en voorlichtingsmateriaal.
3. Ervaringen te blijven uitwisselen. Dus het werk van Fase 1
door te zetten. Dit zou heel goed ism een bestaande structuur, zoals
het NAF, opgezet kunnen worden als flankerende NAF werkgroep op het
gebied van SaaS.