.wilk

Day 2 did not seem as busy as day 1, but I would still grade attendance as healthy. Some vendors said they had hoped for more attendance, but there seemed to be a correlation between an exhibitor's happiness with the conference attendance and the quality of their product - go figure.

In an age of application architectures dominated by loosely-coupled services, I was surprised by how tightly coupled commerce is to content management. Some vendors' products are closely bound to ERP solutions as well, but that's a business decision. There are enough API's and middleware available that there should not be a technical reason to be tightly bound to a single ERP solution. However, the bond between CMS and commerce is more fundamental. At first I attributed this fact to a business decision; I would want to sell the complete solution as well. But some vendors were willing to give up a sale instead of giving up their CMS defense. I then decided it was maturity - or lack of it. Like a 16 year old who truly believes they are invincible, developers come to believe that CMS and commerce are basically the same; cataloging objects is cataloging objects. But this only fits at the most foundational level. As product sophistication grows, you find that the use cases and intents of each platform diverge. True, they share common subsystems at a macro level, like personalization and behavioral analytics, but these are specialized subsystems in their own right, much like authentication, logging and CRM. After talking to some respected people who have been building commerce and CMS solutions almost as long as I have, I decided that maybe I didn't get it. Maybe there was more to this tight coupling than I realized.

The most compelling argument for tightly coupling the Commerce engine with the CMS describes the CMS as the rendering engine for the solution, and commerce provides specialized content to the rendering engine. O.K., I'll bite; I'm an MVC kinda guy. Assuring separation of concerns assists in the creation of reliable and adaptable technology products. The justification for tight coupling places the CMS at the top of the architecture diagram (why is the UI always at the top? I think it's a northern bias). The CMS sits on the front end, does it's thing delivering dynamic content, and it provides the view engine for rendering. When commerce content is required, the commerce engine delivers the specialized content as needed. Um... Or in North Carolina vernacular, that dog don't hunt.

First, separation of concerns drives the architecture towards loosely-coupled components, not away from them. Multi-channel solutions almost require loose coupling of the UI. Second, if the CMS is the view engine, why are the CMS products ladened with business, personalization and marketing logic. Third, if the commerce engine is providing content to the view engine, commerce should be providing a view model. Instead, the commerce engines in question are delivering templated pages or partial page to the CMS.

The argument for a flexible view engine served by specialty application engines has merit. In fact, if eCommerce and CMS were less mature markets, I would be tempted to create a MVCesque solution that embraces this model. But the products providing this UI front-end justification do not deliver the architecture they promote. Worse, other vendors are promoting tightly-coupled commerce and CMS solutions without an understanding of why their product is tightly-coupled.

What does all this mean? Can you get a commerce solution independent of a content management solution? Yes, absolutely. And most vendors promoting a tightly coupled solution will sell you just the commerce piece if you want. After all, the customer is still always right. But you should consider CMS and commerce as a holistic solution. Even if you are not thinking of your commerce solution as tightly coupled to content, the software product manufactures are thinking tightly coupled. When selecting a commerce solution, you may be impacting your future content choices or visa versa.