The document discusses the complexities of multi-store versus multi-instance ecommerce, highlighting the challenges of customization and deployment in both models. It presents use cases and the importance of efficient tooling and architecture to manage product catalogs, user roles, and front-end design effectively. The conclusion emphasizes that while multi-store options are available, they may not be suitable for every business, underscoring the need for careful planning and execution.

1. “Multi Store” eCommerceMaking Good DecisionsMatthew BertulliCo-Founder & President @mbertulli

2. AgendaIntroductionMulti-Store vs. Multi-License Overview“Heavy Hitters”Questions you as developers should be asking in order to find toolset fit.Use CasesWhere do I get all of this stuff from?Technical Analysis and ComparisonsTools, Database, Core Code, Front-End “The Pretty”Q&A / Discussion

3. 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

4. “Multi Store” OverviewTwo Viable ModelsMulti-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.

5. 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?

6. Heavy HittersWhat 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?

7. Use Case – Multi-Store (MLx)Case #1: Multi-Store Deployment5 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.

9. Use Case – Multi-InstanceCase #2: Multi-Instance DeploymentCurrently 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.

11. Maintenance – MI / MSDeveloping your own build and deployment process. Our Tooling:SVN over GIT / MercurialCruiseControl.NET & MSBuildAutomated 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 CompareAutomationTransfer of new DLLs / patches / files to various web servers. Database changes - RPITA

13. Database – Schema Differences

14. Database – Multi-InstanceMultiple 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).

15. What maps well? - MSThe following have default mapping structures and an interface to make the mapping happen. What’s missing?AffiliatesCategoriesCouponsGift CardsManufacturersNewsTopicsOrder OptionsProductsDepartmentsShipping MethodsString Resources

16. Mapping Challenges - MS Customers / UsersThis 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 LevelsIf you have a wholesale only store with wholesale customer levels, those same levels will apply to all stores.

17. Product Catalog - MSYou can map products to stores, but you can’t do much past that natively.The Big One: PricingPrice, Cost, Sale Price, Volume Pricing, Customer Level PricingML 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: ContentMany 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?

18. Notice there is no “Store” paramater.

19. Product Catalog - MIBig Challenge – You have dozens of database instances to push / replicate data into. Our ApproachWe 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.

20. Users / Roles and Store Management - MSSame Company, Different Divisions (Split Resources)Not so nice a fit with Multi-Store LicenseSame Company, Shared ResourcesFits nicely with Multi-Store LicenseMultiple CompaniesYou’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.

21. Front-End “The Pretty” - MSASPDNSF 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.aspxCheckout 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.

22. Front-End “The Pretty” - MIOrganization & Structure to your code is keyEach 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.

23. ConclusionMulti-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