6best practises voor het koppelen van applicaties

6
BEST PRACTISES
VOOR HET KOPPELEN
VAN APPLICATIES
De waarde van een Architectuur voor business en IT
Joost bentvelsen
6 BEST PRACTISES
VOOR HET KOPPELEN
VAN APPLICATIES
De waarde van een architectuur voor business en IT
Het koppelen van applicaties wordt doorgaans gezien als een technisch vraagstuk. Al snel wordt er
bij integratie gesproken over technieken. Integratie gaat in essentie niet over technologie. Het gaat
erom een fundament neer te leggen dat naar de toekomst toe een wezenlijke bijdrage levert aan de
bedrijfsdoelstellingen. Techniek is een middel, geen doel.
In dit artikel presenteert Joost Bentvelzen - Solution Architect Integratie en Mobility bij Breinwave zes bewezen architecturen die als basis kunnen dienen voor uw specifieke scenario.
Het #koppelen van applicaties wordt doorgaans
gezien als een technisch vraagstuk. Al snel wordt
er bij integratie gesproken over technieken als BizTalk, webservices, ESB’s en wat al niet meer.
Maar #integratie gaat wat mij betreft in essentie
niet over technologie. Het gaat erom een fundament neer te leggen dat naar de toekomst toe een
wezenlijke bijdrage levert aan de bedrijfsdoelstellingen. Techniek is een middel, geen doel. En daarom is Integratie Architectuur in de praktijk complex: juist door het verbinden van business en IT.
HET GEVAAR VAN KOPPELEN
Het koppelen van systemen is tegenwoordig niet
meer echt moeilijk. Elke applicatie heeft voorbereidingen getroffen om te koppelen met de buitenwereld en er zijn tal van ‘standaarden’ ontwikkeld
die als basis gebruikt kunnen worden. Als je een
techneut vraagt om twee willekeurige systemen
te koppelen, dan is de kans groot dat de techniek
geen bottleneck is. En ook veel verkopers van (deel)
oplossingen wagen zich aan de uitspraak dat hun
applicatie kan worden gekoppeld aan ieder ander
systeem.
Maar wie hieraan toegeeft en kiest voor een pragmatische aanpak, kan al vrij snel geconfronteerd
worden met de nadelige gevolgen ervan. Pragmatisme blijkt dan opportunisme. Een dergelijke koppeling betreft namelijk als snel maatwerk. En ook
als er tools worden gebruikt waarmee kan worden
geconfigureerd in plaats van geprogrammeerd,
is de kennis in de praktijk vaak maar bij enkelen
bekend en slecht gedocumenteerd. Dat is geen
probleem zolang de koppeling doet wat ervan verwacht wordt. Het probleem ontstaat als de wensen
veranderen.
Want zodra er nieuwe requirements ontstaan,
heeft dit impact op de koppeling. Een veld erbij
bijvoorbeeld, kan al snel een dure aangelegenheid
worden omdat dit in twee systemen en de koppeling gerealiseerd moet worden. Zowel in een ontwikkelomgeving, een testomgeving, een acceptatie
omgeving en een productieomgeving.
En dan hebben we het nog niet eens over het
upgraden van systemen. Steeds vaker kom ik
bedrijven tegen die op softwareversies van jaren
geleden werken omdat ze vanwege alle koppelingen #niet meer kunnen of durven upgraden. En
daardoor halen ze niet de potentie uit ICT die de
concurrentie wel heeft. En dat is duur. De kosten
van een koppeling zitten hem dus niet alleen in de
realisatie ervan, maar vooral ook in het beheren
en uitbreiden ervan. En in de beperkingen die er
daarna ontstaan.
De oplossing hiervoor is niet moeilijk. Het is met
name een attitude. Doe eerst een stap terug en doe
er dan twee vooruit, geldt hier als belangrijkste
uitgangspunt. Wie meteen begint over de tools en
pragmatisch aan de slag denkt te gaan, is uiteindelijk duurder uit. Een goed #fundament neerleggen
is de basis en kan met weinig inspanning.
WAAROM EEN ARCHITECTUUR?
Werken vanuit een #architectuur biedt zowel de
business als de IT houvast. Waar de business het
vaak vooral belangrijk vindt om flexibel te zijn,
focust de IT zich ook op zaken als betrouwbaarheid
en veiligheid. Daarnaast zijn beiden erbij gebaat
de totale kosten, dus inclusief het beheer, zo laag
mogelijk te houden.
Een architectuur helpt hierbij. Er ontstaat inzicht
in het #applicatielandschap. Er is duidelijk welke
applicatie welk doel dient en waar elke applicatie in
het proces wordt toegepast. De koppelingen tussen
applicaties worden expliciet gemaakt. En als er in
de toekomst nieuwe applicaties worden overwogen,
dan kunnen deze worden getoetst tegen de architectuur.
HOE KOM JE ERACHTER WAT DE BUSINESS WIL?
Een architectuur is geen one-size-fits-all. Als iemand
mij advies vraagt over bijvoorbeeld koppelingen,
dan begin ik met het stellen van vragen. Ik wil
weten wat de achterliggende doelstellingen zijn en
kunnen voorspellen welke richting dit de komende
jaren op zal groeien. Op basis van business requirements dus en niet op basis van technologie.
Om de business requirements in korte tijd te doorgronden, begin ik bij de kern. De waardepropositie
van het bedrijf richting haar klanten. Waarom
komen klanten daar? Wat vinden ze wat ze elders
niet vinden? Wat maakt dit bedrijf uniek? En hoe
kan IT daar een bijdrage aan leveren of het zelfs
versterken?
Tracey en Wiersema hebben met hun waardemodel
een bruikbare tool gegeven om hier een referentiekader voor te scheppen en de waardepropositie
expliciet te maken. Door te bepalen of een bedrijf
vooral bestaat vanuit Product Leadership, vanuit
Customer Intimacy of vanuit Operational
Excellence.
En op basis daarvan kun je ook vaststellen of vooral
het product, de klant of het proces centraal staat.
En dat kun je meteen vertalen naar IT. Want wat
is eigenlijk het #kernsysteem: ERP (proces), CRM
(klant) of PIM (product)?
Een ander model dat ik graag toepas is het Business
Model Canvas. Dit model biedt een structuur waarin elk business model kan worden gevangen. Het
richt zich op interne en externe zaken en vertaalt
dit naar kosten en opbrengstenstructuren. Het
maakt scherp wie de klant is, hoe deze benaderd
wordt, welke waarde er geleverd wordt en welke
activiteiten er nodig zijn om dat te bereiken.
Figuur 2 | Business Model Canvas
Bij het invullen van het BMC zouden in principe
alle antwoorden al vast horen te staan. Toch blijkt
dat als dit expliciet gemaakt wordt er vaak nieuwe
inzichten en discussies ontstaan die helpen e.e.a.
scherp te krijgen. Vanuit het BMC kan worden
gedestilleerd welke fundamentele eisen dit aan de
onderliggende IT stelt. En die requirements zullen
dus niet zomaar elk half jaar veranderen.
WERKEN VANUIT BEST-PRACTISES
Hoewel ieder bedrijf anders is en dus de requirements ook verschillen, kan er natuurlijk wel gebruik gemaakt worden van best-practises bij anderen. Soms om deze één op één toe te passen, maar
vooral als referentie om vervolgens tot een eigen
architectuur te komen.
Onderstaand wordt een vijftal best-practises uitgewerkt. In de praktijk kunnen er vaak zo al twee of
drie worden weggestreept zodat snel kan worden
gefocust op één of twee #uitgangspunten en op
basis daarvan nuancering kan worden aangebracht.
De scenario’s starten van minimale complexiteit
naar maximale complexiteit.
Figuur 1 | Waardemodel van Tracey en Wiersema
SCENARIO 1: ALLES IN ÉÉN SYSTEEM
SCENARIO 2: EÉN SYSTEEM IS LEIDEND
De kracht van het eerste scenario is dat alle data
centraal is opgeslagen en er maar één versie van de
werkelijkheid is. Maar de beperking van alles in één
systeem maakt het in de praktijk vaak onrealistisch.
Al was het maar omdat ook externen zoals klanten
en leveranciers vaak toegang tot de informatie moeten krijgen en het niet gewenst is dat die direct tot
het eigen systeem toegang krijgen.
Figuur 3 | Scenario 1 - Alles in één systeem
Het eerste scenario betreft de #integrale oplossing.
Hoewel dit het scenario is waar veel bedrijven ooit
mee zijn gestart, lijkt het inmiddels een onrealistische utopie te zijn geworden. Want hoe groot is de
kans dat je één applicatie vindt die aan alle eisen en
wensen voldoet? En waarom zou je dat willen als
koppelen tegenwoordig geen probleem meer zou
moeten zijn?
Figuur 4 | Scenario 2 - Eén systeem is leidend
Het voordeel van deze ‘architectuur’ is echter
enorm. Alle gegevens worden in één centraal systeem opgeslagen en bewerkt. Er is maar één versie
van de werkelijkheid. Als ergens een wijziging
plaatsvindt, dan hoeft dat maar op één plek. En als
je ooit wilt upgraden naar een nieuwe versie, dan
scheelt het een heleboel tijd in het testen.
Scenario 2 gaat ervan uit dat nog steeds één systeem
centraal staat, maar dat andere systemen kunnen
worden aangekoppeld voor #specifieke doeleinden.
Te denken valt aan een webshop, een portal en/of
een mobiele app. Die functioneren dan als frontend voor een specifieke doelgroep, maar halen en
schrijven hun gegevens uit het leidende systeem.
De keuze om niet alles in één systeem te vangen
biedt functioneel dus mogelijk wel een voordeel.
Maar daar wordt wel een prijs voor betaald. Zeker
in bedrijfsomgevingen waar veel flexibiliteit van de
systemen wordt gevraagd, dus waar veel aanpassingen zijn te verwachten, leiden koppelingen tot veel
extra kosten en doorlooptijd. En wordt het daarmee
mogelijk een beperkende factor.
Dit scenario gaat er dus nog steeds vanuit dat er
één versie van de werkelijkheid is. Er is echter geen
integrale oplossing en er zullen dus koppelingen
moeten worden ontwikkeld en onderhouden. Dit
betekent dat mutaties in het datamodel soms op
meerdere plekken moeten plaatsvinden, maar dat
de complexiteit van de koppelingen meevalt omdat
voor iedereen duidelijk is wat het leidende
systeem is.
Als het kan, adviseer ik dus het liefst een zo simpel
mogelijke architectuur. Met bijvoorbeeld alles in
ERP of alles in CRM. Want wat is er simpeler dan
een integrale oplossing? Maar alleen als het kan.
Want als dit systeem onvoldoende bijdraagt aan de
bedrijfsdoelstellingen, vervalt deze optie wat mij
betreft direct.
Applicaties worden in dit scenario dus ook niet onderling gekoppeld, maar communiceren altijd via
het leidende systeem. Nadeel kan zijn dat daardoor
het centrale systeem moet worden uitgebreid om
data uit andere systemen te kunnen doorgeven
die ver weg staan van het doel van het leidende
systeem. Belangrijk daarom is vroegtijdig vast te
stellen welke #gegevensstromen er uiteindelijk
worden verwacht.
SCENARIO 3: HET PROCES ALS BASIS, APPLICATIES IN HUN
COMFORTZONE
SCENARIO 4: best of breed
Het laatste en meest uitgebreide scenario gaat op
indien de voorgaande scenario’s niet voldoen. In dit
scenario wordt ervan uitgegaan dat er veel verschillende systemen in gebruik zijn die onderling zullen
overlappen qua #datamodel en #functionaliteit.
Figuur 5 | Scenario 3 - Proces leidend
In dit scenario wordt niet geprobeerd om alle data
in vaste systemen vast te leggen. Elk systeem krijgt
in dit scenario een eigen taak en houdt zich aan
zijn eigen scope. Voordeel is dat er maximaal kan
worden uitgegaan van standaard software en dat
elke applicatie die iets bijdraagt aan de bedrijfsdoelstellingen kan worden ingezet.
In scenario 3 is er geen sprake van één leidend systeem, maar wordt per proces bepaald welk systeem
leidend is. Zo kan er onderscheid gemaakt worden
tussen een CRM-systeem voor de front-office en een
ERP-systeem voor de back-office. En eventueel kan
er ook een PIM-systeem worden ingezet rondom
productmanagement.
Nadeel van dit scenario is de #complexiteit. Het
opstellen en bijhouden van een goede architectuur
is onontkoombaar en gezien de strategische waarde
van IT voor veel bedrijven betekent dit dat het ook
aan te raden is om in huis over de juiste competenties te beschikken om e.e.a. zelf in de hand te
houden.
Alle andere systemen worden dan aan één van deze
systemen gekoppeld afhankelijk van bij welk
#proces ze thuishoren. Een scanningsapplicatie in
het magazijn zal dan bijvoorbeeld worden gekoppeld aan ERP (logistiek), terwijl een module om
nieuwsbrieven te versturen dan zal zijn gekoppeld
aan CRM (marketing).
Wanneer een #best-of-breed landschap gewenst is,
zijn er nog verschillende vormen waarin de
#integratie architectuur kan worden opgesteld.
Dit scenario kan goed werken wanneer het proces
duidelijk en vastomlijnd is en wanneer daarin duidelijke afbakening kan plaatsvinden. Als de overlap
van data en processen minimaal is, kan een dergelijk scenario sterk zijn doordat applicaties binnen
hun #comfortzone opereren en er veelal gebruik
kan worden gemaakt van bestaande koppelingen
tussen systemen.
Lastig wordt het indien de overlap van data wel
groot is. Als het resultaat zou zijn dat alle klanten,
alle artikelen, alle prijzen, alle orders, alle facturen,
etc. in meerdere systemen moeten worden vastgelegd, dan betekent dat een uitgebreide en weinig
flexibele koppeling. En als er een extra kernsysteem
komt, zoals bijvoorbeeld een website die met alle
andere systemen data moet gaan uitwisselen dan
zal dat de complexiteit alleen maar doen toenemen.
Point-to-point
De meest bekende en pragmatische integratiewijze
is point-to-point. Er wordt in kaart gebracht welke
applicaties met elkaar gekoppeld moeten worden
en deze worden stuk voor stuk ontworpen, gerealiseerd, getest en in gebruik genomen.
Figuur 6 | Scenario 4 - Point-to-point
Wanneer het aantal koppelingen meevalt en de
verwachting is dat dat in de toekomst ook zo zal
blijven, dan is #point-to-point een prima keuze (ook
in scenario 2 en 3). Maar als het aantal koppelingen
toeneemt, is het risico op zogenaamde spaghetti
groot.
Het overzicht raakt dan kwijt, fouten zijn niet meer
te herleiden en veranderingen of upgrades van
onderdelen zijn risicovol omdat de impact niet te
overzien is.
Message Broker
Wanneer er binnen een applicatielandschap veel
koppelingen zijn, of zijn te verwachten, dan is een
Message Broker van toegevoegde waarde. Een message broker wordt als spin in het web geplaatst en
dient als doorgeefluik van berichten tussen applicaties. Elke applicatie is gekoppeld met de broker en
er zijn geen directe onderlinge koppelingen.
Figuur 7 | Scenario 5 - Message Broker
Voordeel is dat er inzicht ontstaat. Op één plek
zijn alle berichten te herleiden en fouten kunnen
snel geanalyseerd worden. Bovendien maakt deze
architectuur het eenvoudiger om applicaties te upgraden omdat slechts de koppeling met de broker
hoeft te worden getest. Er ontstaat controle over
het gehele landschap.
Enterprise Service Bus
Een ESB lijkt in een aantal facetten op de Message
Broker. Ook deze wordt tussen de applicaties gezet
en regelt centraal de koppelingen. Het verschil met
de broker is dat een #ESB veel minder denkt vanuit
berichten, maar wordt opgezet vanuit processen. Zo
zal de ESB een functie NieuweKlant() ondersteunen
waarop andere applicaties zich kunnen abonneren.
Bij een ESB worden het datamodel en de processen
dus centraal gedefinieerd. Als applicatie hoef je niet
te weten welke andere applicaties er in het landschap zijn, want je communiceert volgens vooraf
opgestelde contracten met de ESB.
Figuur 8 | Scenario 6 - Enterprise Service Bus
Nadeel van een ESB is dat deze vaak hele grote
stukken maatwerk bevat. Een ESB wordt vaak veel
groter en complexer dan vooraf gedacht. En als
er processen wijzigen, moeten alsnog alle koppelingen worden getest. De ESB is op papier dus een
ideale oplossing, maar geeft in de praktijk alsnog
een groot aantal nadelen. En als een bedrijf al een
kernsysteem heeft waarin vrijwel alle data en processen zijn ondergebracht (zoals een ERP-systeem),
dan leidt een ESB tot onnodig veel redundante
logica en lijkt scenario 2 beter toepasbaar.
VAN IT ARCHITECTUUR NAAR IT ROADMAP
Op basis van bovenstaande #best practises help ik
bedrijven om tot een architectuur te komen die het
beste aansluit bij hun bedrijfsmodel en die daadwerkelijk relevant is en bijdraagt aan de bedrijfsdoelstellingen. Dit vertaalt zich onder andere in een
‘ideaal’ applicatielandschap voor die casus.
En dan is het tijd voor de volgende stap. Want als je
eenmaal weet waar je naartoe wilt, kun je een plan
maken in de vorm van een #IT Roadmap. Hou er
hiermee wel rekening mee dat het geen ‘project’
wordt om de architectuur te implementeren, maar
dat het in de praktijk een ongoing proces zal zijn.
Want zowel business als IT zullen continu evolueren en een eindpunt voor wat betreft IT zal in veel
gevallen dus niet bestaan.
Maar voordat daarmee gestart wordt, is het ook
belangrijk te weten waar je staat. Dat kan eenvoudig
door alle actieve applicaties en onderlinge verbanden in kaart te brengen. Welke systemen werkt
iemand gedurende de week mee, welke processen
worden daarmee ondersteund, welke gegevens
worden daarin opgeslagen? Het huidige #applicatielandschap kan zo in beeld worden gebracht als
vertrekpunt.
En van daaruit kan worden bepaald welke stappen
als eerste gezet worden richting de toekomstige architectuur. Welke verbeteringen dragen het meeste
bij aan het bedrijfsresultaat? En welke systemen
moeten actief zijn voordat met andere gestart kan
worden? Een IT Roadmap helpt om het veranderproces expliciet te maken en om vanuit doelstellingen projectmatig stappen voorwaarts te zetten.
WELKE TOOL(S) ZET IK IN?
Ik ben mijn verhaal gestart met te zeggen dat men
niet te snel naar de tools moet grijpen. Maar als de
business doelstellingen helder zijn, de IT Requirements zijn bepaald, de Architectuur is uitgewerkt
en er een Roadmap is opgesteld om vanuit de huidige situatie stappen naar de toekomst te zetten, dan
is de vraag over de tools weer relevant.
Want op het gebied van integratie zijn veel mogelijkheden. Microsoft heeft uiteraard BizTalk als tool
die enerzijds kan worden ingezet als een Message
Broker en anderzijds als ESB (overigens kun je met
BizTalk ook prima Spaghetti realiseren). In de CRM
wereld zijn gespecialiseerde partijen als Scribe
van toegevoegde waarde. En in de ERP wereld van
Microsoft Dynamics wordt veel gewerkt met addons zoals Business Integration Solutions (met onder
andere Connectivity Studio) van To-Increase. En ook
maatwerk is in vrijwel alle gevallen een serieuze
optie om te overwegen. Om de juiste tool te selecteren, is dus meer inzicht nodig in de uiteindelijke
architectuur en de onderliggende overwegingen.
Figuur 9 | Stofzuigertest
Persoonlijk ben ik er wel voor om dergelijke keuzes
op basis van argumenten te maken. Ik heb daartoe
een #beslissingsmatrix opgesteld die sterk is geïnspireerd op de stofzuigertest van de consumentenbond.
Deze bestaat uit de volgende stappen:
1.
Bepaal welke alternatieven je wilt vergelijken.
Zet die onder elkaar.
2.
Bepaal wat de belangrijkste beoordelingscriteria zijn. Zowel functioneel als technisch.
Zowel vanuit business als vanuit IT. Zet die
naast elkaar.
3.
Bepaal per criterium wat de objectieve
requirements zijn om een bepaaldes score
(++, +,=, -, --) te behalen.
4.
Beoordeel vervolgens ieder alternatief voor
elk criterium.
5.
Pas weging toe, bijvoorbeeld op basis van
MoSCoW, om de verschillende criteria het
juiste gewicht te geven. Elimineer de
alternatieven die onvoldoende scoren op
must-haves en couldhaves.
6.
Bereken per alternatief de gewogen score
en de TCO. Op basis hiervan kan de beste
keuze en de beste prijs worden bepaald en
ontstaat beargumenteerde input om een
keuze te maken.
over breinwave
Breinwave ondersteunt organisaties bij het creëren van doorbraken in productiviteit, klantinzicht en klantinteractie. Om dit te realiseren vertrouwen wij op
de kracht die technologie kan bieden; mits goed ingezet kan technologie een nog veel grotere bijdrage leveren bij het realiseren van organisatiedoelstellingen.
Wij zijn onderdeel van de Abecon Groep, een van de toonaangevende Microsoft Dynamics partners in de Benelux.
meer informatie
Joost Bentvelsen - Solution Architect Mobility
+31 6 53 98 44 46
[email protected]

Download Report