Hoe gebruikelijk is de inzet van middleware?

[bakmeel]

Hallo Tweakers,

Voor mijn werkgever ben ik verantwoordelijk voor het operationele onderhoud van onze Salesforce Service Cloud met ongeveer 50 actieve gebruikers. Voor het service proces hebben we nu een goede, maar dure interface gebouwd met ons ERP pakket, SAP Business By Design. De interface is nu namelijk maatwerk in het Salesforce systeem.

Mijn werkgever wil verder groeien en verdere integratie is -zo zegt hij- wenselijk om meer processen in de organisatie te automatiseren. In de roadmap die ik heb voorgesteld wil ik Jitterbit Harmony data integratie (een SaaS middleware platform) gaan gebruiken om de diverse business applicaties die we hier gebruiken aan elkaar te knopen.
Omdat we in onze organisatie geen developers hebben, moet ik voor elk stukje code en het onderhoud eraan een externe ontwikkelaar inhuren.

Maar ik stuit op weerstand. Niet alleen door het stevige kostenplaatje (welke volgens mij te verantwoorden is) maar ook door onbegrip en onbekendheid. Men heeft moeite om de toegevoegde waarde te zien, en hoe het moet helpen in de ontwikkeling van de business. Want ook al bespaar ik mezelf een flinke hoeveelheid code, data integratie is voor ons een complex onderwerp en het onderhoud van alle interfaces is onbekend gebied voor ons.

Ik ben op zoek naar referentiemateriaal, en dan natuurlijk niet de toch al rooskleurige sales pitch van Jitterbit zelf. Hoe "gebruikelijk" is het om data integratie te realiseren met behulp van middleware? Wie gebruikt het al en wat zijn jullie ervaringen? Waar loop je tegenaan in het gebruik en wat zijn de lessons learnt?

Ik hoop dat ik de vraag zo goed gesteld heb. Jullie ervaringen worden op prijs gesteld

[ Voor 0% gewijzigd door bakmeel op 06-09-2018 11:38 . Reden: typo ]

[Harrie_]

Ervaring met SAP ERP en Salesforce; integratie natuurlijk belabberd. Dit hebben we opgelost om vanuit Salesforce over te stappen naar SAP CRM Cloud. Is dat geen optie? Dat je 'vastzit' aan SAP is op zich niet geheel onlogisch, maar waarom de wens om CRM-activiteiten middels Salesforce te blijven doen? Als SAP CRM geen oplossing is dan zijn er nog tig andere CRM-pakketten die redelijk plug- en play op SAP aan te knopen zijn...

[Merethil]

Ik ben zelf integration consultant en ken talloze bedrijven die exact hetzelfde probleem tegenkwamen en gewoon aan de slag gingen met een integratie-pakket. Salesforce heeft trouwens net Mulesoft overgenomen, wat een prima pakket is om integratie mee te doen.

Aangaande Jitterbit, ik had er nog nooit van gehoord. Zelf gebruiken wij webMethods van Software AG, onder andere om bij klanten Salesforce en hun andere applicaties aan elkaar te knopen, als backend server voor talloze websites en ook om met SAP te interfacen (zowel IDOC-verkeer als functiecalls in SAP zelf).

Voor zover ik weet komt dit op heel veel plaatsen voor, maar er is weinig informatie op het internet over wie welke tools gebruikt en waarvoor, dus zien welke grotere bedrijven welke middleware-oplossingen gebruiken is lastig denk ik.

[bakmeel]

Merethil schreef op donderdag 6 september 2018 @ 13:14:
(...)
Voor zover ik weet komt dit op heel veel plaatsen voor, maar er is weinig informatie op het internet over wie welke tools gebruikt en waarvoor, dus zien welke grotere bedrijven welke middleware-oplossingen gebruiken is lastig denk ik.

Dat bevestigt in ieder geval mijn observatie dat er weinig te vinden is over de "best practice" in dit veld. Maar gelukkig ben ik dus geen eenzame kruisvaarder met een eigen doel :-)

[Gerco]

