Intro to the Agile Integration Approach: an Essential Part of a Growth Strategy

Intro to the Agile Integration Approach: an Essential Part of a Growth Strategy2020-09-10T18:55:47+00:00
ON DEMAND WEBINAR

Intro to the Agile Integration Approach: an Essential Part of a Growth Strategy

Watch Now

Mark Simon Mark Simon Head of Strategy and Operations
CELIGO
Kim Loughead Kim Loughead VP Product Marketing
CELIGO

As you start to scale business operations, it doesn’t take long before you realize that manual processes are holding you back and potentially slowing sales and reducing profitability. It’s one thing to realize you have a problem and another thing to know where to start in solving it. What are the critical business processes you should integrate now and which ones can wait? How much should I automate before waiting for the next inflection point so I don’t waste time, resources and most importantly, cash?

These are all the same questions Celigo faced as we started to scale. In this on-demand webinar, we share with you what we did, when, and why through an Agile Integration approach. Mark Simon, Head of Strategy and Operations at Celigo with two decades of operational experience, provides details about how Celigo took an agile approach to automating our business operations, including:

  • Critical first step business process to automate and key integrations
  • Celigo's integration roadmap and what our business gained from each step
  • The Agile Integration approach
  • The Integration Maturity Model to help lay out an integration plan for scaling your business

Watch Today!

