Content and Commerce: a big opportunity for DrupalDriesThu, 11/10/2016 - 16:08Last week Acquia announced a partnership with Magento. I wanted to use this opportunity to explain why I am excited about this. I also want to take a step back and share what I see is a big opportunity for both Drupal, Acquia and commerce platforms.
State of the commerce market
First, it is important to understand what is one of the most important market trends in online commerce: consumers are demanding better experiences when they shop online. In particular, commerce teams are looking to leverage vastly greater levels of content throughout the customer's shopping journey - editorials, lookbooks, tutorials, product demonstration videos, mood videos, testimonials, etc.
At the same time, commerce platforms have not added many tools for rich content management. Instead they have been investing in capabilities needed to compete in the commerce market; order management systems (OMS), omnichannel shopping (point of sale, mobile, desktop, kiosk, etc), improved product information management (PIM) and other vital commerce capabilities. The limited investment in content management capabilities has left merchants looking for better tools to take control of the customer experience, something that Drupal addresses extremely well.
To overcome the limitations that today's commerce platforms have with building content-rich shopping experiences, organizations want to integrate their commerce platform with a content management system (CMS). Depending on the situation, the combined solution is architected for either system to be "the glass", i.e. the driver of the shopping experience.
Drupal's unique advantage for commerce
Drupal is unique in its ability to easily integrate into ambitious commerce architectures in precisely the manner the brand prefers. We are seeing this first hand at Acquia. We have helped many customers implement a "Content for Commerce" strategy where Acquia products and Drupal were integrated with an existing commerce platform. Those integrations spanned commerce platforms including IBM WebSphere Commerce, Demandware, Oracle/ATG, SAP/hybris, Magento and even custom transaction platforms. Check out Quicken (Magento), Puma (Demandware), Motorola (Broadleaf Commerce), Tesla (custom to order a car, and Shopify to order accessories) as great examples of Drupal working with commerce platforms.
We've seen a variety of approaches to "Content for Commerce" but one thing that is clear is that a best-of-breed approach is preferred. The more complex demands may end up with IBM WebSphere Commerce or SAP/hybris. Less demanding requirements may be solved with Commerce Tools, Elastic Path or Drupal Commerce, while Magento historically has fit in between.
Additionally, having to rip and replace an existing commerce platform is not something most organizations aspire to do. This is true for smaller organizations who can't afford to replace their commerce platform, but also for large organizations who can't afford the business risk to forklift a complex commerce backend. Remember that commerce platforms have complex integrations with ERP systems, point-of-sales systems, CRM systems, warehousing systems, payment systems, marketplaces, product information systems, etc. It's often easier to add a content management system than to replace everything they have in place.
This year's "State of Retailing Online" series asked retailers and brands to prioritize their initiatives for the year. Just 16% of respondents prioritized a commerce re-platform project while 41-59% prioritized investments to evolve the customer experience including content development, responsive design and personalization. In other words, organizations are 3 times more likely to invest in improving the shopping experience than in switching commerce platforms.
The market trends, customer use cases and survey data make me believe that (1) there are hundreds of thousands of existing commerce sites that would prefer to have a better shopping experience and (2) that many of those organizations prefer to keep their commerce backend untouched while swapping out the shopping experience.
Acquia's near-term commerce strategy
There is a really strong case to be made for a best-of-breed approach where you choose and integrate the best software from different vendors. Countless point solutions exist that are optimized for narrow use cases (e.g. mobile commerce, marketplaces and industry specific solutions) as well as solutions optimized for different technology stacks (e.g. Reaction Commerce is JavaScript-based, Magento is PHP-based, Drupal Commerce is Drupal-based).
A big part of Acquia's commerce strategy is to focus on integrating Drupal with multiple commerce platforms, and to offer personalization through Lift. The partnership with Magento is an important part of this strategy, and one that will drive adoption of both Drupal and Magento.
There are over 250,000 commerce sites built with Magento and many of these organizations will want a better shopping experience. Furthermore, given the consolidation seen in the commerce platform space, there are few, proven enterprise solutions left on the market. This has increased the market opportunity for Magento and Drupal. Drupal and Magento are a natural fit; we share the same technology stack (PHP, MySQL) and we are both open source (albeit using different licenses). Last but not least, the market is pushing us to partner; we've seen strong demand for Drupal-Magento integration.
We're keen to partner with other commerce platforms as well. In fact, Acquia has existing partnerships with SAP/hybris, Demandware, Elastic Path and Commerce Tools.
Conclusion
Global brands are seeing increased opportunity to sell direct to consumers and want to build content-rich shopping journeys, and merchants are looking for better tools to take control of the customer experience.
Most organizations prefer best of breed solutions. There are hundreds of thousands of existing commerce sites that would like to have more differentiation enabled by a stronger shopping experience, yet leave their commerce capabilities relatively untouched.
Drupal is a great fit. It's power and flexibility allow it to be molded to virtually any systems architecture, while vastly improving the content experience of both authors and customers along the shopping journey. I believe commerce is evolving to be the next massive use case for Drupal and I'm excited to partner with different commerce platforms.
Special thanks to Tom Erickson and Kelly O'Neill for their contributions to this blog post.
Comments
Thanks for sharing, Dries! My perspective on the partnership is colored by my long history of promoting native eCommerce solutions within the Drupal community (and with Commerce 2.x we're pushing hard to be more competitive with dedicated commerce applications out of the box), but I think your strategy w/ respect to winning over existing Magento users is clear / commendable and still points to the opportunity for Drupal Commerce.
I would've shared this assessment even before your partnership was announced for the key reason you mention in the post: re-platforming can be a tough pill to swallow, and even if you are committed to it (that 16% still represents thousands of merchants), the fewer integrations you have to rewrite between your eCommerce application and the various back-end services you depend on for order management, fulfillment, reporting, etc. the better. Every dollar you save on what is purely a cost (i.e. rewriting integrations, absent scalability or other performance issues) you can invest in future revenue by creating a more appealing, engaging experience on the front end.
That said, maintaining separate applications side-by-side will itself increase your technology costs (e.g. hosting, software updates, developer training, etc.), so I believe in a future where Drupal Commerce is sufficient for more use cases and easily scales to meet the demands of the largest merchants. It's great for digital commerce, for event sites, for selling user generated content, etc. (essentially, for verticals where the content *is* the product) - and it's a decent foundation for building robust D2C brand sites (e.g. lush.co.uk or the more recent obermeyer.com) and highly custom business requirements. However, we know that we need to be more competitive both out of the box (esp. with regards to merchandising) and as an ecosystem (esp. with regards to order management / fulfillment), so we've prioritized addressing both of those during Commerce 2.x development.
While making Drupal Commerce an easy replacement for a third party eCommerce application is a long term goal, the short term opportunity is for merchants to use Drupal Commerce as a front-end for third party applications just as you are suggesting. Meaningful integrations will require structured representation of commerce data within Drupal, and there's no reason they shouldn't take advantage of the relevant Commerce modules and libraries, which were designed to be used in part and not just as a whole. For sites requiring currency / address localization, I'd almost say it's a requirement, and the libraries we built to handle this have been humming along in production environments for some time now. : )
You mention costs and software updates as something which argues against "separate applications side-by-side". I would argue those a absolutely minimal. To host a commerce solution you already need a huge stack of software/applications. One more does not add much to the total cost. That's even more true if one add the costs of development and not only the continued maintenance costs.
The cost of developer training depends solely on the longevity of the skills learned. If skills learned for one set of library/framework is viable for the next 5, 10 or 15 years then that has to factored into the equation. From personal experience I can say that the costs of having to relearn a framework is huge. There is a major undertaking both upfront and for several years when new bugs/problems surface. I've been following UberCart for a long time. We ventured into Drupal Commerce and felt a bit blindsided by that experience. Now Commerce2 is fronted as a "total rewrite" which really makes one wonder what has changed in the real world - tax rules (only tax rates has changed), discount calculations, price handling, currency handling, payment handling, order registrations (backend), order handling (backend), and more has not changed for the last 15-20 years. The presentation of information has changed quite a lot of course, and also so has user interaction, but the backend side of commerce has not changed.
What we experienced from UberCart to Commerce, and our fear is that going from Commerce to Commerce2 the backend again changes (a lot). Those of us who develop and maintain large commerce sites with a myriad of backend integrations (logistics, accounting, third party pricing-systems, giftcards, etc) are faced with a huge undertaking the day we have/want to upgrade a commerce site (UberCart -> Commerce -> Commerce2). The "upgrade" project is so large that we end up facing the same project costs as when we initially set up the commerce site. The result is that the customer might conclude that the best thing is to put out request for proposals on a new site. "A new site" is a pretty accurate description of every major Drupal upgrade and especially if the site is a commerce site with UberCart/Commerce/Commerce2.
We have just begun nibbling at D8. For us the most important thing when considering how to get out of the current Pressflow+UberCart and Drupal+Commerce stack will be how decoupled is the commerce backend from Drupal. If the next iteration of Drupal will again require huge amount of work on the commerce backend then that's not a good option at all. In my opinion an upgrade of the presentation of information (Drupal) should not touch the way prices are calculated or when tax is applied... Neither how orders are stored or handled. Just to give an example. Except for a few, most of our customers never touch an order in Drupal+Commerce. Orders and payments are handled and processed in their own ERP system. Some of those systems are 10+ years old. Some are even nearing 20 years. They still work and there is absolutely no need to upgrade or change system.
Drupal + Magento is something we have looked at earlier. Then we were in them midst of D7 + Commerce development. It will however be quite interesting to compare D8 + Commerce2 and D8 and a Magento stack next year. It will come down to how reusable is current Commerce code/modules with Commerce2 and what the planned life cycle of Commerce2 and (current version) of Magento be.
Great post Dries.
I'm flattered to see our innovative Drupal + Magento work with Quicken mentioned by you. Quicken is one of the earliest and largest Magento 2 stores launched in the world. We have built headless commerce with Drupal many times now, most recently with Quicken.com (headless Magento 2) and BenefitCosmetics.com (headless Hybris).
We are also thrilled to be partnering with you and Acquia on building this Drupal Magento integration by porting the work we have already done for many enterprise clients and bringing it into the Acquia stack. Exciting times!
TAG has been integrating best-of-breed commerce solutions with Drupal for many years. We recently shared our analysis of where we think the content and commerce space is going: https://medium.com/third-grove/the-death-of-drupal-commerce-as-an-ecomm…
We recently contributed the connectors we developed for Drupal and Hybris back to the community (https://www.drupal.org/project/hybris). These connectors -- like our Quicken work connecting Drupal and Magento -- are used today in production at enterprise-scale to power awesome shopping experiences with Drupal and headless Hybris. As our sponsorship of one of Drupal's six core maintainers (catch) shows, giving back to Drupal is very important to Third & Grove. And it's something we will continue to do as we continue our journey in the content and commerce space.
Thanks! Third & Grove also wrote modules for Drupal-Magento that bring in product information into Drupal, along with a variety of other features (hopefully releasing soon...).
In our recent projects with headless Hybris and headless Magento we haven't found a need for the Drupal Commerce components. We have found that Drupal itself is the most compelling unification layer. Our typical approach has been to keep in the commerce platform all the things commerce engines are good at (pricing, promotions, payments, etc) and to focus Drupal on what it's good at (content and engaging digital experiences). And herein lies the tension (we feel) with trying to use DC as the unification layer - DC is a commerce engine.
1. Abstraction layer - Because of Drupal 7's (and even more Drupal 8's) robust Entity (and other) APIs we have not found a need to leverage what the Drupal Commerce (DC) modules provide. Components like products and promotions become regular Drupal entities, and checkout flows tend to be custom so they are just Drupal page building. It's possible a Drupal Commerce component focused exclusively on checkout might be useful, at least as a starting point that can be customized.
2. Merchant optimized tools - Many of these tools are content driven so they are interacting with the website through the lens of content, not commerce platform components. Because the work of commerce is pushed to the commerce platform Drupal Commerce's components are less focused on the glass, and thus at less at play here. A good example is content personalization, which includes products because once they are in Drupal they are regular Drupal nodes. One potential area where DC may be able to play an important role is in price personalization.
3. Different channels - Say for example you have a headless Magento store that is powering commerce experiences on a website (Drupal) and in a mobile app (iOS). In our typical approach other channels would be going to Magento, not Drupal, in order to calculate discounts, get prices, and process payment. If the app needed some of the marketing content around products (that typically would be stored in Drupal) they would go right to Drupal for that (which has great support for this use case). In my opinion going through Drupal to talk to the commerce engine wouldn't be ideal from a performance, complexity, or level of implementation effort perspective.
Granted most of our clients are enterprise-scale, but in our projects we have had more success with a strict delineation between content information and commerce data. Our clients tend to organize their teams in this way as well - there tends to be a content team and a separate ecommerce/fulfillment team, so each only has to be trained and login into one system.
It would be good to see some strong case studies of Drupal + Magento as marketing collaterals for pushing the integration into the market. It would also be good to see a bit of analysis on what would be the best fits for the different scenarios for ecommerce merchants. Maybe a decision tree for different business use cases for business decision makers in ecommerce space.
I agree! So much so that this in the works ;) Third & Grove will be releasing information along these lines in three weeks. I will update here when we do.
Not sure I'd agree with the positioning of Drupal Commerce at the low end, particularly given that we used it to re-platform from a huge ATG install across Royal Mail Group (using the separate instances integrated via services approach as you mention in your reply to Robert).
The other key use case for Drupal Commerce was Eurostar, which required deep integration with content along with personalisation and segmentation which we couldn't find in any non-bespoke system. This was similar to an airline booking system (if more complex) and the checkout flow needed to adjust depending on various contexts (eg upsell tickets to a festival in your destination at the time you are traveling, part pay with various types of points, fewer steps when bookings are in high demand, A/B checkout flows).
Both of these examples are going back a very long way and doubtless the product landscape has improved (although I'd imagine finding Hybris devs is still a challenge and ATG still clunky and prohibitively expensive even for enterprise), but I'd hope that Drupal Commerce as a solution hasn't gone backwards with the advent of Drupal 8. I would position Commerce as for where you precisely don't want a separate 'web shop' (for which there are many solutions such as Magento etc.), but instead want a seamless context-driven experience between content and commerce. My expectation has always been that Drupal 8 and Commerce 2 would cement that and allow easier 'omni-channel' use via native services.
Thanks for taking the time to post this Dries. The Magento announcement last week caused a few waves in the Drupal community and I think it's very important for you to put this into context.
Having been heavily involved in some of the Drupal Commerce examples you mention in this post I have a strong belief that Drupal Commerce with Drupal as a single destination content and commerce platform is a very powerful and widely underrated solution. Since iKOS joined Inviqa I've had the benefit of working with some of the best Magento engineers around and this has allowed me to experience first hand where the short falls in content management are in these mainstream commerce platforms. I have also seen enough to know just how far we can push Drupal Commerce.
I like the phrasing you use - determining which platform is the "glass" when combining two systems. It's an important decision and often not an obvious one. Drupal 8 now being a capable decoupled system makes this a little easier as we can benefit from the full strengths of Drupal whilst maintaining the well respected back office capabilities of Magento.
I have huge respect for what Ryan, Bojan and the team have done with Commerce 2. It's so important for people to realise that the split of Commerceguys from Platform.sh did not and does not mean the death of Drupal Commerce - slow or otherwise. It's understandable that this massive effort in rewriting commerce and addressing many of the thing we learnt from D7 has taken a long time with a small core team. It's now time for those of us maintaining the supporting modules to step up and complete the picture.
As a long term partner of Acquia, Commerceguys and Magento we have interesting times ahead. Our approach is always to look at the business value our clients get from their systems rather that to dictate the solution that meets our interests. As you rightly point out replacing an commerce platform is not always possible so we need to be flexible in how we operate. I expect we will have the opportunity to bring in Drupal Commerce solutions in the future as well as continuing our efforts to bring Drupal and Magento closer together.
More case studies and success stories will benefit all of us against the strong competition in the market.