#HRTechChat Showcase: Original Zen and the Art of Integration Strategy

Some may appreciate the play on the title of a mid-1970s philosophical novel, “Zen and the Art of Motorcycle Maintenance,” others the Eastern twist on Western theology. Regardless, original Zen and the art of integration strategy is the absolutely essential and crucial understanding that cloud-to-cloud integration is a process and a way of life, never something that eventually ends because it will ever finally be perfect. Vendors in HCM that acknowledge and embrace this universal truth will save money, increase sales, and improve their customer retention — all major competitive advantages.

This episode of the video podcast is something we call the #HRTechChat Showcase, a version of #HRTechChat wherein our guests not only chat with us, but also share slide decks or other visual cues to help convey their ideas. So, if you’re listening to us on one of the audio platforms where we syndicate, this time you may want to look for us on YouTube so you can view the video.

My guests were all-around experts in the granularities of cloud integration: Chief Technology Officer Jeff Tremblay and President Pierre Rousseau of The Cloud Connectors, an integration platform-as-a-service (iPaaS) where they and their fellow co-founders invented and use Clouddata™, a native-to-cloud-integrations computer language.

Listening to vendors of software-as-a-service (SaaS) for human capital management (or any other domain of the enterprise, for that matter), a buyer might be forgiven to believe solution providers have solved cloud-to-cloud integration once and for all with application programming interfaces (APIs). But they haven’t — far from it. An HCM technology stack chockful of countless APIs hanging together via no more than a slew of corresponding point-to-point integrations is, as the cliché goes, a recipe for disaster. Vendors experience what TCC calls the Wall Effect, a hockey-stick graph where the cost of integration (TCoI) for maintaining everything suddenly increases exponentially to sap resources and siphon talent away from innovating. The challenges comprise far more than what appears above the waterline of the Integration Iceberg, an apt metaphor TCC invokes.

To use another cliché, Clouddata is a game-changer. To pull from the related research note that we recently published, “Clouddata does for integrations what SQL has done for relational databases. Much like SQL delivered relational database coding from the very complex language CODASYL, Clouddata fulfills the same role for integrations. Clouddata makes it easy to build complex integrations that enable businesses to scale.”

There’s more, of course. Critical as Clouddata is, it takes more than a breakthrough in computer language to make cloud-to-cloud integration better, more manageable and affordable over the long term. And there’s even more, and at this point, I really should just let Pierre and Jeff do the explaining.

I happen to like the concept of #HRTechChat Showcase, by the way. Perhaps you’ve wondered at times what a briefing with an industry analyst is like, for example. Or, you just like seeing slide decks or other props when learning something new. Some don’t like PowerPoint, but we’ve all seen their impact and effectiveness elevate immeasurably when the caliber of presenter is really good. And, in Jeff and Pierre, we have really good, high-caliber presenters for this episode, indeed.

Our #HRTechChat Series is also available as a podcast on the following platforms:

