A Service Architecture Approach to Ecommerce
January 27, 2014 - Best Practices
When it comes to ecommerce, one size does not fit all. Since 2007, we’ve been building a flexible ecommerce solution for develpers and have come across just about every possible need you can imagine. The number of different ways people want to sell things online is mind-numbing. Trying to fit that all into a “turnkey” solution rarely works. Instead, we’ve found the best approach is often to use the best of breed solutions working closely together in a service oreiented architecture (SOA).
What’s SOA? From Wikipedia:
Service-oriented architecture (SOA) is a software design and software architecture design pattern based on discrete pieces of software providing application functionality as services to other applications. This is known as Service-orientation. It is independent of any vendor, product or technology.
There are many pieces specific to the client’s business model which have to be adjusted for a successful ecommerce project. These include the website components, catalog, inventory, user system, CRM, analytics, affiliate and email marketing, payment gateways, merchant accounts, alternative payment systems, order management, accounting, dunning, reporting, and fulfilment. There’s also the cart experience, downloadables, recurring payments, taxes, shipping, anti-fraud tools, discounts, and PCI compliance.
It’s impossible for one company or one technology to be the industry-leading expert in all those different requirements. Your ecommerce solution is never going to have the best content management system or analytics packages. Existing companies and open source solutions focus all of their effort on perfecting these technologies and continually make improvements to them.
The key is to focus on where you need flexibility. Is it in reporting? Inventory management? The cart and checkout experience? The order fullfillment? Each of these needs come with their own challenges and have their own definitions of flexibility. By thinking of each system as a separate service, you’re free to customize or replace each tool independantly, as long as the tools can integrate with each other effectively. If they are tightly coupled or worse, built within the same technology, you options are severly limited.
When we built FoxyCart, from day one we decided we were not going to be a content management system. As developers, we liked using tools like MODx to build sites exactly how we wanted them. We didn’t want to be limited in what we could accomplish for our clients. We also didn’t want to maintain two websites by building a store site in an inflexible system and a content site in the tools we enjoy. By treating each as a separate service, we were able to add ecommerce to existing websites and, after each transaction, work with the data directly to update whatever system needed it. We avoided duplicating data by not maintaining inventory in the system, but instead relied on the website to interact with inventory as a separate service.
This approach provides flexibilty because each part is doing what it does best. This is how you win online. Your vision shouldn’t be hindered by inflexible tools.
To learn more about a service architecture approach to ecommerce, check out php[architect]‘s eCommerce summit this Thursday, January 30th. Tickets are still available. I’ll be speaking along with 3 others with topics including eCommerce Content Management, Using and Learning From Stripe, and PHP eCommerce Evolution: Then, Now, the Future.
I hope to see you online this Thursday!