As yet another exciting cloud integration gig draws to an end, I sit here ruminating over everything that transpired over the last years in the cloud/hybrid integration space and I’ve some confessions to make.
Confession 1: Love for virtual access overrides the perks of an onsite travel
We know integration is not always cloud to cloud. More often than not, there are On-Premise systems to be dealt with. And, these systems are well within the customer’s network. VPN/Citrix/RDS and other modes of virtual access are our best friends. I love customers that make me feel “welcomed” with such means of virtual access.
Real physical access to a customer’s network e.g. insisting on a company imaged laptop or worse still, insisting on an onsite gig only to develop on a company imaged laptop because the said on-premise system can only be accessed that way is archaic. It can put off blokes of my kind a bit. But, we recover well.
Confession 2: The 3-system landscape is a dark horse in your quest to cloud-nirvana
This’s purely from my SAP experience – but, is applicable in general to most system architectures. Stick to a three system landscape. Yes, there are pros and cons. But, if you’re embarking on a large-scale cloud implementation that has plenty of integrations to cover and it’s possible to have a three system landscape, stick to it! The developer develops in the dev system, tests and releases it to the quality system. Customers perform their acceptance tests on the quality system (that mimics the Prod system in every way possible). Bugs raised during acceptance testing can be worked on by your developer in the development system independent of your testing. No tools down for anyone and the prod. system remains sacrosanct accepting only the tested and vetted code from quality. So one advise – keep your 3 tiers in shape!
Confession 3: A god mode developer is the most productive developer
During the development phase, give the developer all the rights in the system they are developing on. This can make you apprehensive, but if you don’t trust the developer, you shouldn’t be doing business with her. After all, you have your 3 tier landscape, don’t you?
And also don’t wire fence API access with Firewall restrictions too early in the project. I know this’s important to ensure user credentials don’t expire. But, it also impedes 3rd party, the likes of POSTMAN and SOAP UI, tool access to the cloud system.
Confession 4: API first integration
Integrations should be built with APIs and integrations should be callable as APIs. Integration is too vital an asset to be relegated to a behind the scene job. Real-time, event-based integration over HTTP APIs is the new norm. E.g. An employee hired on SuccessFactors can be replicated to a downstream ERP/Payroll system in near-real-time, so much so that the employee hired on SuccessFactors can be “worked” on in the downstream ERP/Payroll systems in no time. This offers business continuity and process satisfaction.
Confession 5: Stick to Standards and invest in scaffolding.
Again talking of SAP integrations. When doing SAP to SAP integrations, there’s nothing better than SAP’s Cloud Platform Integration and its standard redelivered content. Agreed, it has its own quirks – but, it’s certainly way more efficient and time tested than the .csv import that you’re probably considering.
When embarking on large scale integrations, especially custom integrations, invest in the support and scaffolding structures around the integration. Versioning, automated test cases, CI/CD pipelines, regression etc need tools beyond just excel sheets downloads/uploads. I would seriously recommend setting aside at least 10% of the overall project budget on building/buying scaffolding & support assets. FIGAF for SAP CPI is definitely worth checking out before you build one on your own.
Confession 6: Don’t fear integrations.
Integration solutions of today are increasingly catering to Citizen and Adhoc integrators. These are Business Process Experts who just want to get things. Did your candidate just send you her resume in an email and you want to push it into your recruiting system? Do you want all the tweets addressed to your company’s handle to be accumulated and sent to a sentiment analyser? Use cases like this can be tactically resolved with citizen integration tools like Cloud Elements, Zapier, Tray and the likes. Cloud Elements, for example, exposes over 200 connectors called elements and a formula builder to handle the eventing and business logic. This is really like virtual lego – pick and choose the connectors you want, write a formula, rule, recipe to put them together and voila your integration is up and running.
To conclude, every client system landscape and the environment has its own quirks, bells and whistles, all homegrown over decades. This is what makes every assignment unique and why integration is fun. It’s the same endorphin rush that you get when you open a new lego box!