Apple iTunes: https://podcasts.apple.com/us/podcast/3sixty-insights/id1555291436?itsct=podcast_box&itscg=30200
Spotify: https://open.spotify.com/show/0eZJI1FqM3joDA8uLc05zz
Stitcher: https://www.stitcher.com/show/3sixty-insights
SoundCloud: https://soundcloud.com/user-965220588
YouTube: https://www.youtube.com/channel/UC6aDtrRPYoCIrnkeOYZRpAQ/
iHeartRadio: https://www.iheart.com/podcast/269-3sixty-insights-78293678/
Google Podcast: https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5zb3VuZGNsb3VkLmNvbS91c2Vycy9zb3VuZGNsb3VkOnVzZXJzOjkyNDY0ODI1OS9zb3VuZHMucnNz
Amazon Music & Audible: https://music.amazon.com/podcasts/7e7d809b-cb6c-4160-bacf-d0bb90e22f7c
PlayerFM: https://player.fm/series/3sixty-insights
Instagram: https://www.instagram.com/3sixtyinsights/
Pocket Casts: https://pca.st/iaopd0r7
blubrry: https://blubrry.com/1460785/
Castbox: https://castbox.fm/channel/id4113025
ivoox: https://www.ivoox.com/en/perfil-3sixty-insights_a8_listener_25914379_1.html
Podchaser: https://www.podchaser.com/podcasts/3sixty-insights-1718242
Pocket Cast: https://pca.st/iaopd0r7
Deezer: https://www.deezer.com/us/show/3029712
Pandora: https://www.pandora.com/podcast/3sixty-insights/PC:1000613511
Listen Notes: https://www.listennotes.com/podcasts/3sixty-insights-3sixty-insights-DgeU6AW42hn/
PodBean: https://www.podbean.com/podcast-detail/9nugf-1e0a27/3Sixty-Insights-Podcast
Podchaser: https://www.podchaser.com/podcasts/3sixty-insights-1718242
Podcast Addict: https://podcastaddict.com/podcast/3sixty-insights/3319198
Tune In: https://tunein.com/podcasts/Business–Economics-Podcasts/3Sixty-Insights-TechChat-p1529087/

See a service missing that you use? Let our team know by emailing research@3SixtyInsights.com.


Brent Skinner 00:00
Well, hello, everybody, and welcome to this the latest episode of the #HRTechChat video podcast. And with me today, I have two of the co-founders of the Cloud Connectors, Pierre Rousseau and Jeff Tremblay. Welcome to you both. I’m really excited about today’s conversation where we’re going to be talking about integration in the cloud, how it’s not like it used to be. And there’s a lot to think about. We’ve all had some conversations offline, the three of us and others on your team learned a lot about this over the past several months, we’re actually coming out with a research report, not too many weeks, and it should be alive soon. And but we wanted to just give people an opportunity to sort of see this from your perspective. We have an iceberg here on the screen, Jeff, I can already kind of imagine the metaphor here. I’m thinking of the Titanic and what happened there. What’s going on here with integration today?

Jeff Tremblay 01:10
Yeah, so what we’re trying to represent here is the kind of the problem of integration and how, especially in the enterprise world, where even though technically yes, we can create, you can create integration. And yes, you can adapt it for customers. But what happens over time is trying to standardize this, if you would, the traditional approach is, vendors create this hybrid iceberg, if they’re trying to customize every customers, what they end up with is, every customer has this line of code as you deploy and multiply customers in the cloud, you end up with this iceberg, which, and the portion that you see is an integration offering any API’s and it looks all nice, but under the hood is as you’ve deployed and implemented. So many of them, you end up with what you don’t see, which is, you know, one line of code for customers. And if anything, if you need to move the iceberg and API change, something happened in the, in the environment where you need to change for everybody. Well, you have to move what’s underneath, basically. So this is what we’re trying to represent here.

Brent Skinner 02:21
Yeah, that’s pretty easy. In you know, that, then, that iceberg does look pretty nice for an iceberg above the water anyway. There’s, it looks pretty ugly underneath. It can be tough. You mentioned sort of the API’s and all that I understand that. It’s so just people who are watching a lot of folks and may have dealt with this in the past, and when they’re dealing with vendors in the space and having to sort of connect to different systems that we hear about Point to Point API connections, the sorts of things and sort of, I hate to call it a one and done approach to integration that happens at the beginning. And there’s a lot that can go wrong there. Ken, can you maybe share with us a little bit of around that?

