6 BEST 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]