Service Oriented Integration Platform - a Guide
An Introduction to Logistics Fulfilment Integration
Whenever an eCommerce merchant decides to outsource its fulfilment to a 3rd party Logistics Provider (3PL), a technical integration project is needed, to ensure that all orders from the merchant's shop system are transferred reliably and swiftly to the new 3PL's Warehouse Management System (WMS) so they can piclk, pack, print labels and dispatch effectively, getting the product to the customer as quickly as possible.
Every eCommerce merchant uses a shop system - Shopify, WooCommerce, NetSuite, and many more besides; every 3PL has a WMS - Manhattan, BlueYonder, SAP, SNAPFulfil and so-on; and every integration project connects these two systems together.
Onboarding new Merchants - The Issues
Onboarding new merchant employees is an essential and necessary part of the fulfilment process. And this is often difficult. Why? Because many companies' IT integration teams still work with traditional and inflexible process-oriented methods or use non-specialized integration tools that, while proven and reliable, are time-consuming and expensive. Additionally, developing only individual, private one-to-one integrations for each new customer creates a complex structure with multiple points of friction that slows everything down and needs to be kept up-to-date at all times.
As mentioned, it's an unavoidable part of the process. And it's often also a painful process. Why? Because many companies' IT integration teams are still using traditional and inflexible process-oriented methodologies, or use non-specialised integration tools, both of which, although tried, tested and reliable, are time-consuming and expensive. Add to that an entrenched mindset that only creates single, one-to-one private integrations for every new customer, and you have an almost perfect storm of friction that slows down everything.
And herein lies the tension; many swiftly-growing and fleet-of-foot eCommerce merchants approach 3PLs to help handle their rapid growth, and expect onboarding to be equally agile, taking perhaps a few days - only to be informed that this may take 4-6 months, sometimes much more, and also cost an arm and a leg to boot. Even integrating simple shop systems can turn into unexpectedly long engagements. 3PL salespeople often complain of losing deals as soon as they quote the extended effort estimate and costs associated with onboarding. Equally, merchants complain of inexplicably lengthy timescales and costs quoted by 3PLs that simply jar in their fast-paced, agile world.
That both the methodology and the mindset of creating a mass of individual one-to-one integrations bring their own issues, of ongoing upgrades, support and the maintenance of all of these interfaces, not to mention the associated costs, is reason enough to rethink how to build them entirely. Certainly for IT staff, creating the same integrations from scratch each and every time must be a dispiriting Groundhog Day experience for them. Developers would rather be involved in more creative and interesting projects, and many are reluctant to take roles that only offer this type of work. Recruiting and retaining IT staff in the logistics world is a well-documented issue, and it's now not difficult to ascertain why.
Whilst there is a phalanx of integration tools on the market (much of which is lumped into the Integration Platform-as-a-Service (iPaaS) category) purportedly to make life easier, they are neither specialists in the complex world of eCommerce logistics, nor do they obviate the necessity of building private-label integrations in the first place. The diagram below shows the difference an iPaaS tool makes to an IT team - very little, in fact. The only significant difference is that writing code to talk to an API is replaced by creating mapping using the iPaaS software tool.
The remaining process steps still have to be taken, which results in very little time being saved, but paradoxically creates an ever-expanding list of integrations that require ongoing maintenance and support. We are still following traditional development methodologies and IT project processes, with no discernible effort or cost reductions; indeed, we now have the added license fee of the iPaaS tool fees for the API calls that are often charged on top.
What Is Service Oriented Integration?
Codept has pioneered a new and innovative paradigm to address the friction that exists in the existing set-up. The Service Oriented Integration model tackles the issue from a different perspective, and, as a result delivers a different and far more efficient solution. The overriding principle of Service Oriented Integration is that, instead of viewing all projects as individual engagements that re ring-fenced and not to be used anywhere else, the IT team instead can use pre-built services that can be assembled rapidly and re-used regularly on any new projects - which is at once innovative and practical, given that many of the requests between systems are the same, regardless of the shop system or the WMS in use.
A "service" in this respect is what can otherwise be referred to as calls or flows between the shop system and the WMS. They are usually API-based, though not exclusively so (they could also use .csv, XML, EDI, (S)FTP formats), but they incorporate all of the expected calls that a WMS needs to fulfil an order; sales order, dispatch, shipment notification, stock update, cancellation, and so-on. Different shop systems have their own ways of working, but fundamentally their outputs - sales orders - as already mentioned, always need to produce the same data to enable the WMS to fulfil on their behalf.
Services are built upfront, enabling merchants to be onboarded extremely rapidly. And, this standardised Integration model can also be tweaked or customised, also enabling merchants with custom requirements to be accommodated easily within this model. Importantly, many integrations have already been built into the Platform, and they can be used by any company immediately. Codept's Self-Onboarding interface to Shopify in fact does this automatically, and new merchants can be onboarded in as quickly as 10 minutes.
Brand new connections to less-popular shop systems only need to be built once; they are always designed from the outset to be reused, and not just specifically for one customer. And, as long as this initial design step is done well, it massively reduces effort, time and cost for all future deployments of this integration. The interface becomes a "plug-in" tool that requires little or no tweaking on subsequent integration projects, which obviates the need to build and then maintain and constantly upgrade multiple private label integrations, also allowing 3PLs to leverage previously built for other customers.
The Service Oriented Integration model embraces the principles of multi-tenant SaaS, of reusing core product core and adding a layer that allows a core module to be customised to meet individual customer requirements, but still remain part of a commonly shared, reusable service. The benefits include a significant reduction in development effort and costs, a decrease in upgrade and support and maintenance costs, and a much-reduced time to value for merchants. In the high-speed world of eCommerce, the time harvested back from this approach becomes a valuable commodity that can make the difference between winning or losing an account.
The diagram below outlines the Codept model, which is useful in determining the difference between Codept's Service Oriented Integration model and iPaaS integration tool models.
Why Isn't This Model More Widely Adopted?
The big question is: why don't more organisations adopt this model? Quicker, more efficient, cheaper, enabling more sales, easier to support and maintain, the list of benefits goes on.
Well, it requires a specific developer skillset, one that can recognise which elements of an integration project may be reused, and then how to build something in such a way that enables it to be reused flexibly in the future. The benefits of a more considered approach are manifest when subsequent implementations are required; these take considerably less time to configure, as the common services are already set up, and work is only required for any custom components. And, because you are reusing common shared services, they are also much easier to maintain and upgrade.
But it also requires a specific mindset, of agility, flexibility and speed, which does not always marry well with other traditional orthodox methodologies that so many experienced technology experts have grown up with and have embraced as the best way to run projects. This mindset is somewhat entrenched in many larger organisations with long-established highly centralised IT departments.
The traditional IT project methodology, called Waterfall, or writing a technical specification, signing that off and then following that specification rigorously, and with change requests from clients at every step needing authorisation, has worked for many years. But the Waterfall approach, as well as being time-consuming and expensive, is also blinkered insofar as it is designed to handle individualised private-label integration projects. Service Oriented Integration requires consideration of other projects, so that services can be successfully shared between clients - so the overall approach needs to be more holistic, and less individualised. This agility and flexibility is the essential mindset we are referring to.
Many 3PL organisations may not realise they have a problem. When they win tenders, they are able to deploy new integrations that merchants are happy to pay for and patient enough to wait for. They use a trusted methodology to run integration projects, and they generally succeed, more or less.
But how many deals do 3PLs lose by quoting implementation fees and timelines that merchants find excessive? Ask a salesperson, and they will tell you plenty of stories of frustration and loss. If there were an alternative way of building integrations, which decreased costs and timescales for all concerned, it would be germane to explore, surely?
The Codept Platform Approach
Codept has pioneered the Service Oriented Integration approach outlined above, using the Codept Integration Platform. Services are shared rather than individualised, so multiple merchants can use the same integration service calls - meaning that onboarding a new merchant into their WMS environment takes a fraction of the time compared to following traditional integration methodologies, leading to shorter time to value for the merchant - as already mentioned, a valuable commodity to be able to offer. The Codept technical team has adopted a highly agile development approach, but, using this shared model, the "new work" components are smaller and easier to complete.
For companies that provide eCommerce contract logistics, by adopting Codept as their Integration Platform, they are also able to leverage other integrations that are already built into the Platform - that alone delivers substantial savings; there is no starting from scratch here. The Codept Platform already supports all of the major shop systems, such as Shopify, Shopware, WooCommerce and BigCommerce. A 3PL can use any of these integrations out-of-the-box, which can deliver savings right from the outset.
Some IT departments are set up as profit centres, so it is in their interests to make projects wash their own faces. But even for these operations, Codept can still be exploited to their benefit - by charging the same fees, but delivering integrations more rapidly, they can in fact grow their margins. In addition, Codept also handles all of the support and maintenance, and all of the technical updates to these integrations, which, for an established fulfilment operation, will be a significant overhead, often with its own full-time dedicated team. Consider that Shopify provides quarterly software updates; for a 3PL with then Shopify merchants, that becomes an annual exercise alone of 40 individual maintenance updates. With Codept, all of this pain, and concomitant cost, are taken away.
Three years ago, when eCommerce was peaking during the Covid lockdown, life was good for 3PLs; they could pick and choose which contracts they wanted. Things are rather different today, however; many 3PLs have excess capacity, merchants on a geometric growth path are fewer and further between, and competition for their business is fierce. Companies that had previously only targeted Enterprise businesses are now dipping down to engage with mid-sized merchants. With warehouses needing to be filled and fewer merchants looking to expand, 3PLs need all the help they can muster right now. All 3PLs are, in fact, lowering their minimum order values, and lower order values always mean lower margins, so streamlining operational costs is one of the main focuses of 3PLs at this moment.
In conclusion, Service Oriented Integration has the ability to transform the IT landscape in logistics. IT is usually a cost to any business, so if you can do anything to reduce these overheads, this should be welcomed. Some 3PLs that have adopted the Codept Platform have reduced their integration costs so much, they can now offer free onboarding to new merchants in their sales pitch. And if a salesperson is able to quote lower integration fees (or even offer them free of charge) and against better timelines, merchants would be foolish to turn this down. Now, that must be a valuable sales tool in their arsenal in today's challenging environment.
An Introduction to Logistics Fulfilment Integration
Whenever an eCommerce merchant decides to outsource its fulfilment to a 3rd party Logistics Provider (3PL), a technical integration project is needed, to ensure that all orders from the merchant's shop system are transferred reliably and swiftly to the new 3PL's Warehouse Management System (WMS) so they can piclk, pack, print labels and dispatch effectively, getting the product to the customer as quickly as possible.
Every eCommerce merchant uses a shop system - Shopify, WooCommerce, NetSuite, and many more besides; every 3PL has a WMS - Manhattan, BlueYonder, SAP, SNAPFulfil and so-on; and every integration project connects these two systems together.
Onboarding new Merchants - The Issues
Onboarding new merchant employees is an essential and necessary part of the fulfilment process. And this is often difficult. Why? Because many companies' IT integration teams still work with traditional and inflexible process-oriented methods or use non-specialized integration tools that, while proven and reliable, are time-consuming and expensive. Additionally, developing only individual, private one-to-one integrations for each new customer creates a complex structure with multiple points of friction that slows everything down and needs to be kept up-to-date at all times.
As mentioned, it's an unavoidable part of the process. And it's often also a painful process. Why? Because many companies' IT integration teams are still using traditional and inflexible process-oriented methodologies, or use non-specialised integration tools, both of which, although tried, tested and reliable, are time-consuming and expensive. Add to that an entrenched mindset that only creates single, one-to-one private integrations for every new customer, and you have an almost perfect storm of friction that slows down everything.
And herein lies the tension; many swiftly-growing and fleet-of-foot eCommerce merchants approach 3PLs to help handle their rapid growth, and expect onboarding to be equally agile, taking perhaps a few days - only to be informed that this may take 4-6 months, sometimes much more, and also cost an arm and a leg to boot. Even integrating simple shop systems can turn into unexpectedly long engagements. 3PL salespeople often complain of losing deals as soon as they quote the extended effort estimate and costs associated with onboarding. Equally, merchants complain of inexplicably lengthy timescales and costs quoted by 3PLs that simply jar in their fast-paced, agile world.
That both the methodology and the mindset of creating a mass of individual one-to-one integrations bring their own issues, of ongoing upgrades, support and the maintenance of all of these interfaces, not to mention the associated costs, is reason enough to rethink how to build them entirely. Certainly for IT staff, creating the same integrations from scratch each and every time must be a dispiriting Groundhog Day experience for them. Developers would rather be involved in more creative and interesting projects, and many are reluctant to take roles that only offer this type of work. Recruiting and retaining IT staff in the logistics world is a well-documented issue, and it's now not difficult to ascertain why.
Whilst there is a phalanx of integration tools on the market (much of which is lumped into the Integration Platform-as-a-Service (iPaaS) category) purportedly to make life easier, they are neither specialists in the complex world of eCommerce logistics, nor do they obviate the necessity of building private-label integrations in the first place. The diagram below shows the difference an iPaaS tool makes to an IT team - very little, in fact. The only significant difference is that writing code to talk to an API is replaced by creating mapping using the iPaaS software tool.
The remaining process steps still have to be taken, which results in very little time being saved, but paradoxically creates an ever-expanding list of integrations that require ongoing maintenance and support. We are still following traditional development methodologies and IT project processes, with no discernible effort or cost reductions; indeed, we now have the added license fee of the iPaaS tool fees for the API calls that are often charged on top.
What Is Service Oriented Integration?
Codept has pioneered a new and innovative paradigm to address the friction that exists in the existing set-up. The Service Oriented Integration model tackles the issue from a different perspective, and, as a result delivers a different and far more efficient solution. The overriding principle of Service Oriented Integration is that, instead of viewing all projects as individual engagements that re ring-fenced and not to be used anywhere else, the IT team instead can use pre-built services that can be assembled rapidly and re-used regularly on any new projects - which is at once innovative and practical, given that many of the requests between systems are the same, regardless of the shop system or the WMS in use.
A "service" in this respect is what can otherwise be referred to as calls or flows between the shop system and the WMS. They are usually API-based, though not exclusively so (they could also use .csv, XML, EDI, (S)FTP formats), but they incorporate all of the expected calls that a WMS needs to fulfil an order; sales order, dispatch, shipment notification, stock update, cancellation, and so-on. Different shop systems have their own ways of working, but fundamentally their outputs - sales orders - as already mentioned, always need to produce the same data to enable the WMS to fulfil on their behalf.
Services are built upfront, enabling merchants to be onboarded extremely rapidly. And, this standardised Integration model can also be tweaked or customised, also enabling merchants with custom requirements to be accommodated easily within this model. Importantly, many integrations have already been built into the Platform, and they can be used by any company immediately. Codept's Self-Onboarding interface to Shopify in fact does this automatically, and new merchants can be onboarded in as quickly as 10 minutes.
Brand new connections to less-popular shop systems only need to be built once; they are always designed from the outset to be reused, and not just specifically for one customer. And, as long as this initial design step is done well, it massively reduces effort, time and cost for all future deployments of this integration. The interface becomes a "plug-in" tool that requires little or no tweaking on subsequent integration projects, which obviates the need to build and then maintain and constantly upgrade multiple private label integrations, also allowing 3PLs to leverage previously built for other customers.
The Service Oriented Integration model embraces the principles of multi-tenant SaaS, of reusing core product core and adding a layer that allows a core module to be customised to meet individual customer requirements, but still remain part of a commonly shared, reusable service. The benefits include a significant reduction in development effort and costs, a decrease in upgrade and support and maintenance costs, and a much-reduced time to value for merchants. In the high-speed world of eCommerce, the time harvested back from this approach becomes a valuable commodity that can make the difference between winning or losing an account.
The diagram below outlines the Codept model, which is useful in determining the difference between Codept's Service Oriented Integration model and iPaaS integration tool models.
Why Isn't This Model More Widely Adopted?
The big question is: why don't more organisations adopt this model? Quicker, more efficient, cheaper, enabling more sales, easier to support and maintain, the list of benefits goes on.
Well, it requires a specific developer skillset, one that can recognise which elements of an integration project may be reused, and then how to build something in such a way that enables it to be reused flexibly in the future. The benefits of a more considered approach are manifest when subsequent implementations are required; these take considerably less time to configure, as the common services are already set up, and work is only required for any custom components. And, because you are reusing common shared services, they are also much easier to maintain and upgrade.
But it also requires a specific mindset, of agility, flexibility and speed, which does not always marry well with other traditional orthodox methodologies that so many experienced technology experts have grown up with and have embraced as the best way to run projects. This mindset is somewhat entrenched in many larger organisations with long-established highly centralised IT departments.
The traditional IT project methodology, called Waterfall, or writing a technical specification, signing that off and then following that specification rigorously, and with change requests from clients at every step needing authorisation, has worked for many years. But the Waterfall approach, as well as being time-consuming and expensive, is also blinkered insofar as it is designed to handle individualised private-label integration projects. Service Oriented Integration requires consideration of other projects, so that services can be successfully shared between clients - so the overall approach needs to be more holistic, and less individualised. This agility and flexibility is the essential mindset we are referring to.
Many 3PL organisations may not realise they have a problem. When they win tenders, they are able to deploy new integrations that merchants are happy to pay for and patient enough to wait for. They use a trusted methodology to run integration projects, and they generally succeed, more or less.
But how many deals do 3PLs lose by quoting implementation fees and timelines that merchants find excessive? Ask a salesperson, and they will tell you plenty of stories of frustration and loss. If there were an alternative way of building integrations, which decreased costs and timescales for all concerned, it would be germane to explore, surely?
The Codept Platform Approach
Codept has pioneered the Service Oriented Integration approach outlined above, using the Codept Integration Platform. Services are shared rather than individualised, so multiple merchants can use the same integration service calls - meaning that onboarding a new merchant into their WMS environment takes a fraction of the time compared to following traditional integration methodologies, leading to shorter time to value for the merchant - as already mentioned, a valuable commodity to be able to offer. The Codept technical team has adopted a highly agile development approach, but, using this shared model, the "new work" components are smaller and easier to complete.
For companies that provide eCommerce contract logistics, by adopting Codept as their Integration Platform, they are also able to leverage other integrations that are already built into the Platform - that alone delivers substantial savings; there is no starting from scratch here. The Codept Platform already supports all of the major shop systems, such as Shopify, Shopware, WooCommerce and BigCommerce. A 3PL can use any of these integrations out-of-the-box, which can deliver savings right from the outset.
Some IT departments are set up as profit centres, so it is in their interests to make projects wash their own faces. But even for these operations, Codept can still be exploited to their benefit - by charging the same fees, but delivering integrations more rapidly, they can in fact grow their margins. In addition, Codept also handles all of the support and maintenance, and all of the technical updates to these integrations, which, for an established fulfilment operation, will be a significant overhead, often with its own full-time dedicated team. Consider that Shopify provides quarterly software updates; for a 3PL with then Shopify merchants, that becomes an annual exercise alone of 40 individual maintenance updates. With Codept, all of this pain, and concomitant cost, are taken away.
Three years ago, when eCommerce was peaking during the Covid lockdown, life was good for 3PLs; they could pick and choose which contracts they wanted. Things are rather different today, however; many 3PLs have excess capacity, merchants on a geometric growth path are fewer and further between, and competition for their business is fierce. Companies that had previously only targeted Enterprise businesses are now dipping down to engage with mid-sized merchants. With warehouses needing to be filled and fewer merchants looking to expand, 3PLs need all the help they can muster right now. All 3PLs are, in fact, lowering their minimum order values, and lower order values always mean lower margins, so streamlining operational costs is one of the main focuses of 3PLs at this moment.
In conclusion, Service Oriented Integration has the ability to transform the IT landscape in logistics. IT is usually a cost to any business, so if you can do anything to reduce these overheads, this should be welcomed. Some 3PLs that have adopted the Codept Platform have reduced their integration costs so much, they can now offer free onboarding to new merchants in their sales pitch. And if a salesperson is able to quote lower integration fees (or even offer them free of charge) and against better timelines, merchants would be foolish to turn this down. Now, that must be a valuable sales tool in their arsenal in today's challenging environment.
Free Case Study
Join our mailing list for the latest news
