6 BEST PRACTISES VOOR HET KOPPELEN VAN APPLICATIESDE wAARDE VAN EEN ARCHITECTuuR VOOR BuSINESS EN IT

JOOST BENTVELSEN

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.

6 BEST PRACTISES VOOR HET KOPPELEN VAN APPLICATIES

Het #koppelen van applicaties wordt doorgaans gezien als een technisch vraagstuk. Al snel wordt er bij integratie gesproken over technieken als Biz-Talk, webservices, ESB’s en wat al niet meer.

Maar #integratie gaat wat mij betreft in essentie niet over technologie. Het gaat erom een funda-ment neer te leggen dat naar de toekomst toe een wezenlijke bijdrage levert aan de bedrijfsdoelstel-lingen. Techniek is een middel, geen doel. En daar-om is Integratie Architectuur in de praktijk com-plex: 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 voorberei-dingen getroffen om te koppelen met de buiten-wereld 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 prag-matische aanpak, kan al vrij snel geconfronteerd worden met de nadelige gevolgen ervan. Pragma-tisme blijkt dan opportunisme. Een dergelijke kop-peling 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 ver-wacht 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 koppe-ling gerealiseerd moet worden. Zowel in een ont-wikkelomgeving, 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 koppelin-gen #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 uiteinde-lijk duurder uit. Een goed #fundament neerleggen is de basis en kan met weinig inspanning.

DE wAARDE VAN EEN ARcHiTEcTuuR VOOR busiNEss EN iT

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 archi-tectuur.

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 require-ments dus en niet op basis van technologie.Om de business requirements in korte tijd te door-gronden, 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 referen-tiekader 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.

Figuur 1 | Waardemodel van Tracey en Wiersema

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 waar-in 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-PRAcTisEsHoewel ieder bedrijf anders is en dus de require-ments ook verschillen, kan er natuurlijk wel ge-bruik gemaakt worden van best-practises bij ande-ren. 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 uitge-werkt. 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.

scENARiO 1: ALLEs iN ÉÉN sYsTEEM

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 onrealisti-sche 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?

Het voordeel van deze ‘architectuur’ is echter enorm. Alle gegevens worden in één centraal sys-teem 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.

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 aanpassin-gen zijn te verwachten, leiden koppelingen tot veel extra kosten en doorlooptijd. En wordt het daarmee mogelijk een beperkende factor.

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.

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 moe-ten krijgen en het niet gewenst is dat die direct tot het eigen systeem toegang krijgen.

Figuur 4 | Scenario 2 - Eén systeem is leidend

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 front-end voor een specifieke doelgroep, maar halen en schrijven hun gegevens uit het leidende systeem.

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.

Applicaties worden in dit scenario dus ook niet on-derling 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 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 verschil-lende systemen in gebruik zijn die onderling zullen overlappen qua #datamodel en #functionaliteit.

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 bedrijfsdoel-stellingen kan worden ingezet.

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 compe-tenties te beschikken om e.e.a. zelf in de hand te houden.

Wanneer een #best-of-breed landschap gewenst is, zijn er nog verschillende vormen waarin de #integratie architectuur kan worden opgesteld.

Point-to-pointDe 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, gereali-seerd, 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.

scENARiO 3: HET PROcEs ALs bAsis, APPLicATiEs iN HuN cOMfORTZONE

Figuur 5 | Scenario 3 - Proces leidend

In scenario 3 is er geen sprake van één leidend sys-teem, 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.

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 gekop-peld aan ERP (logistiek), terwijl een module om nieuwsbrieven te versturen dan zal zijn gekoppeld aan CRM (marketing).

Dit scenario kan goed werken wanneer het proces duidelijk en vastomlijnd is en wanneer daarin dui-delijke afbakening kan plaatsvinden. Als de overlap van data en processen minimaal is, kan een derge-lijk 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 vastge-legd, 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 toene-men.

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 BrokerWanneer er binnen een applicatielandschap veel koppelingen zijn, of zijn te verwachten, dan is een Message Broker van toegevoegde waarde. Een mes-sage broker wordt als spin in het web geplaatst en dient als doorgeefluik van berichten tussen applica-ties. 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 up-graden omdat slechts de koppeling met de broker hoeft te worden getest. Er ontstaat controle over het gehele landschap.

Enterprise Service BusEen 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 land-schap 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 koppe-lingen 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 pro-cessen 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 ROADMAPOp basis van bovenstaande #best practises help ik bedrijven om tot een architectuur te komen die het beste aansluit bij hun bedrijfsmodel en die daad-werkelijk relevant is en bijdraagt aan de bedrijfs-doelstellingen. 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 evolue-ren 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 verban-den in kaart te brengen. Welke systemen werkt iemand gedurende de week mee, welke processen worden daarmee ondersteund, welke gegevens worden daarin opgeslagen? Het huidige #applica-tielandschap kan zo in beeld worden gebracht als vertrekpunt.

En van daaruit kan worden bepaald welke stappen als eerste gezet worden richting de toekomstige ar-chitectuur. 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 verander-proces expliciet te maken en om vanuit doelstellin-gen 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 Require-ments zijn bepaald, de Architectuur is uitgewerkt en er een Roadmap is opgesteld om vanuit de huidi-ge situatie stappen naar de toekomst te zetten, dan is de vraag over de tools weer relevant.

Want op het gebied van integratie zijn veel moge-lijkheden. 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 add-ons 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 selec-teren, 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ïn-spireerd op de stofzuigertest van de consumenten-bond.

Deze bestaat uit de volgende stappen:

1. Bepaal welke alternatieven je wilt vergelijken. Zet die onder elkaar.

2. Bepaal wat de belangrijkste beoordelings- criteria 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.

MEER iNfORMATiEJoost Bentvelsen - Solution Architect Mobility +31 6 53 98 44 46joost.bentvelsen@breinwave.nl

OVER bREiNwAVEBreinwave 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.