Full Webinar Transcript
Good morning. Good afternoon everyone. My name’s Kim Loughead. I’m VP of Product Marketing here at Celigo. I have with me Mark Simon, who’s VP of Strategy and Operations, also at Celigo. And welcome to today’s webinar, intro to agile integration approach, which is an essential part of any growth strategy. So for today’s agenda – if you can head to the next slide, thanks – we’re going to do a super-quick intro of Celigo for those of you who might not know who we are. And then Mark is going to go through some different types of how you manage integrations and an integration maturity model that will sort of help you map out the approach you might want to take and where you might want to strive for in the long term with your integration strategy. And then we’re going to get into some more fun stuff. So we’re actually going to walk you through how our agile automation approach has helped us get to our first 25 million. And we’re going to go into some detail here around exactly what we did to get started, what were some of the key early integrations we did, and why we really feel this agile approach has worked for us and why we think it will work for you. And then Mark will finish off with some free advice, which is always worth what you pay for it, and then we’ll have plenty of time for Q&A at the end. So a couple of housekeeping tips. We are recording the session. You’ll get a recording– you’ll get a recording of it in your email box at least by tomorrow. If you have any questions, please use the Q&A panel to type them in and we’ll get to them towards the end of the presentation today. So Celigo. Who are we? So Celigo is a integration platform as a service, otherwise known as an iPaaS. We serve mostly mid-market companies. So our UI is uniquely designed to serve both the technical as well as a non-technical user. So that means we have all of the dev tooling that a technical developer would need to build complex multi-step integrations, but we also have a UI that’s very approachable for a non-technical user who understands the relationship of data and what data needs to be integrated that maybe isn’t proficient in JavaScript, for example. We have over 3,000 happy customers, some of which you can see there on the right. We’re a global company. We have operations in the US as our headquarters but we have operations in EMEA as well as Asia-Pac. So we could serve customers globally. We are on the Gartner Magic Quadrant, one of only 17 iPaas vendors that appear in that Gartner report. We serve all verticals. So we’re talking largely today about SaaS, but we also serve e-commerce verticals, manufacturing verticals, distributors and wholesalers, and a slew of other different types of verticals. And for those of you who may know us, we do have best-in-class integrations to apps such as Zendesk, Salesforce, NetSuite, and Jira through something that is unique to Celigo, which is our integration apps. And these are SaaS apps that are built on top of our iPaaS platform that serve very specific integration needs between two applications. So we have a integration app for Salesforce to NetSuite that solves probably 90 to 95 percent of the integration use cases you would have between those two applications. And Mark will sort of touch on how we have used our own integration apps throughout our journey so with that, I’m actually going to now pass it off to Mark and let him do a more in-depth intro of himself and get us started. All right. Thank you very much, Kim. So I’ve been the VP of strategy and operations at Celigo for just about the last two years. And within that role, I’ve been overseeing our internal business systems here. So, primarily, our core NetSuite and Salesforce systems, the integrations within those, the team that manages those integrations, but also several other business systems as well. We’ve got a universe of– I think we’re getting close to 40 SaaS applications in the business currently. Prior to joining Celigo, I spent 12 years in the NetSuite consulting space, of which 8 years were leading one of the larger professional services firms in the NetSuite ecosystem. So I’ve spent most of the last decade– over the last decade very focused in the ERP mid-market space, both with NetSuite and with several other ERP systems, CRM, and the custom business solutions. Prior to that, I was on the other side of the fence and was co-founder and CTO of an e-commerce company where we actually selected and implemented NetSuite for our own usage. And that was a critical juncture in the growth of that organization. So I’ve been working with integration and data flow between business systems for close to 20 years now. So moving on to the Celigo story a bit, it helps to kind of set the stage around the ways that integrations can be managed in an organization. And we really see this breaking down into three different methods right now. There’s a traditional centralized, there is a decentralized integration approach, and then there is a distributed development with centralized management. And the way we view these is none of them are right or wrong. They’re simply different methods of going about it, and they fit for different organizations at various size in their growth and various industries, various departments. And we see, very often, a mix of these within an organization and with ours. So where Celigo is at, as many organizations often do, it actually started out with some of a centralized development approach. It then moved to a bit more decentralized, and now we’ve been circling back through as our internal business systems team has grown to a hybrid, which is the distributed development and centralized management. And by that, I mean you have internal resources that may live in IT or in a business systems team that are experts on the integration and are owning perhaps some of your critical financial integrations, but then other integrations are owned, developed, and perhaps managed by their own departments. So a good example can be integrations within marketing or within different sales applications that then can be managed by the teams that are closer to that, whether it’s a marketing ops or perhaps a sales ops or elsewhere in the org. We see the same thing– as a SaaS company, we see the same thing with engineering. Certain integrations that engineering and product feel like they should own. And so this hybrid lets us leverage more resources in the organization. And this also becomes critical as you select a tool for us. And iPaaS is the cornerstone of this whole technique. But having an iPaaS that is easy to use for the end user facilitates this. So having a tool for integration that doesn’t require developers to manage and build out integrations is key to moving to a more optimized approach. So one of the things we look at is an integration maturity model. And there’s a lot here to take in. I admit that. But this is also a very powerful slide in concept because it shows the growth that a lot of organizations go through as they mature in their approach to integration over time. We look at the step on the far left, the ad hoc step, that’s the very beginning. So that’s where you’re typically very reactionary when you’re approaching integration as an organization. So it’s often an afterthought. It’s driven by, “Hey, we need a system to do X.” You get that system up and running or partway through implementation, “Oh, how are we going to get this data connected?” Or, often, it’s months after it’s been up and live and you start to have some problems. You do a quick root cause and you see that, “Oh, we need data integrated.” That’s a state that a lot of organizations pass through and that’s very, very common. And it’s also very common as organizations will step up through their approach to integration maturity that you’re not on the same level for all areas. So maybe operational readiness is lagging behind. Maybe it’s way ahead, but your number of cloud apps might have proliferated to 30 or 40 because of your business needs while operationally you’re not at an optimized stage, for example, yet. One of the things that’s pretty common as we see customers move through this and as we have moved through this maturity model ourselves is that you see a mix of using both point-to-point integrations that are often provided with or native to certain SaaS applications. Our own what we call integration applications, as Kim mentioned earlier. So the Salesforce and NetSuite is an example. Using those and then more custom integrations that are built. The central point to this is at the very beginning, you’re leveraging transfer of data. That’s integration right there. And you need to really think about how you’re going to move that. And what we found was being an iPaaS company and having [inaudible] at our disposal from the very beginning really changed how we thought about that approach and set a good foundation for growth and success. One of the things about this as well is that right in the middle we see a centralized step. And that’s a model that is kind of the traditional one, where a lot of larger organizations stop at what was previously seen as the way to do integration, especially when everyone was building out integrations. It required a coded approach or a very difficult-to-use tool to build an integration that required developers. And what we’re seeing now with the modern tools, a true iPaaS 2.0 like Celigo, some of our customers, they just skip over the centralized stuff altogether. They go from a developing phase to an optimized and a decentralized approach because as they– business needs are changing so fast that when you move into an agile-oriented approach driven by often agile approaches to business process definition and implementation– it’s moving so fast. And that’s the only way an organization can keep up and be optimized enough to meet the needs of the business. So how did an agile automation approach get us to our first 25 million? We just take a look at the Celigo– let’s call it a snapshot of the Celigo app landscape. And this is a few of our applications, but these are the primary ones. Some of the most critical in our organization. And what you’ll notice is when you have all these– as everyone knows, as soon as you get applications out there, you get data residing there, and then you end up with inefficiency. And we’ve seen the same thing as our own internal integration sometimes can’t keep pace with our implementations. Not often. Even though we’re an integration company, it still takes time and energy to identify the business processes and have a good plan for the integration. And SaaS apps, some of them can be implemented very quickly. And we take a hybrid approach to this ourselves, and you’ll see some of the connection points here leverage native integrations. And while that may seem surprising to some, that we’re an iPaaS company and we’re leveraging native integrations, sometimes that’s just the quickest way to go. And we get a SaaS app implemented quickly. We will do a gap analysis and assessment of the native integration, see if it meets our needs, and launch it and use that native integration. If it gets through testing, continue to use that. We often find gaps very early on, and in which case we will remediate those through custom flows built on integrator.io. But the point is, like any growing company, we don’t have unlimited resources, so we have to, both as a business systems team and as departments, kind of make smart decisions on how to approach this. And I think that’s a key thing for us and anyone else that’s looking at planning their integrations. You will use things. And using some of those native integrations can be useful for a period, but you will almost certainly outgrow them as your business needs evolve and change. And having a plan and a tool to support that is pretty critical to making all this work. So for us at Celigo, things really center around a set of seven solutions that have really become the data hubs in our organization. And this has been an evolution over several years. This started out with, really, just about three of these, initially, and that has grown over the years to expand. And that’s what’s going to happen for any growing SaaS company. And it’s important to recognize that as you add more data hubs, they can become islands very quickly. And islands of data lead to inefficiency, reporting problems, inaccuracy. Synchronization problems are very common with those scenarios. So it’s just key to be cognizant of that as you go. And you might start out with one or two of these data hubs and you won’t know where you will end up. You might have an idea. We see some common patterns, software, SaaS. Those software companies. We use a lot of the same ones. But where you’ll end up is often very different than where you think you’ll end up. So it’s just important to be thinking about that as you pick your data hubs and you plan for those, how you’ll be integrating. So jumping into what we did, the first step on Celigo’s agile integration journey was the quote-to-cash process, basically. Getting orders into our billing system and ERP. The first phase here, really, it all boils down to getting the money in the door and making the product work. And these integrations were built out as the first ones that the team put into place at Celigo several years ago, and that started with Salesforce as the CRM that was adopted early on in Celigo’s journey as a software company. And so, right away, one of the first needs there is just to get those closed opportunities over into NetSuite as sales orders. In our situation, we were able to leverage our own NetSuite-to-Salesforce integration application, which in an early phase like this and even further on handles a great number of the needs right out of the box. And that provides a rapid path opportunity with using integrator.io to then customize later. But we leveraged that right out of the gate. The other thing that the team built early on is integration for users and licensing from NetSuite out to our product back end. Now, a little more detail on this is helpful. Celigo happens to use NetSuite as its subscription billing engine. Having an original nexus as a NetSuite solution provider, the team had a lot of capability and strength around NetSuite custom solutions and built a very good solution using customer records within- and that’s way to handle the subscription billing aspects and be that entitlement engine within that suite. We see a spectrum of things. So for other customers that may more look like using suite billing. It could be all the way up to a Zoora. It could be using a subscription solution that’s part of a payment provider like Stripe, for example. There’s lots of different options out there and that may vary. But that flow of data from around entitlement and licensing to a product is critical for a SAS company, and that was one of the first integrations that was built. And this is built here. Those are all custom flows. [inaudible] is using a custom database solution on the back end, but those flows keep are our product in sync with our entitlements and subscription master in that suite. So moving on in our evolution, the kind of the one B-step for us was getting further along in the customer 360 visibility and getting some basic and intermediate product usage data into our customer hub. So our customer success team– and this a great example of a distributed model. The customer success team owned the support tool that was selected, Zendesk ,and that we still use. And they built out the integrations from Zendesk into NetSuite to bring in ticket and status information into NetSuite so that we could have a more centralized visibility, as in not all users in the company were in Zendesk. So we could get that customer 360 in our first phase here within our ERP NetSuite. Another side of this that was really critical was getting some product usage data. So an example of that is, how do we know if a customer is successfully using their products? How do we know if a customer is having problems? Can we identify that? Have they purchased things that maybe they’ve implemented but they’re actually not using or the volume is is down dramatically on? And all of our logging is going through Splunk. So by integrating Splunk data into NetSuite, able to take millions upon millions of rows of log data in Splunk, aggregate those up to a higher level, and then bring those in as as custom records into NetSuite associated with the customer to provide visibility and just high-level number of flows running, how successful those flows are to provide that 360 visibility into the customer health of their account. And that was really critical for getting visibility in the organization into how to help customers better. So our next step in the process was this initial process with cash management. So getting billing and payments integrated. And this came a little bit further along in the journey. And this is where we’ve added in several solutions as we’ve moved– as our businesses has evolved, we’ve moved those processes out from the core ERP out into best of breed applications. So one of the things we’ve done in the business systems team and in conjunction with the finance team at Celigo is select Paystand as our payment processor and billing portal provider and leveraging Paystand and getting the payment information integrate it into NetSuite. So facilitating easier payments by our customers when they receive an invoice is a critical part of an objective for the organization, which was to reduce friction in the payment process and give customers more options. And this is a case where we actually leverage– again, we leverage a hybrid approach where we can utilize custom integrator.io flows for some of it, but we also leverage some native integration for others where it makes sense. So it’s a good pairing, especially because in this case there’s an embedded application in NetSuite. So we compare the two approaches for an optimized approach and taking that approach reduced the burden on our internal teams as far as management and build-out of the data flows. Another one that we added in this journey is bringing in SAP Concur for employee expense management, leveraging integrator.io to build those integrations using our templates. And, again, that really helped accelerate the process. So why does an agile approach matter? Where you are right now is unlikely to be where you’ll end up. And often you have a vision for where you’ll be and what your systems will look like, what your business processes will look like, and you should always plan and plot that out. But that’s plan and reality very rarely meet up. And so a modern business environment, especially for a growing SaaS or software company, is so dynamic. You need to bring agility to your integration and your business processes, and flexibility in platform and approach is key for that. And we found that to definitely be the case at Celigo. So as applications in your environment evolve– and by that, we mean both feature sets within the applications, the business processes that are going through them. These things simply will change over time. And sometimes they change very rapidly. From my consulting experience, what I saw was a 90-to-100-day window after go live on ERP was a critical juncture, where there would typically be a significant amount of potential change. And I’ve seen that hold true for just about any application you implement. You do your best to align new processes with the needs of the business, but then where the rubber meets the road is when the users are in there using it. And you really often get some great insights on how to evolve things and get the highest level of efficiency in that second phase. It’s those adjustments that you make. It’s the modifications that come afterwards that can really make a very dramatic improvement in efficiency, optimization, and user happiness as well. So that’s true with any application and is critical to be– in order to facilitate that, you need to have flexibility with your integration as well and be ready and capable to make changes. So you can see there how Celigo went from a fairly simple customer success environment to we added Gainsight CS as a critical data hub in our environment. And Gainsight is where our customer success team is living and really spending their time logging and viewing data about the customer to optimize their customer health and happiness. But that dramatically changes the data landscape, and that’s natural. We couldn’t have predicted that we would head in that direction. A couple of years before that, it wasn’t on the company’s radar, but things evolve. The landscape for customer success applications evolved, and suddenly it becomes the best and most efficient move to select the best-of-breed application and get this implemented. So one of the things that’s critical here is now NPS score information is living within Gainsight. Visibility into support tickets, customer survey data there. Onboarding project data is living in there. Again, so expanding that Customer 360 view and adding these integrations in quickly and easily were critical to this. At Celigo, we run in a highly efficient manner, and so we don’t have a large and expansive business system team, but we have– by leveraging integrator.io, our CS team actually took on the building of their flows in integrator.io from NetSuite to Gainsight and back along with Jira, Zendesk, and some of the other applications. And our CS team members and leadership there that built these out, they were not experts on io, but they were familiar with the platform. They implemented Gainsight, for example, Zendesk, involved with the other applications. And so they were business process experts. And as business process experts, they’re uniquely situated to be the most knowledgeable on the details of the data flow between the systems. How they want it visible, how they want it transformed. And so instead of handing off to centralized IT and queuing up and taking longer to implement or slowing down the process, they were able to, with guidance and assistance of a validation of the architecture in a centralized manner, build these out quickly and efficiently themselves. And I think that that’s really an excellent example of a distributed method. And for us at Celigo, it was an excellent way to approach it, and it’s been very successful. So another very important topic in the later agile journey for Celigo has been the reporting and analytics. And this can be very, very tough. As you move from– as we moved from most of our data being in a single system, for the most part, or really two systems early on that become three, as this progresses, you go from– we had data in our ERP, NetSuite. That was largely synced with our CRM early on. But then we have product data that’s out in our product back end. And lacking the ability to sync those from a reporting standpoint was limiting. And so one of the things that we implemented was launching a relatively, in some ways, basic relational database in a cloud-hosted environment. But not biting off the end-all, be-all solution, but launching something in an environment that could be propped up quickly. And this was a fantastic example of the agile process at work for us, getting that up and running, because our product team simply needed a relational data set to be able to answer some questions. A lot of our product data is about usage and I think the metadata for a customer around what they’re connecting, what their flows are doing, the status of those flows. Those are all in a MongoDB database. And it’s a great option for a lot of things, but the load to do relational SQL queries against it is very high. And so the ability to get that data out and into a quick relational database that served as sort of a proof of concept in the beginning of our journey was very, very helpful. It allowed the team to answer a lot of questions very quickly. And then from there, we’ve simply expanded on that. So getting more customer data, starting to solve other business problems by getting additional data in, whether it’s from Splunk– other areas beyond just more subscription data, billing information, these types of things, and iterating over this and adding these very quickly to facilitate answering a question. That has served us very well. And as we look at where we’re going, we’re adding more data to this and looking towards the future. We haven’t settled on a final data warehousing solution, but we realize that we’ve met some early needs, we’re outgrowing that, and we need to evolve further and migrate our core to more of a true data warehousing solution. Evolve to the next step of more sophisticated centralized schemas and then, with that, bring in data from additional platforms in our environment. And we’ll continue to do that And all of these flows are facilitated using integrator.io. And in some cases, from a data pipeline standpoint, we’ve moved to leveraging Python, for example, Python and pandas, and adding those in doing proof of concepts on some more sophisticated data transformation using those tools and then piping that data in through integrator.io as we build this out. So free advice. How to go about building out your integrations for success. Key takeaways and advice from our journey at Celigo. Our approach was to start with that quote-to-cash to accelerate billing, and that’s what we would recommend to our customers and that’s what we see over and over again with our customers as prospects, is them focusing there. And that’s a key thing. Get your order-to-cash process to a stable, efficient process as soon as you can. And then within that, depending on what your environment looks like, you may need to integrate for entitlements processes to keep your customers happy and so that they can be– that you can address that fulfillment side as quickly as possible. The next one, right beyond that, close-following, is customer 360. And for churn reduction and for increase in upsell, you need to have that visibility. And thinking about that from the start and picking a good reportable platform is what I would really recommend there. And when you start looking at customer 360, you often are joining in data from multiple systems, and those queries can get more complex. And that’s where some SaaS solutions often don’t have as strong capabilities out of the box for reporting. So that’s where it’s important to think through some of that early on, where you want that Customer 360 data to reside, in what shape, and what will you need to get out of it, and keep that in mind early on. The other one is the cash management. That may come into play in a different order than ours. So we primarily do most of our billing on invoice in terms. We’re primarily a company based on one-year annual terms, one or multi-year, but a lot of SaaS companies have very different models and may be more focused on up-front credit card payments, monthly billing. Quarterly may come into play as the standard. And in that case, that could definitely move up some of the requirements around this. Primarily being a B2B company, that meant this was less critical with 3,000 customers than if we had 30,000 customers. We would have moved up– cash management would have moved way up in the priority, and then a very, very early focus– payment processing, reconciliation then move up earlier. And, again, that comes down to everybody’s individual needs. One of the big things here, and I touched on it already a little bit, is around reporting and analytics. So when you’re looking at a business systems architecture, you’re plotting out your integration road map and your landscape, you’re looking at native versus custom versus using maybe something like an integration application on Celigo, you should always, always be thinking about reporting. And I’ll draw a comparison to the 12 years I spent in NetSuite and mid-market ERP consulting, was eventually it evolved pretty quickly, our process to– one of the very first implementation conversations, either the first or, at most, the second, would involve plotting out and mapping requirements around reporting and analytics, simply because it’s so critical to understand some of the key requirements around your reporting needs as early as possible. And while you don’t have to overengineer everything, keeping that in mind early around how you’re going to report data when you start to have– especially disparate systems. When you’re moving it around, there are some critical fundamental principles about your business and its data that will bubble out. And identifying and addressing those early is one of the– can be one of the things that increases efficiency more than anything else. And reporting is an area where it’s very easy to get painted into a corner and be in a position where you have to do more iterations and you need more rework. And that’s a part of an agile process. But that said, you want to be as efficient as possible and get to key insights early and keep those in mind throughout your business system journey and the integration work. It will really make a huge difference in the efficiency for the long term. So, beyond that, again, as the business systems are– as you’re implementing, you should always be asking yourself when you’re touching on a system. How are we going to integrate this? Where does it fit into the integration plan? Should we integrate it now? How are we going to integrate it? Those are critical things. And that’s questions to ask. And do we have the right platform? And Celigo being an integration company and having an iPaaS in-house, it very much facilitated a more efficient process for us, and we really see the power of the ease of use combined with the technical capabilities of our platform within our own organization. We see it ourselves in departments being able to run with building and managing their own integrations where needed and also having centralization as well and marrying those two in an optimized manner. I strongly recommend anybody embarking on the integration journey, whether you’re at the beginning or further along in the maturity model, that you keep that in mind and think about it. Awesome. Thank you. Thank you, Mark, for all that great information. Just a reminder to the audience out there that if you have any questions, please put them into the Q&A section. We did get a couple of questions come through while you were talking, Mark. So we’ll hit those first while we wait for others to add some additional questions. So one question that came in was common sort of pitfalls. So people kind of start off on their journey and then they realize that they’ve potentially picked the wrong path or seem to stumble and then have to do some maybe rethinking or reworking. Are there any common things or common pitfalls that you’ve seen in your experience that we could sort of help people avoid? There’s several. One is just realizing that not everything’s going to be perfect. Not everything is going to be right. So we all do our best to make decisions around which system and how a business process should work. But the only thing that I’ve seen hold fast is that you don’t know what you don’t know. And as soon as you think you have it all figured out, the business will change. Something will change and it will modify. So I think that’s led me, especially over time, to really try to weigh the balance of looking down the road but also just accepting that this will change and adopting more of that agile approach and just accepting that we will have a lot of iterations, we will evolve everything, and setting expectations with your key business stakeholders that this will be an evolution. This won’t be perfect the first version. And getting everyone thinking about continual evolution of your integration in your business systems and processes will lead to a ton of success. Another big pitfall that I see is not having a clear answer to, “Who owns this?” when it comes to integration. This can often happen in any of the models. It’s less common in the centralized model, but it’s very common to not have a clear answer on who will own an integration once it’s up and running. It’s one thing to build it, but and it’s less about the technical aspect of it. It’s relatively easy with a modern tool like Integrator.io to go in and change the mapping or change the transformation. But it’s making those decisions. It’s getting to the bottom of a business problem. Okay? This record failed today. Why did it fail? The contract between the two systems wasn’t met, and we now need to delve into and get a root cause of why a field didn’t have the correct value in it, for example, that it failed to meet that contract. There needs to be someone in the organization that is looking at your integrations and looking at the errors on a daily base basis. And something that we’ve done internally and have a target and strive towards– certainly not successful at this all the time because it is to target zero unhandled integration errors. And so start with one critical integration. And so we know for us that if it’s finance-oriented and integration, we stick with that and can look at it and say, “Okay. There’s a clear owner. There is management. We’re making sure that we’re addressing those errors, and we have zero unhandled errors.” So that’s a big pitfall. You can have a great integration platform that you choose. You can implement it properly, but if you don’t stay on top of your integration management, you won’t be successful in the end, so. And that’s where Integrator.io can come in and really provide a good opportunity for changing how that’s typically done because that management of an integration then can shift more to a business user. Someone that’s closer to the endpoint application and maybe not as technical, and so you have a pairing that the business user can now get in and investigate, handle the first line of response and investigation, and then if needed, they can escalate to someone that’s maybe more technical and might modify code or write new code. But being as most integrations can be done without that, that’s often not needed. So those are a couple tips. Cool. Super helpful. Thanks for the detailed response there. That sort of spawned a adjacent question around best practices, and just maybe to add a little color. So if we’re in a distributed model, how do you ensure that everybody’s following the same kind of best practices about not only building, but as you say, managing the integration. So at the end of the day, if you have something that is scalable and reputable, people are reasoning integration assets across the organization versus everybody kind of using the same platform but maybe reinventing the wheel every time they start an integration project. Yeah, so the first thing is have an iPaaS solution. So when you get– a distributed model will not be successful and will just create a a massive mess if you don’t have a centralized tool so that you then have a very clear choice. You’re either using native integration, native plus custom clothes on an iPaaS, or you’re building out with a custom flow on the iPaaS. So that’s a starting point. It just simply won’t work without an iPaaS. It’ll just come unglued. So use an iPaaS, and then from there, establish a center of it– I use the term center of excellence, and that sounds like some big fancy resource-heavy project in a large organization, but that can be simple as figuring out who in the organization is going to be the nominated and more importantly, take on some leadership around building out integrations. And that can be someone in an existing department. That can be someone if you’ve got centralized– if you have I.T. or business systems, those are a natural fit that somebody there is taking some responsibility. So even if integration is built by marketing, there’s someone that’s building out a common set of approach and processes and saying “Hey, everybody at the department level, you can build your own integrations, but this is the approach. This is how we test them. This is how we roll out to production. This is how we do an architecture review.” You can make that as mature or as lightweight as you want, but starting with getting some assistance in the organization, and that cannot be a single person or single team. That can also be more of a committee where if you have a very distributed environment– very, very distributed, you might have a five-person committee that’s building integrations for each of their departments, and they come together every two weeks to look at what’s being built, review it, and sign off collectively because you have more collective wisdom. There’s no single right answer there but those are some ways that you can really both leverage the platform and the team and knowledge that you have to make a distributed model work successfully. Awesome. Thanks so much for that insight. Looks like that is all the questions we have, so I want to thank everybody on the call for attending the session today. Obviously, I want to thank Mark for all of his great insight and information that he shared with us today. And if you want to learn more about how we updated our customer 360 journey, there’s another webinar that you can find on our resources page. As I said, you’ll get this recording in your inboxes tomorrow morning. And thank you for your time and attention today, and that’s the end of our session. Thanks. Bye. Thank you