AspDotNetStorefront offers multiple licensing options for e-tailers. Which method you choose depends largely on architecture. How you choose architecture is based on a very large amount of variables. These are the slides I went through at the 2011 AspDotNetStorefront eCommerce conference.

1. “Multi Store” eCommerce Making Good Decisions Matthew Bertulli Co-Founder & President @mbertulli

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

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

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

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

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

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

13. Database – Schema Differences

14. 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).

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

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

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

18. Notice there is no “Store” paramater.

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

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

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

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

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