Jeff Tremblay 03:11
Yeah, for sure. There’s, you know, first, there’s just there’s kind of a myth with integration, it’s been a problem for so long, probably for, you know, over 20 years or so. Or as long as I’ve been in the industry, at least there was a problem. And it was, the problem definitely evolved from being the pure basic of being able to exchange data, right? If you go back like 20 years ago, before API’s to exchange data, you had secure file transfer server, and you were doing this from file. But really, any integration had to occur in parallel in this parallel world of what the evolution of the stack of the product were evolving. So you had, you know, direct SQL injections are you were consuming flat file and injecting in your system and or exporting. So for integration, you were using reporting to export basically an in like, bulk import and before API’s app, and so it was impossible to evolve product with at the same time as integration offering. So that was kind of the old way, and it was ugly. And when epi occurred, everybody says that is it, you know, there was kind of a lot of publicity to say the integration problem has been solved, and we’re done with it. And, and you know, that’s now we can exchange data, and it’s done. So itself. So people said, Finally, let’s talk about something else. Reality is, even today, it’s still the number one problem in the HR tech industry, where when you try to build your stack, it’s still not solved. So why is it not solved? And it’s, we try to usually I try to explain this to SQL, right? That’s the same thing as exchanging database. So you have system which is AP data model, and they each have their API offering and sometimes just changing one field in the integration say I’d like to I Customize my application, here’s my user defined field just had that two, then integration. That seems simple enough. But for that, that might be a different API call. Right? So that’s it. So that’s how you end up with this custom code for the specific customer. Plus the on top of that, you know, even though it can mean one more API, but also is between each of the integration is ETL. Right, extract, transform and load. Because there’s no language, that’s simple feel that you’re trying to change can have an impact on extracting it a different API call, no, you need to transform it for your destination systems, I need to transform. And there’s even though I’m adding an extra field, I need to add code to transform it plus, finally, and that the destination might have an impact. So you have any changes of impacts along the way that can apply and create, you know, this this multiple effect. And then you went, That’s kind of how you build your iceberg. So I hope that was clear. But that’s in a nutshell, that’s kind of the problem that we’re trying to solve and how iceberg keeps getting built. Why, right now, in the enterprise world, as soon as you try to adjust your integration for each customers, sometimes it can have just long, long impacts.

Pierre Rousseau 06:21
And the iceberg doesn’t melt as you add client, it just grows and grows and grows. Right.

Brent Skinner 06:28
I’m so glad you brought that up here. Because I was just thinking something like, I don’t know, if you read my mind, or I read yours, but whichever way it’s good, because I was thinking about, because as you were, as you were talking, Jeff was saying, Okay, how, how does a starting to think about icebergs, like actual icebergs and how they get bigger and bigger, and they know, they just keep accumulating, you know, frozen water, the water just keeps freezing underneath until, and that’s that every single API connection that an organization takes on is another sort of frozen layer, making the iceberg even bigger. And, and, you know, when you’re describing sort of the old way of, of making the making a connection work, right, that it was almost exhausting to think about, right? Because there’s so much that needs to go, right, there’s so much that just has to be you have to babysit along the way and it can be I imagine it can just be absolutely an absolute nightmare for some organizations if they have a particularly busy HCM technology stacks now, now I know you’re both from you both are x to layo. And I’d love to hear the story because a little birdie told me that this was kind of like the origins of where this is your aha moment? Where you really thought okay, yes, this is what needs to get done.

Pierre Rousseau 08:02
Sp first of all, you’re spot on? Yes, we’re from Toledo. And, and I was from the services side. And Jeff was from product. And we were both working in a great organization that as you know, that hundreds of 1000s of customers, the problem being that I felt at that point, I always felt, why are we only caring about our side of the fence? Right? We didn’t know what the other softwares were doing, which hrs and so on so forth. We only cared about what Twilio needed, right? So there was this wall. And then we were on this side of the fence. And we were just looking at the Twilio integrations. And the very few that we ever asked that ever happened to we knew what was happening on the other side. It was just like kind of magic, right? So that led to our vision. When we started file connectors, we said no, we’re not going to be caring about our side of the fence, we’re going to be looking at the vast realm of HR. And it’s better to see it from end to end. And that was vision since they want so build a software that’s going to be able to address all of these problems, and A to Z, right. So you have a unified way of looking at the transactions, and you see it present. And so that was a vision since they won. And that was based on Yes, great to experience, but not optimal. And that’s where we came in. And that’s where we are today.

