“Multi Store” eCommerce

Making Good Decisions

Matthew BertulliCo-Founder & President @mbertulli

Agenda Introduction Multi-Store vs. Multi-License Overview “Heavy Hitters”

Questions you as developers should be asking in order to find toolset fit.

Use Cases Where do I get all of this stuff from?

Technical Analysis and Comparisons Tools, Database, Core Code, Front-End “The Pretty”

Q&A / Discussion

Who is this guy?

10 or so years in eCommerce. Last “real job” was with NetSuite before starting Demac

Media ~3 years ago. Experience with digital goods sales, online event

registration and ticketing, b2c online retail, b2b eCommerce, multi-channel sales, and the nastiness that is eCommerce marketing.

Developer first, everything else second. Multi-Language (not just a .NET guys). Strong belief in use the right tool for the right job. Love the challenges of multi-store and multi-channel

eCommerce

“Multi Store” Overview Two Viable Models

Multi-Store is the true use of ASPDNSF Multi-Store version. V9 with more goodness.

Multi-Instance is using multiple ASPDNSF instances for multiple stores.

“Multi Store” eCommerce is extremely complicated. We have an hour and we won’t even scratch the surface.

My Hope I want to give you enough ammunition to

answer the following question when tackling “multi store” eCommerce:

Is it more work to customize ASPDNSF Multi-Store or build tooling and process for handling multiple ASPDNSF instances?

Heavy Hitters What exactly does truly map well in Multi-Store? Product Catalog Questions:

Same products, different merchandising per store? Different pricing per store? Different categories/structure per store?

Infrastructure! How are you going to be hosting? How are you handling deployment? Builds, fixes, testing, etc… Do you need to have different users have access to different

stores? Are you doing multi-store for multiple “separate” clients? How different is the purchasing process from store to store?

Same payment methods, same shipping methods? Do you know how these site are marketed / connected?

Use Case – Multi-Store (MLx) Case #1: Multi-Store Deployment

5 stores. 25 planned and 50 is the target. Lower traffic sites, higher order value. Single vertical server scaling. Deal with web farm

challenges if ever arise. Easier deployment of fixes on core code base. More difficult management of store-specific change

requests (lots of shared code). Pretty large product (200,000+ SKUs) catalog and even

larger set of meta data. Having this data in one repository has significant resource-based value.

Use Case – Multi-Instance Case #2: Multi-Instance Deployment

Currently 10 stores launched, 15 more planned, and 150-200 is the target.

Each store owned and operated by a different company. Each store integrated to one wholesale distribution ERP

system (Prophet21). Needed to be easier to make store specific

customizations. Deployments of core code fixes/patches is much more

difficult. Continuous Integration (CruiseControl and MSBuild are useful) Version control is important.

Multiple web and database servers hosting all of these sites.

Maintenance – MI / MS Developing your own build and deployment

process. Our Tooling:

SVN over GIT / Mercurial CruiseControl.NET & MSBuild

Automated builds of checked in code. CSS Compression, FTP Files, Copy Proper License Files Etc…

True local dev, staging server, and production server separation.

Red Gate SQL Compare & SQL Data Compare Automation

Transfer of new DLLs / patches / files to various web servers.

Database changes - RPITA

Database – Schema Differences

Database – Multi-Instance Multiple database instance deployments.

Dev, Staging and Production all look like this. Your data tooling must be a huge focus.

Replication / Sharing of data (think inventory).

What maps well? - MS The following have default mapping structures and an

interface to make the mapping happen. What’s missing?

Affiliates Categories Coupons Gift Cards Manufacturers News Topics Order Options Products Departments Shipping Methods String Resources

Mapping Challenges - MS Customers / Users

This is actually something that has been missing and can be an architectural challenge in single store scenarios. Which users have access to what? True Roles/Membership does not exist.

Customer Levels If you have a wholesale only store with wholesale

customer levels, those same levels will apply to all stores.

Product Catalog - MS You can map products to stores, but you can’t

do much past that natively. The Big One: Pricing

Price, Cost, Sale Price, Volume Pricing, Customer Level Pricing

ML 9 Makes price rule customization a little easier by consolidating everything into one Prices.cs class.

Note: If you’ve ever tried to customize pricing in source code you know there are a LOT of touch points.

The 2nd Big One: Content Many multi-store merchants will want to vary

their product catalog content per store. Part of this is SEO, part of it is merchandising differently for different types of stores. (i.e. – discount store vs. normal retail vs. private sale)

You could clone products, keeping a copy of each product in each store?

Notice there is no “Store” paramater.

Product Catalog - MI Big Challenge – You have dozens of database

instances to push / replicate data into. Our Approach

We developed an integration framework that allows us to setup a series of integration “jobs” for each store. These jobs do things like: Update Inventory every 15 minutes from ERP system. Process Orders from www.store.com to ERP system. Copy catalog of products to each store daily.

This works for us, but doesn’t mean it works for everyone.

Use of Red Gate tools may allow for easier data replication across instances in some cases.

Users / Roles and Store Management - MS Same Company, Different Divisions (Split

Resources) Not so nice a fit with Multi-Store License

Same Company, Shared Resources Fits nicely with Multi-Store License

Multiple Companies You’ll be coding quite a bit to make this work. Locking down sets of data based on user access is not

an easy architectural problem to solve. Let alone in code.

Front-End “The Pretty” - MS ASPDNSF has always been good at multiple skins/templates

for different uses (think holiday season skin).

Each store should share the same core .aspx pages. You want to watch out for those pages that don’t depend heavily on XMLPackages/Skins for display / markup. ShoppingCart.aspx Checkout Pages (checkoutshipping.aspx, checkoutpayment.aspx,

checkout1.aspx)

You can have separate skins / templates for each store. Pretty obvious one and very necessary. Method depends on V8 or ML code base.

Front-End “The Pretty” - MI Organization & Structure to your code is key

Each store is a customized version of an existing “Skin” that we pre-designed and developed.

We create Skin_#### for each variation where #### is our client ID in the warehouse system.

Leverage version control tools heavily to deal with branching, merging, conflicts and common code.

Conclusion Multi-Store is a tough nut to crack, especially

for the small to mid sized online merchant. Maintenance is the problem. Good Architecture is

the answer. The right tooling can save you a lot of time and

headache. Just because multi-store platforms exist, doesn’t

make them the right choice for everyone.

Q&A / Discussion