Sylleptic

(This is a piece I wrote for the retail solutions conference guide.)

If you’re a retailer or a consultant involved in choosing an e-commerce solution, the approach you take, and in particular where to start the process, is critical. You might start with a decision on the underlying application server (Microsoft or Java, for example). Some look for something that fits well with a system they already have (like their ERP or warehouse management system), or with a “must-have” application or consumer offering, like facet-based navigation. Others start from the ownership or implementation model: are you looking for a hosted solution or something you can host and support yourself? Perhaps you would like your own unique instance of the application you can adapt totally to your needs? Do you need to be live in 12 weeks, or will you be doing a detailed analysis and customisation project? Subjective feel about fit with the vendor or vendors often carries a lot of weight, and budget is always a deciding factor.

In practice, many people come out of this process with a solution that is quite complex: the level of flexibility and integration offered by many products today, and the long lists of existing integrations seen in so many vendor presentations make choosing a hybrid solution a normal outcome. This raises some difficulties that must be considered when choosing the partner or partners who will deliver the project, but it also raises some real issues about the nature of the solution for the people who have to operate it once it is live.

The problems around project delivery relate to responsibility and complexity. Let’s say you’ve chosen a search product, a base commerce application, an image and video delivery tool, and a payment service provider, and you need integration with your existing warehouse and ERP. Who’s going to take responsibility for making all of those pieces fit together? Do you have the right people in-house to do the complex technical management that’s required, or will you use a consultant? Will you appoint one of your vendors to manage the overall implementation? Who will lead and manage end-to-end testing of the fully integrated solution? If you don’t consider this basic governance and accountability, problems are certain to arise. Aside from these questions, you need to consider who will manage the technical integration of all the pieces. All sorts of different interfaces are required between systems: these need to be specified, developed (or adapted from existing ones) and tested. Someone needs to make sure all the interfaces click together. This isn’t trivial, and it seems it’s sometimes assumed to happen by collaborative means: our experience is that it’s a lot simpler and a lot less risky for all partners if one party to the project is explicitly identified as being the lead for management, integration and verification of the solution.

If you’ve completed a successful multi-vendor e-commerce project, there remain questions about the integration of management tools, and their impact on the efficiency of your back office. I was recently at a presentation for a site content personalisation tool, and it became clear that whatever the benefits the tool had in terms of user experience, conversion and basket value, it was going to make the retailer’s management task a lot more complex. When a retailer chooses different vendors for different parts of the solution, it adds many steps to the management processes. Workflow for these tasks sometimes seems to be under-played in solution definition, and end-to-end documentation and testing seem to get lower priority than they ought. Let’s take  the  example of adding a new product and putting it on promotion – this really should be quite simple and yetthe merchandiser might have to use the base commerce platform, the search management console, and an image management console to get everything up and running.

This is a problem that some of the big vendors with a comprehensive offering would suggest they have the answer for: if you buy their product, it all fits together, and all the tools are integrated, so management is easy. It’s worth remembering that several of these products have been built by acquisition, and weren’t designed in an integrated way, so the reality may not be what is promised in the literature. We would recommend customers to choose a base product, like Microsoft Commerce Server, that works well for most of their requirements, and only add to it in really high value areas: most people should challenge customisation and additional complexity wherever it’s introduced into a solution.

In the longer-term, we would expect much easier integration between all the diverse products that are on the market. The evolution of web services as a standardised and flexible way for applications to talk to each other already makes it easier for applications to integrate in many ways. For example, putting data into the big search products today is a matter of generating some XML from your product catalogue and firing it into the index server. We’ve built our own management tools on top of web services so that they can be integrated and re-used in all sorts of ways, but it would be really exciting if we could integrate the management tasks of multiple vendor products in this way: as vendors expose more of their management capabilities to systems integrators as web services, we should be able to turn my new product example into a single page transaction in the future.

E-commerce continues to be an exciting and innovative space to be involved in technically, so we can expect to see a host of ideas coming forward to manage complexity, both in project delivery and management of the solution once it’s live, in the coming years.