Using external services in eCommerce

What were the key factors in determing which eCommerce solution you decided to go with?  Probably in no small part you looked at functionality - whether out of the box, or by way of extensions.  But, perhaps the functionality offered by a particular framework shouldn't be such a driving factor, and maybe fitting your business model exactly isn't as important as you might think.

This probably sounds like a silly thing so say.  Of course your eCommerce solution should fit your business requirements as closely as possible, surely that goes without saying.  Well, yes that's absolutely true, but lots or perhaps even most of the functionality you need doesn't neccessarily have to sit inside your eCommerce framework.  And in fact to future proof your business it can actually be preferable for it not too.

There's really two different views to this discussion and neither is wrong as such, it's more about getting your preferred balance of versatility compared to complexity.  One of the one hand you have a store where most of the functionality required for your business has been added to your eCommerce framework codebase, then on other hand you have a store where most of that functionality uses exernal services.

With the setup where business functionaliy has been developed primarily inside your eCommerce framework, you gain with simplcity.  Everything's in one place, it's easy to switch between tasks and you can much more easily compare data sources - and even build logic to do this for your automatically.

However with this setup you lose on versatility.  You're basically pretty much locked into using your eCommerce framework long term because there's so much invested interest there.  You never know what the future will bring for your business, particularly considering the ever-changing nature of eCommerce.

Imagine if the future brings a compelling business case for changing to a different eCommerce framework?  In this case think about just how much functionality would lost, and need to be replaced in the new framework, or using external services.

Here past decisions of developing functionality inside your eCommerce solution will have created a situation where you face significant investment in porting functionality to an alternative solution, and this makes it hard to go forward with the changes that really make sense from a business perspective.

So by developing within your eCommerce framework, you can get to the situation where you actually block the forward progress of the business in the future.

While it can make complete sense, even considering the possible future of the business, to have functionality sit inside your eCommerce framework, for many things it makes a great deal of sense to use an external service which then integrates with your eCommerce solution.  In this case, you gain when it comes to versatility, but lose when it comes to complexity, just because you have a number of systems to consider and manage, as opposed to having a single point to access everything.

However, the trade-off of added complexity is one that is very often worth it, and actually doesn't end up being a trade-off at all.  That's often because the added complexity of multiple systems, also brings with it greater specialisation.  So by using external systems, you also get greater specialisation and better functionality in managing that particular area of your business.

Now if we consider the same compelling business case for changing to a different eCommerce framework, we can easily imagine how much simpler it's going to be.  Now that we have lots of business functionality managed in external services, all we really need to worry about is migrating the relevant data from the current eCommerce framework to the new one, and there are plenty of services that can do this for you.

Generally, I like to recommend a 'light touch' approach when considering the functionality your eCommerce framework is responsible for.  What I mean by that is just that it can often offer the best long-term benefits if you stick pretty closely to out-of-the-box functionality for your eCommerce framework.

Doing this largely levels the playing field between different solutions on offer, making a migration from one framework to another much simpler.  Also with popular external services, it's very likely that there'll be direct integration with all the main eCommerce frameworks meaning that all external services can be integrated into the new framework with ease, and continue to be used the same as before.

In programming, there's a concept called being 'loosely coupled', which basically means that when you design a system, you want to build it so that one area of the system has very little direct dependency on other areas.  Designing something like this gives you the versatility to alter or even remove one area of the system without affecting overall functionality.

This is effectively the concept we're going for here - to have the various elements of your eCommerce business work independently of each other.  It gives you the ability to swap out, or replace the functionality of any single area of responsibility easily, and with minimal, or even no impact on other areas.

Looking at the wider picture like this, it's easy to see the benefits of segregating the different areas of responsibility of your eCommerce business across various relevant services.

So to conclude, my general recommendation here is to carefully consider what the best solution is going to be for any single business requirement.  Think about what you need to achieve right now, but also give real thought to the possible future direction of your business and the requirements that could introduce.

Having the versatillity to take your business in the right direction without being tied down to a single software solution gives increased possibilities, and invests in the future.  So whatever you might feel right now about where your business could be in 5 or 10 years time, the benefits of segregating the the different areas of responsibility across different solutions shouldn't be ignored.

Thanks so much for for reading, and I'd love to hear your thoughts on this in the comments.  See you next week!