Ik ben ook integration consultant en werk dagelijks met diverse smaken middleware. Ik heb ook nog nooit van Jitterbit gehoord. Wel van Sonic ESB, Webmethods, Interlok en Mulesoft en ik kan het aanraden om daar eens naar te kijken (sommigen hebben een evaluatieversie of zijn zelfs open source of gratis). Middleware is geen oplossing voor alle problemen, maar kan wel een hoop werk uit handen nemen.

Ik zie het meest grote bedrijven voor wie een €25k licentie wisselgeld is en die geld hebben om consultants in te huren voor meerdere maanden full time on site. Als een kleiner bedrijf zal het misschien minder makkelijk zijn om dat te integreren zonder een developer in dienst te hebben, maar het is wel een stuk makkelijker op te pakken voor iemand die *geen* developer is, dus misschien kun je een groot deel zelf doen in plaats van iemand in te huren.

Disclaimer: Ik heb gewerkt bij Progress Software (Sonic ESB), Software AG (Webmethods) en nu bij Adaptris (Interlok)

[Merethil]

Gerco schreef op donderdag 6 september 2018 @ 15:38:
Als een kleiner bedrijf zal het misschien minder makkelijk zijn om dat te integreren zonder een developer in dienst te hebben, maar het is wel een stuk makkelijker op te pakken voor iemand die *geen* developer is, dus misschien kun je een groot deel zelf doen in plaats van iemand in te huren[/small]

Hier ben ik het deels mee eens maar ik heb ook genoeg bedrijven gezien waar zaken totaal niet schaalbaar zijn opgezet, of dat de middleware één grote warboel wordt...

Ik moet wel zeggen dat als je weinig echt intensieve zaken gaat doen en misschien alleen wat data van A naar B en terug wil transformeren/transporteren, dan kan je best uit de voeten met een community versie van Mulesoft en zelf wat aanmodderen, maar alles daarboven is toch wel wat te hoog gegrepen vaak.
Dit vooral omdat je ook nog eens én de domeinkennis nodig hebt, én de intrinsieke werking van de middleware-oplossing, én weten hoe je een schaalbaar landschap bouwt. Als je dan ook nog eens de boel moet onderhouden en wat monitoring wil doen dan heb je vaak niet genoeg aan zelf wat zaken bouwen, alleen al omdat het gewoon heel veel tijd kan kosten als je dit allemaal nog nooit hebt gedaan.

Bij ons zetten we voor dit soort zaken vaak zelfgemaakte packages in bij elke klant, welke we over de jaren heen ontwikkeld hebben om zo customizable, schaalbaar en gebruiksvriendelijk mogelijk te zijn. Die kennis heb je niet als je net begint en vaak wordt alles bij elkaar al snel teveel waardoor je alleen maar eerder tegen die grens van onbegrip aanloopt bij de overige collega's die het nut van de middleware niet snappen.

[bakmeel]

Ik had al een keer eerder geprobeerd om middleware in te zetten maar destijds was het aan elkaar knopen van twee endpoints inderdaad een te dunne case om de licentiekosten van middleware te verantwoorden. Ik denk zelf nu dat we er wel aan toe zijn :-) Er komen meer applicaties in het landschap en ik zie vanachter mijn eigen bureau dat die data-silo's een recept zijn voor overbodig werk. Het is echter precies dat kennisterrein waar ik zelf tegenaan zit te kijken. Tot op heden heb ik steeds in mijn eentje de interface bijgehouden in samenwerking met de developer van onze Salesforce consultants. Als ik (of mijn werkgever) wil voorkomen dat we continu consultants moeten inhuren zal die kennis dus in huis moeten komen.

Tot op heden ben ik zelf altijd verantwoordelijk geweest voor het onderhoud van onze Salesforce org, inclusief de integratie er naartoe (ik ben / was certified Salesforce Advanced Admin).
Daarom komen de middlewarepartijen die ik in de business case meeneem ook uit die hoek. MuleSoft heb ik inderdaad ook gesproken. Prachtig systeem en ik denk dat zij extreem performant kunnen zijn bij grote volumes data en enterprise-wide integraties. ScribeSoft (komt uit de Microsoft hoek) was super goedkoop maar alleen in staat om op basis van schedulers te werken en had moeite met SOAP.
Jitterbit is een UK club en is groot geworden met het Salesforce platform. Zij ondersteunen schedulers en trigger-based integraties die je haast point-and-click in elkaar kan sleutelen. Ik had al enige ervaring met hun product omdat ze een gratis Salesforce Data Loader leveren die goed werkt.