Brent Skinner 09:31
Yeah, yes. This might be a good segue. Because there’s, from what I understand that was sort of the impetus for this development of, of a of a easily accessible, understandable language for API integration cloud data, which you guys have invented. Now, there’s a really good analogy that you guys do a much better job of describing than I do now. Uh, with sort of SQL and how SQL was, was a godsend back in the day for spreadsheet integration.

Jeff Tremblay 10:09
Yeah, so the impaired described it well. So you know, definitely back in the day, each vendor and I guess that’s still true today, I mean, most vendor tried to solve integration by looking at their own little RAM then create offerings based on who so and that’s, that’s still what, what’s happening today. So you have vendor and you create solution? Did you try to create little bubbles to isolate your problem? And second, trying to solve assessments background check, and here’s my offering with some flexibility and all that which, that’s a topic for another time, I guess, are out to solve this. But are we even at teleo, we definitely lived in where the product evolved by acquisition of Oracle tried to grew from one you know, more recruiting into fuel talent management’s based, a product evolve, integration offering had to evolve. And we had to migrate customers from old Ghana systems to the other end, it was such an impact. So definitely, when we founded the cloud connectors, okay, we want to solve the problem from A to Z plus that strike to solve that, kind of, you know, what’s missing in integration? What is missing to make this a flexible, so I don’t try to solve it, like the industry tries to solve it right now, which is, okay, I’m gonna look at one problem, and I’m going to solve that problem, then then the next problem, I’ll solve the next problem when it comes to try to say, Okay, can we solve this, you know, and what was missing what’s missing. And again, I refer to it previous, it’s the ETL approach to say, if you think at SQL, I can write the database problem is the same as integration problem are very similar in a familiar way that I’m trying to move data from sources to destination, which is different schema, different structure of data. And but I’m still trying to move data. And I can write a statement that says in SQL, which is select from the sources, transform it and move so that can be written into one, one single statement that in the company, and language is standard eyes. So basically, whatever is the problem of data, you don’t actually try to look at one problem bubble at bubble, you’re just saying ears, I’m expressing a DATA statement, and then it can be interpreted and generated. So moving data from databases is no longer a problem. That was missing an integration. There’s no, there’s no integration language. So that’s kind of the so you do have API, which are your sources similar to databases in a nutshell, it’s fronting your application. But there’s no language to represent, I want to move from these epi to this, and I want to transform it. So integration is still done. in silos. extraction, transformation, and load is entirely different. So every time you have a new data problem, you have to write code. So that’s what we strive to solve this. Okay. Now, first, let’s create a platform and I pass around a language that is solving that so that doesn’t matter what DATA statement or what data problem we can add, it’s always going to be solved the same way. In a nutshell, that’s just what we would try to do.

Brent Skinner 13:17
Yeah, yeah. And I’m so glad you brought up iPass. Because the cloud connectors at TCC, for short, the cloud connectors is an iPass. But, but you’re different. You’re a different kind of iPass. And it is that that cloud data piece of the puzzle, that’s a big part of that. Yeah. Yeah. You know, I’d love to learn a little bit more around integration strategy, which we talked about that too, but I know there’s also another slide here. That’s, that’s really interesting. I’ve seen before. So the wall effect? Yeah. We’ve heard it. I’ve heard you guys calling it the wall effect pier. What? What is the wall effect?

