Tegenwoordig is er voor ieder business-probleem wel een applicatie voorhanden. Al dan niet uit de cloud, of voor mobiele platformen. Maar juist de integratie van al die applicaties wordt steeds belangrijker. Want bedrijfsdata die opgesloten zitten in silo's remmen de business-processen en daarmee operationele efficiëntie. Met een integratieplatform knoop je deze silo's aan elkaar. Maar waar moeten deze oplossingen aan voldoen? Vijf eisen.
1. Gebruik van In-memory Data Grid-architectuur. Een integratieoplossing moet 24/7 continuïteit garanderen. Bovendien moet het kosteneffectief opschalen zodat het groei en onverwachte pieken in gebruik kan opvangen. Een in-memory data grid-architectuur biedt deze beschikbaarheid en schaalbaarheid en is daarom essentieel. Een dergelijke architectuur verdeelt de verwerking over verschillende nodes. Valt een node uit, dan verplaatst het beheersysteem de verwerking automatisch naar een andere node. Dat voorkomt dataverlies. Ook kan het systeem nodes bijschakelen voor meer verwerkingskracht, mocht een piek in de belasting dat vereisen.
2. Ondersteuning voor iedere combinatie van on-premise en cloud. Tegenwoordig gebruiken organisaties een keur aan cloudgebaseerde oplossingen. Vaak nemen ze die af op basis van korte-termijncontracten en ook wisselen ze nogal eens van aanbieder. Dat maakt het handmatig programmeren en onderhouden van al die koppelingen een lastige klus. Applicatieplatforms nemen die koppelingsproblematiek uit handen en zorgen er achter de schermen voor dat alles netjes blijft werken, inclusief automatische documentatie. Dat bespaart bovendien gedoe en kosten wanneer organisaties van tools wisselen. Zorg er ook voor dat het integratieplatform geoptimaliseerd is voor het verbinden van cloudomgevingen met andere systemen, services en databases, waar deze zich ook bevinden.
3. Realtime beschikbaarheid van data. Businessdata is het meest waardevol wanneer het in real-time wordt gemeten, geanalyseerd en opgevolgd. Het volume en snelheid ervan nemen hand over hand toe, het managen ervan is dan ook een lastige uitdaging. In-memory data grids zijn ideaal voor real-time dataverwerking. Het kan meerdere taken tegelijkertijd afhandelen, wat zorgt voor snelle toegang tot informatie. Het is bovendien onafhankelijk van de dataverwerking van welk ander derde systeem dan ook. Applicaties die draaien op een in-memory data grid kunnen daarom gemakkelijk realtime data verwerken en presenteren.
4. Datamobiliteit tussen verschillende apparaten en besturingssystemen. Het moeilijkste van de ontwikkeling van mobiele enterprise-apps is de connectie met backend-processen. Een workflow-gebaseerd applicatieplatform kan business-processen gemakkelijk mobiliseren, in tegenstelling tot een puur data-georiënteerde oplossing. Voor een efficiënte ontwikkeling van een app is het belangrijk dat een integratieplatform naadloos samenwerkt met een multichannel app-ontwikkelplatform. Met een dergelijk ontwikkelplatform kunnen developers apps bouwen waarbij het uiterlijk zich aanpast aan het device, zoals Apple- of Android-smartphones, tablets of de desktop.
5. Ondersteuning van huidige backend-systemen. Geen enkele integratieoplossing kan bestaan in een vacuüm. Per definitie ligt de waarde ervan in de ondersteuning van een brede reeks aan backend-systemen. Zorg dan ook dat de vendor van de gekozen integratieoplossing sterke banden heeft met de vendoren van de huidige belangrijke it-systemen, het liefst uitgedrukt in officiële certificeringen. Die moeten een probleemloze werking met de huidige oplossingen garanderen. Bovendien is dan support gegarandeerd.
Conclusie
Een integratieplatform zorgt voor een gestandaardiseerd, snel en eenvoudig ontwikkelproces en koppeling met een brede range cloud- en backend-systemen. Zo’n platform moet wel over langere tijd zijn waarde behouden, voor een hoge roi. Kies dan ook verstandig en zorg dat het aan hierboven beschreven eisen voldoet.
Integratie platform zonder het woordje Webservices en IAM te noemen?
Dan even kort door de bocht mijn gedachten bij de vijf genoemde punten:
1. Gebruik van In-memory Data Grid-architectuur.
Waarom een eis? Leuk? sure, handig? vast wel, maar eis? Waarom dan? Staat los van wegvallende nodes.
2. Ondersteuning voor iedere combinatie van on-premise en cloud.
Ik voor vooral over het woordje “iedere”. Dat is hetzelfde als software ontwikkelen die op alle database kan landen. Wat overblijft is een jack of all trades and master of none. Je kunt niet EN sterk zijn EN overal op aan kunnen sluiten. Ergens moet de prijs betaald worden.
3. Realtime beschikbaarheid van data.
Ook dit als eis stellen is gewoon niet goed. Tegen welke prijs? Realtime is gewoon niet altijd nodig, dus waarom dan deze restrictie als eis opnemen?
4. Datamobiliteit tussen verschillende apparaten en besturingssystemen.
zeker: Webservices en IAM.
5. Ondersteuning van huidige backend-systemen.
Nee. Als je je hierop gaat richten ben je al hard op weg legacy te creëren. Hier geldt in mijn opinie: Choose your battles. Voor acceptatie zul je met sommige back-end systemen moeten communiceren, bijvoorbeeld Active Directory.
Uiteindelijk moet je niet alles technisch op willen lossen, want dat komt met een prijs. Kijk naar welke producten toekomst hebben en welke aan het einde van hun life-cycle terecht zijn gekomen. Door alles te willen mis je focus en dus kracht. Beter een aantal zaken heel goed, dan veel zaken matig….
@Henri
Hij verkoopt iets duurs met “In-memory Data Grid-architectuur” enzo, niet iets met Webservices en IAM. Daarom noemt die ze niet.
Auteur lijkt hier vooral een bewijs te geven voor de wet van Wirth – software wordt recht evenredig inefficiënt als snelheid van de infrastructuur toeneemt. Idee van een in-memory datagrid is leuk maar als dit een noodzaak is voor een ‘magic strings’ integratie dan is het naar mijn opinie verre van efficiënt. Aangaande de bewering realtime beschikbaarheid in een data grid heb ik wel enige vragen, data mobiliteit vergt heel wat van het netwerk.
“Een workflow-gebaseerd applicatieplatform kan business-processen gemakkelijk mobiliseren, in tegenstelling tot een puur data-georiënteerde oplossing.”
Euh… waar had ik dat ook alweer eerder gehoord?
@Henri
Webservices zijn leuk maar ze hebben ook een eigenschap van inefficiëntie, je gaat dus van boven naar beneden door de stack en vice versa. Voeg daar transactionele IAM aan toe en je hebt een oplossing die zo traag is als dikke stront door een dunne trechter. En dan zal ik nog maar niets zeggen over onevenredige zware resource belastingen.
Aangaande opmerking over legacy is het alleen voor migratie al handig als je een koppeling hebt, je verhaal over toekomst raakt kant noch wal. Het is namelijk kapitaal vernietiging om telkens met elke hype mee te gaan. Overwegend dat een groot deel van de software in de back-end nog batch georiënteerd is – en geen AD ondersteund – dan ligt hier het probleem.
Het zoveelste laagje over de silo’s heen leggen lost dus niets op maar verergerd probleem alleen maar, nog meer ongestructureerde data die alleen maar zoek raakt.
Mag ik als ik het artikel lees, en de reakties, samenvatten dat het vak ICT nog steeds onvolwassen is?
Wie naar integratie zoekt kan eens kijken bij Pentaho of Talend.
De behoefte naar integratie is er zeker gezien de groei van dit soort platformen. Niet vergeten, “de keten” is zo sterk als de zwakste schakel, geintje.
De behoefte aan integratie is enorm groot en groeit, juist omdat men naast monolithische systemen steeds meer tools over het internet adopteert (cloud) is de vraag naar integratie overweldigend.
Met name het anderhalf jaar zijn er door een aantal ontwikkelingen meer mogelijkheden die ook nog eens door korte iteraties steeds bruikbaarder en gebruiksvriendelijker geworden en wordt integratie technisch gezien minder complex en dat is met name gedreven door webservices, ongeacht wat Ewout hierover roept.
Ja het komt met een performance prijs, maar deze is gewoon te mitigeren en er zijn bovendien nauwelijks alternatieven.
De grootste uitdaging blijft de organisatorische kant. Welke methode / framework + tools zou je moeten gebruiken om dit goed te doen? De killer methode heb ik nog niet ontdekt om goede governance over je integratie te voeren. Dus voor nu zijn dit de juiste mensen met de juiste competenties.
@Henri
ook goede tools,en die zijn er heus wel, moeten door competente mensen worden gehanteerd
@Jan
Er zijn meer goede tools dan de door jou gememoreerde open source oplossingen, ook binnen de enterprise software zijn er goede.
@Ewout
Ik raad je aan eens naar de inrichting van de Google infrastructuur te kijken, volledig gebaseerd op IMDG en je kunt naar mijn mening niet zeggen dat Google een lage performance heeft.
@Felix
Ik heb dit artikel niet geschreven om iets te verkopen, maar om iets onder de aandacht te brengen. Ik zie teveel ‘goedkope’ peer to peer en open source oplossingen die eigenlijk helemaal niets gekost zouden mogen hebben vanwege de abominabele kwaliteit. En webservices en IAM zijn communicatie methoden, dat die worden gehanteerd gaan we vanuit, de echte uitdaging voor een goede integratie wordt uitgedrukt in een meerwaarde voor de business.
en lest best @ Henri
de andere oplossing is een ‘broker/requester’ mechanisme met daarachter een full en realtime failover, dat is vele malen duurder dan de IMDG oplossingen van tegenwoordig.
Iedere combinatie van on premis en cloud is belangrijk en haalbaar, wat ik zie is dat SAP R3 gebruikers data in huis willen houden en toch bv van SFDC gebruik willen maken, en dan volledig realtime geintegreerd met elkaar, in de ervaringen die ik ermee heb zijn er niet veel integratiesystemen die dat verzorgen.
Niet iedere synchronisatie van informatie hoeft real time te zijn, klopt, maar daar waar het meerwaarde levert, door bv binnen SAP R3 middels idocs te communiceren, zijn bedrijven gaarne bereid zich hiervoor inspanningen te getroosten. Te denken val aan cross platform systemen waarbij mobiel orders kunnen worden geaccepteerd en bevestigd, in casu de effectenhandel en/of valuta arbitrage.
Communiceren kan op vele wijzen, informatie dient te worden beschermd, binnen de integratiewereld zijn we inmiddels zover dat we daar sine qua non van uit gaan.
Backend systemen zijn veelal heel duur geweest en vervat in de cultuur van de ondernemeing; een nieuw ERP systeem is vergelijkbaar met een harttransplantatie. Ik kan me voorstellen dat bedrijven hier toch erg voorzichtig mee zijn. Indien je derhalve een legacy systeem kunt versterken door ‘het laagje erboven’ dat de gewijzigde informatiebehoeften van een onderneming het meeleven met de markt kan opvangen, weet ik dat veel bedrijven hiervoor zullen gaan.
Groeten
John Verwaaijen
De schrijver van dit artikel
@John (auteur van het artikel)
Een nogal abject uitspraak aangaande open source, veel commerciële oplossingen zijn tenslotte op dezelfde code gebaseerd. Wet van Wirth is trouwens een economische welke dus gebaseerd is op een lineariteit van kosten tussen de functionaliteit en prestatie. En het laagje erboven op is dus precies wat ik bedoelde met de opmerking dat ik verhaal al eerder gehoord had, ergens in de vorige eeuw toen ABAP en ESB populair waren maar welke nu voor een ’technology debt’ zorgt.
Rendement (ROI) van menig ERP systeem is dan ook veel lager dan initieel beloofd, Gartner stelt zelfs dat veel organisaties nu de boete betalen voor het stapelen van oplossingen. Uiteraard is een harttransplantatie van volledige ERP vervanging risicovol maar je opmerking aangaande back-end systemen is door de wet van Moore achterhaald. Niet geheel ontoevallig hebben we een platform dat geen harttransplantatie doet maar een bypass welke niet alleen de data sneller laat stromen maar ook de kosten doet dalen. Oudere software heeft nu eenmaal weinig baat bij een multi-core systeem maar haalt dus wel voordeel uit snellere I/O bussen als gevolg van de exponentiële groei datagroei.
En dit geldt dus met name als je over IDoc gaat praten want dat is net als XML een protocol bovenop een andere (communicatie)laag waarbij naar ik meen de beveiliging dus nog toegevoegd moet worden. Consolideer je fysiek logisch gescheiden componenten dan haal je direct de vertraging van het netwerk eruit en versla je Google op prestatie, kosten en beveiliging. Blijf je binnen de ‘bouwsteen’ van het grid dan is er momenteel nog niets sneller dan de Northbridge (in-memory connect) en ga je buiten de ‘bouwsteen’ dan verslaat Infiniband via de Southbridge elke WAN verbinding voor zowel de latency als bandbreedte. Oplossing is gebaseerd op het idee van LPAR middels hardware partioning voor generieke Intel architectuur waarbij ook de in-memory communicatie versleuteld wordt, iets waar Google nog wat te verbeteren heeft.
http://www.slideshare.net/edekkinga/forward-unisys
Als je me dus wat over architectuur wilt vertellen binnen data grids is het misschien handig als je ook de fysieke aspecten meeneemt, de in-memory caching van data is vaak een pleister die dan ook nogal wat nadelen heeft welke niet alleen impact heeft op de kosten maar ook de functionaliteit en integriteit van een systeem. De zoveelste applicatieserver toevoegen aan het ERP landschap is dan ook alleen maar het probleem voor je uit schuiven, een ontkenning van de feiten welke dus steeds zwaarder op het budget drukken. Back-end systemen zijn namelijk goedkoper dan de front-end systemen als je alle kosten gedurende de gehele looptijd meeneemt als gevolg van de verschuiving naar software. En aangezien de marges hierop 40 maal hoger is dan op hardware dan is de verschuiving naar de cloud ook niet zo moeilijk meer te begrijpen.
@Ewout
wellicht eens onder het genot van een kop koffie en een koekje bespreken; de redactie heeft mijn email adres 🙂