Wat ik tot zover van @Merethil en @Gerco heb geleerd is dat middleware niet geheel (of geheel niet) ongebruikelijk is, en dat steunt de case. Wel is het noodzakelijk om goed te kijken naar het onderhoud. Dat is per definitie kennis-intensief en middleware verandert daar niets aan. Afhankelijk van het integratieplatform dat je gebruikt kan je het wel makkelijker maken...

PS eigenbelang speelt hier natuurlijk ook een rol. 1 keer raden wie die middleware mag gaan onderhouden ;-)

[Merethil]

bakmeel schreef op vrijdag 7 september 2018 @ 10:48:

PS eigenbelang speelt hier natuurlijk ook een rol. 1 keer raden wie die middleware mag gaan onderhouden ;-)

Dit is de reden dat er (grote) clubs zijn die dit volledig uit handen kunnen nemen. Zelf doen we hier consultancy maar hebben we ook onze eigen implementatie van de ESB-oplossing klaarstaan voor (kleinere) bedrijven die liever geen development of onderhoud willen doen en daar gewoon voor betalen. Dan doen wij development, support en onderhoud (inclusief het up-to-date houden van alle software). Dat draait dan op AWS dus de klant hoeft zelfs geen ijzer te leveren.

Uiteindelijk komt het bij Middleware vaak neer op hoeveel geld je wil neerleggen als bedrijf. Ja, het kan prijzig zijn, maar het is uiteindelijk het systeem met de hoogste uptime-eisen, grootste hoeveelheid data die erover loopt en dus ook de belangrijkste factor wordt. Dat is het niet vanaf dag één, maar zodra men leert hoe makkelijk op die manier software A met software B kan werken, of product X aan leverancier Y gekoppeld kan worden, gebeurt het vaak dat opeens álles aan datatransport over de Middleware moet gaan.

Laat ik je vast vertellen dat als jij de enige bent die het gaat onderhouden je waarschijnlijk toch beter af bent met wat scripts en CRON-scheduled jobs om data heen en weer te pompen, een heel Middleware platform is vaak best arbeidsintensief om op te zetten, waarna je het onderhoud goed moet doen omdat een flink deel van je data er opeens overheen loopt. Ik wens je veel succes met de uitdaging, Middleware ligt niet iedereen maar ik vind het geweldig

[downtime]

Merethil schreef op vrijdag 7 september 2018 @ 11:19:
[...]

Dat is het niet vanaf dag één, maar zodra men leert hoe makkelijk op die manier software A met software B kan werken, of product X aan leverancier Y gekoppeld kan worden, gebeurt het vaak dat opeens álles aan datatransport over de Middleware moet gaan.

De fase waarin ze overmoedig worden, omdat het zo mooi en zo gemakkelijk lijkt, en het verandert in die ene hamer waarmee elk probleem opgelost kan worden. Dat is net voordat de boel onder zijn eigen gewicht instort en men gedwongen wordt tot herbezinning.

[Merethil]

downtime schreef op vrijdag 7 september 2018 @ 12:46:
[...]

De fase waarin ze overmoedig worden, omdat het zo mooi en zo gemakkelijk lijkt, en het verandert in die ene hamer waarmee elk probleem opgelost kan worden. Dat is net voordat de boel onder zijn eigen gewicht instort en men gedwongen wordt tot herbezinning.

Dát ligt een beetje aan hoe het opgezet wordt natuurlijk. Natuurlijk moet er rekening gehouden worden dat niet álles over de Middleware gaat als het niet nuttig is (een batch-jobje afschoppen op een systeem dat juist geschikt is voor een hoge hoeveelheid kleine berichten verwerken is nogal zonde), maar in veel gevallen heb je ook daar je consultants voor. Die kunnen aangeven wat wel en niet binnen de grenzen van het platform ligt.

En zelfs dan, veel middleware-oplossingen kunnen prima horizontaal schalen en derhalve alsnog de oplossing zijn voor het probleem, zelfs als ze er totaal niet voor geschikt of geoptimaliseerd zijn. Dan wordt het echter een kwestie van hoeveel geld men er tegenaan wil gooien