Pierre Rousseau 14:03
So basically, this is, you know, when you are at your startup, right, you’ve got and you first start signing customers. And you need to build custom integrations. And you, you know, of course, you can do it right, you got some very bright minds in your in your shop, and those guys are going to take care of it. So you’re gonna have one guy that’s going to do it, and then he’s going to build the second customer through us. So another says software, and so on, so forth, right? So you’ve got your own team, maybe one or two guys are going to build these integrations to 1235 20 customers. But as you grow, you keep replicating the same thing, which is custom code, per client. And now your team. Well, it’s no longer one or two guys that were four or five guys, right? And you keep growing, you keep expanding and now you’re at a point where you got 200 integrations, 300 integrations, and now you’re seven guys. And now you got customers asking you to change code. to y and z, and it becomes a lot of work. And now you’re at some point, it’s going to cost you internal cost is going to be true to roof. But in your own mindset, you’re going to say, well, guess what? I have to do it, it’s the way to go. Right? But no, it’s not the way to go. And we, we like to think that your own developers should be working on building your own solution, and then seeing it that come up with very cool features, not have five or 10 Guys, or maybe more, in some cases that are just maintaining line of lines of codes, integrations. That’s just not you know, that doesn’t make sense, right. So it’s, that’s a wallet there.

Jeff Tremblay 15:43
There’s many, many Yeah, the vendors tend to think and that’s what we track to where they tend to think that they can solve this and they don’t really see the long term big picture of where they’re going. So I spearfishing the first instinct is like, oh, there’s an API. Yeah, I can build something that works. And then, so the first misconception is, they’ll think that eventually, if they do it, it’ll, they’ll be able to repeat per vendor or, you know, it will look the same or adjustments per system that they try to grow. It’s going to slightly vary, but they can, you know, simplify quite a bit. And then the second mistake is thinking that even within, once they realize that it doesn’t work per vendor or much, then they’ll think well, okay, well, at least once I have a vendor, I’ll be able to customize, or each customer will fit in the same bucket. But unless you unless you simplify to the exact same requirements for customers, you end up with this. And then you’ll, you’ll hit your wall at one point where I think Gartner now says that it’s 50% of your r&d that will be spent on integration for your own product over time, and it keeps they keep implementing that number every, every year, every time they do there’s a report. Yeah, it’s like 15 I think they’re predicting that it will grow beyond 50. In the future, because of that problem.

Brent Skinner 17:06
You know, that’s, you know, it’s funny, I can imagine a scenario where a vendor contending with all of these integrations might it might actually be, might actually be preferable not to take on new customers at some point. I mean, it’s a weird, scary situation to think about. But yeah, this this is so interesting, because it’s this is, if you think about it, this is sort of the sum, total effect, financial labor expenditure effect. And innovation of innovation, impediment for any vendor that’s that has that that big iceberg underneath the surface of the integration that this is this is the this is what happens with the with the integration iceberg. This is what happens. Exactly.

Jeff Tremblay 18:07
They’re directly tied to both of them, correct?

Brent Skinner 18:09
Yep. Yeah, absolutely. Now, what is what’s what does an integration strategy look like? I mean, let me let me frame this a little bit from my perch, from what I understand. And maybe you guys can elaborate. From what I understand. Again, going back to the API’s, and that sort of that point to point API integration approach of the past, which was definitely better than what preceded that. But just does it isn’t up to snuff for today. When you have enough of those in place is just you end up you’re very reactive, and you’re just it’s kind of like trying to plug the holes in a dam, you know, and you only have so many fingers. And you’re just, you’re just working on that integration strategy. What is what is integration strategy? Like? How does cloud data have factor into that? Because obviously, obviously, it does, but there’s more to it than that. What is an integration strategy?

Pierre Rousseau 19:12
Well, the integration strategy, first of all, is you got to, you got to it has to be three to five years upfront, right? So what do you need to put in place right now for everything to scale once you’re 510 20 times bigger 100 times bigger, right? So that’s the first thing you need to think about not look not so the strategy should come from you, your organization and not come that typically comes from sales, right? Sales are gonna say, Hey, guys, I’m about to sign this customer. Can you integrate these guys and you’re gonna say, Sure, we’ll make it happen right then. And that’s not strategy that’s just being reactive and that’s what you know, many people do, but the strategy is, is otherwise you first of all need to select the right eyepatch. Right that As that as that is going to be able to scale with the number of clients that you add, and scalability is number one, afterwards, you’ve got to be able to mass manage and Mass Update, because your own API’s might vary might change over the years. And, of course, the different software’s that you’re going to be connecting to, will evolve as well. So you got to be able to scale mass manage. And that’s what you need to that’s what needs to be part of your strategy. Otherwise, every single client is going to have his own line of code. And you’re gonna have to redo this over and over again.

