De bomen en het bos in het IT landschap
Wat maakt integraties lastig?
Inleiding
Wanneer in een bedrijf meerdere applicaties worden gebruikt, komt vroeger of later het vraagstuk van integraties aan de orde. Applicaties binnen eenzelfde type zijn makkelijker te integreren dan applicaties van verschillend type. Het onderscheid in die verschillende typen is handig om een eerste begrip van een applicatie te krijgen. Maar het is vooral handig, omdat men er de integraties mee in kaart kan brengen in de applicatiearchitectuur, ook wel het IT-landschap genaamd. In de vorige blogs hebben wij achtereenvolgens transactionele systemen, documentaire systemen, real-time systemen en advanced planningsystemen besproken. Er zijn overigens nog wel meer typen, zoals bijvoorbeeld data warehousing systems, workflow management systems, of financial planning systems.
Waarom integreren?
De behoefte aan integraties is onlosmakelijk verbonden met verdere digitalisering. Steeds weer ontdekt men dat verschillende applicaties op aanpalende gebieden van de bedrijfsvoering elkaar kunnen versterken door onderling informatie uit te wisselen of door gebruik te maken van elkaars bedrijfslogica. Vaak is integratie ook gericht op het vermijden van overlap of redundantie. Een IT-landschap laat zien welke integraties er zijn, maar vooral ook welke integraties gepland worden. Soms kan ook duidelijk worden welke applicaties kunnen worden afgebouwd. Op die manier wordt de bijdrage van digitalisering aan de bedrijfsvoering zichtbaar, planbaar en beheersbaar – ook qua kosten en baten.
Een voorbeeld van een IT-landschap is in de figuur hieronder weergegeven. In dit IT-landschap zijn applicaties van hetzelfde type bij elkaar geplaatst. Door dit te doen, ontstaat inzicht in de aard van de integraties en de inspanningen die daarmee gepaard gaan.
Integraties vragen blijvend aandacht
De meeste applicaties die tegenwoordig worden geïmplementeerd zijn standaardapplicaties. Zulke applicaties kennen veel parameters, zoals de taal waarin wordt gecommuniceerd, de schermindeling, kleurgebruik, gebruikersrechten, maar ook welke functionaliteit wordt gebruikt of geblokkeerd. Om standaardapplicaties te kunnen gebruiken, moeten deze applicaties worden geconfigureerd; de parameters moeten een waarde krijgen. Tijdens de levensduur van de applicatie wordt deze ook af en toe opnieuw geconfigureerd.
De integraties die worden gerealiseerd moeten uiteraard aansluiten bij de geconfigureerde applicaties. Maar dat betekent iets voor elke her-configuratie: zodra er iets aan de parameterinstellingen wordt gewijzigd, moet worden nagegaan of die wijziging invloed kan hebben op een integratie. Zo ja, dan moet die integratie worden geïnspecteerd, eventueel opnieuw worden getest, en soms opnieuw ontworpen en gedocumenteerd. Dit geldt natuurlijk des te meer wanneer een upgrade of nieuwe versie van een pakket wordt doorgevoerd. Dat maakt integraties lastig, want zij vragen steeds weer aandacht.
In de praktijk wijken professionals en softwareleveranciers soms af van de scherpe indeling in applicatietypes. Een CRM-applicatie is meestal hoofdzakelijk transactioneel, maar kent soms stukjes documentaire eigenschappen, bijvoorbeeld t.a.v. contracten. Een ERP-applicatie is eveneens hoofdzakelijk transactioneel, maar kent soms real-time eigenschappen bijvoorbeeld t.a.v. warehousing.
Overigens kan ERP zelf ook worden opgevat als een verzameling integraties tussen transactionele systemen voor functionele gebieden in een bedrijf. Het meest extreem zijn MES-applicaties, die soms zowel transactioneel, documentair als real-time zijn. Dit betekent natuurlijk dat veel integratie problematiek binnen het pakket zal zijn opgelost, maar ook dat het implementeren nogal wat vaardigheden vraagt.
De aard van integraties tussen typen applicaties
Hieronder beschrijven wij integraties tussen typen applicaties; integraties van dezelfde typen én integraties van verschillende typen. Al deze integraties hebben één gemeenschappelijk kenmerk: integraties tussen applicaties van verschillend type vergen kennis van beide typen applicaties en van hun onderliggende technologieën en vooronderstellingen. Dit maakt zulke integraties lastiger dan integraties tussen applicaties van hetzelfde type.
Integratie van transactionele systemen
Integraties hebben vrijwel altijd een component die betrekking heeft op data. Dit is het duidelijkst bij integraties tussen transactionele systemen. Zoals we in blog 2 van deze serie kunnen zien, bestaan de data in zulke systemen uit regels in tabellen, waarbij de kolommen in die tabellen de attributen representeren. Integratie komt hier vaak neer op het afbeelden van tabellarische gegevens uit het ene systeem naar tabellarische gegevens in het andere systeem.
Een simpel voorbeeld betreft de afbeelding van de postcode in Nederlandse adressen tussen twee systemen. In het ene systeem staat de postcode uit een attribuut met zes karakters, vier cijfers gevolgd door twee letters. In het andere systeem bestaat de postcode uit twee attributen, één attribuut met vier cijfers en één attribuut met twee letters. Men kan zich eenvoudig voorstellen hoe het ene systeem de gegevens afbeeldt op de gegevens van het andere systeem. Het wordt ingewikkelder, als men bij elke afbeelding wil checken, of de combinatie van cijfers en letters wel bestaat in Nederland. Bijvoorbeeld, de postcode 9999XX bestaat niet. Het wordt nóg ingewikkelder wanneer men wil checken of de straatnaam en postcode wel bij elkaar horen en wanneer er een handmatige ingreep nodig is als deze check een inconsistentie vindt.
Dit soort integraties kan leiden tot het gebruik van bedrijfslogica (business logic) van het ene systeem door het andere systeem. Maar het betekent ook, dat er bedrijfsprocessen moeten worden gedefinieerd die het werken met integraties faciliteren. Ook dit komt in blog 2 over transactionele systemen aan de orde.
Integratie van documentaire systemen
De integratie tussen twee documentaire systemen, waarover we in blog 3 hebben geschreven, is minder makkelijk te automatiseren dan de integratie tussen twee transactionele systemen. Bij twee documentaire systemen zal de integratie vaak binnen PDM/PLM worden geregeld, en dat gaat normaliter gepaard met handmatige inspectie en soms met handmatig ingrijpen.
Documentaire en transactionele systemen
Integratie tussen documentaire systemen en transactionele systemen betekent meestal dat er een stukje tabellarische data is gedefinieerd binnen het documentaire systeem. Dit is bijvoorbeeld het geval bij stuklijsten. Integratie gaat dan technisch op min-of-meer dezelfde manier als tussen twee transactionele systemen, maar de bedrijfsprocessen vragen meer aandacht. Ook moet het “check-in/check-out” principe worden gerespecteerd, en dat vraagt aan de transactionele kant aanpassingen in de status van objecten. Hierover is ook meer te lezen in blog 3 van deze serie.
Documentaire en real-time systemen
Integratie tussen documentaire systemen en real-time systemen betekent in de fabriekspraktijk vooral CAD/CAM integratie. Het komt erop neer, dat tekeningen via een reeks transformaties worden omgezet in bewerkingsvoorschriften voor numeriek bestuurde gereedschapswerktuigen en in handelingsvoorschriften voor robots. Vaak is menselijke ondersteuning via simulaties en goedkeuringen gewenst. Hierover kun je meer lezen in blog 4.
APS
Integraties waarbij Advanced Planning Systems (APS) in het geding zijn lijken weer veel op integraties tussen transactionele systemen, zoals hierboven besproken. Echter, wanneer fundamentele datastructuur wijzigingen nodig zijn om van transactionele data te komen tot in-RAM data, dan is de integratie plotseling veel complexer. De Advanced Planning Systems zijn in blog 5 besproken.
Technologie
De meest voorkomende soort integraties wordt gevormd door integratie tussen transactionele systemen. Om data van het ene systeem te kunnen afbeelden op de datastructuur van het andere systeem is speciale software ontwikkeld. Deze wordt wel aangeduid als Enterprise Application Integration (EAI) software. Vooral in grotere bedrijven wordt van deze software gebruik gemaakt
Deze software is in de eerste plaats bedoeld om het afbeelden van data van de ene applicatie naar de andere te vergemakkelijken. Daarnaast faciliteert deze software het gebruik van bestaande bedrijfslogica (business logic) van de ene applicatie in de andere applicatie. Hiervoor is wel van belang, dat applicaties zich open stellen voor zulke uitwisseling. EAI-software verzorgt echter meer dan alleen bilaterale integraties tussen transactionele systemen: het kan er bijvoorbeeld ook voor zorgen, dat een transactie in applicatie A wordt doorgegeven aan een aantal andere applicaties B, C, D, …via een bus-architectuur.
Zoals gezegd, de meeste applicaties die worden gebruikt in productieomgevingen zijn standaardapplicaties. Vaak heeft de leverancier van deze standaardapplicaties reeds voorzieningen getroffen om integraties makkelijker te maken. Een klassieke voorziening is de API, application programming interface.
Tegenwoordig kunnen applicaties zichzelf toegankelijk maken door zgn. webservices beschikbaar te stellen, waarmee andere programma’s data kunnen ontlenen aan een applicatie. Dit ziet men in toenemende mate bij transactionele standaardprogrammatuur. Zulke webservices worden ook gebruikt door EAI-software om integraties te vergemakkelijken. Daarmee dalen de kosten van integraties, maar de noodzaak om deze te inspecteren bij her-configuratie en upgrading blijft bestaan.
Wat maakt integraties lastig?
Integraties tussen twee applicaties zijn sowieso lastig, omdat bij wijziging van één van de applicaties elke integratie met die applicatie moet worden geïnspecteerd; en leidt dit tot hernieuwd testen, of zelfs tot herontwerp van de integratie. Bovendien zijn integraties vaak verklonken met bedrijfsprocessen. Bij het (her)ontwerp van een integratie tussen twee applicaties is het van belang, om de typen applicaties in het vizier te houden. Immers, verschillende types applicaties gebruiken verschillende technologieën. En een integratie vraagt dus kennis van de betreffende technologieën. Deze integraties kennen elk hun eigen patronen.
Mobina biedt helderheid
Met deze serie van 6 blogs hopen wij meer inzicht te hebben gegeven in de complexe wereld van verschillende applicaties en de daaruit voortvloeiende integratieproblematiek. Blijft het lastig om door de bomen het bos te zien? Het maken van onderscheid tussen de typen applicaties en het bepalen van de integraties is niet altijd eenvoudig. Mobina heeft jarenlange ervaring en expertise in business consultancy en IT en wil jou hierbij graag professioneel ondersteunen. Want Mobina kent de complexiteit van business en IT in organisaties, of het nou gaat om grote projecten of organisatorische optimalisaties.
Mobina
Mastering complexity
Meer weten?
Of heb je specifieke vragen naar aanleiding van een van de 6 blogs uit de serie? Neem contact op met Mobina via insights@mobina-services.nl.
En lees onze andere blogs over het IT-landschap:
Blog 1: Een introductie in de bomen en het bos van het IT-landschap
Blog 2: Helderheid over Transactionele systemen
Blog 3: Helderheid over Documentaire systemen