Jeff Tremblay 20:35
Yeah, I would say reusability, from A to Zed, you need to reuse your code. And be sure that as piercing massively. And that’s kind of, for us, like, if you think about it, if you reduce your integration to DATA statement, like for us, we could have a vendor changing as API, it could change from XML to JSON. If the data model is the same or evolves, as long as it’s the same piece of data, we can update a connector and we consume a DATA statement, it will just generate the proper web services. So we update once and Mass Update for everybody that needs to be and then ultimately think about your long term maintenance costs. So if you think about integration, think about long term and maintenance costs. And if your strategy is going to keep, you know, is going to bring you to 50 or 60% of your r&d spend on integration. How can you stay competitive? And how can customer not have to absorb that cost? In the long term?

Brent Skinner 21:37
Yeah, yeah. You know, going back to what you said, Pierre, that what strikes me here is that in an, I would say, an integration strategy. First and foremost, is, is a just a wholesale shift in mindset. You know, where were you going with my mindset shift? You’re right. Yes, yeah. Yeah, absolutely. Where you’re, you’re, you’re realizing from the Verrett, it’s, it’s the organizations that are going to get this right. Are, they’re going to, they’re going to be working with the cloud connectors, obviously. But beyond that, they’re going to be, they’re going to have that understanding that they’re going they’re thinking about the future, you said that three to five year minds, mindset, where they are acknowledging it’s almost a sort of a talking turkey to themselves, look, we are going to hit the wall, the integration wall effect, it is going to affect us, let’s, unless we account for that now, and entirely shift our, our approach to integration. One of the things that I like to talk about is, when thinking about integration, a lot of it coming from, from my conversations with you, too, is this idea of, of Zen, you know, there’s, you know, there’s so many things we think about, okay, at some point, we’re going to solve for it, finally, and there’ll be perfect, and we can set it and forget it and move on. There’s a book that I that I have I know haven’t read the whole book. So I Don’t Want To Be A Poser here. I haven’t actually read the book, but it’s called Zen in The Art of Motorcycle Maintenance. And I started reading it once and I got super busy with something and I put it down and I never finished it but what I understand is that you have an old motorcycle, right? You’re not the goal is not to get it fixed and get it right. And then you’re never going to have to fix it again to enjoy it. The idea is that you need to incorporate fixed repairing the motorcycle into your long term. Never Ending experience for out for as long as you have the motorcycle. And that’s kind of the idea with, with integration strategy as well, I think you know, you’re not going in it and into your integration at the beginning and looking to fix it at the at the outset and then expecting it just to work. The idea is to think about integration throughout the lifetime of the existence of the coexistence of those applications.

Jeff Tremblay 24:23
For sure, I love that analogy because I’m a motorcycle enthusiasts plus. I didn’t know. But yeah, I think it’s spot on. Because you cannot look at integration as a fixed you’ll never it will always change I mean, we’re in the IT world. It. There’s so many especially in HR. I mean, if you think about it, there’s so many new solutions. People are being creative and there’s always new application new solution. You want to integrate them into your stack so it will continuously evolve and then even the same systems evolve technology evolves you API’s change the system change. So I love the analogy if you can figure out how to maintain it over time and as part of your life cycle that’s it’s perfect. That’s the way to think about it.

Brent Skinner 25:14
Yeah, yeah. Well this has been a fascinating conversation. Thank you so much for being my guests on this episode. I think this is very, very helpful for folks to be learning about in our space. Thank you so much, Brian.

Jeff Tremblay 25:30
Thank you Brent

Pierre Rousseau 25:30
Thank you

Share your comments: