AspDotNetStorefront Multi store - Making Good Architecture Decisions

3,187 views

Published on

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.

Published in: Technology
2 Comments
0 Likes
Statistics
Notes
  • I can crack it
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • I can crack it !
    alby@foxmail.com
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

No Downloads
Views
Total views
3,187
On SlideShare
0
From Embeds
0
Number of Embeds
616
Actions
Shares
0
Downloads
25
Comments
2
Likes
0
Embeds 0
No embeds

No notes for slide

AspDotNetStorefront Multi store - Making Good Architecture Decisions

  1. 1. “Multi Store” eCommerce<br />Making Good Decisions<br />Matthew Bertulli<br />Co-Founder & President <br />@mbertulli<br />
  2. 2. Agenda<br />Introduction<br />Multi-Store vs. Multi-License Overview<br />“Heavy Hitters”<br />Questions you as developers should be asking in order to find toolset fit.<br />Use Cases<br />Where do I get all of this stuff from?<br />Technical Analysis and Comparisons<br />Tools, Database, Core Code, Front-End “The Pretty”<br />Q&A / Discussion<br />
  3. 3. Who is this guy? <br />10 or so years in eCommerce. <br />Last “real job” was with NetSuite before starting Demac Media ~3 years ago.<br />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.<br />Developer first, everything else second.<br />Multi-Language (not just a .NET guys). <br />Strong belief in use the right tool for the right job.<br />Love the challenges of multi-store and multi-channel eCommerce<br />
  4. 4. “Multi Store” Overview<br />Two Viable Models<br />Multi-Store is the true use of ASPDNSF Multi-Store version. V9 with more goodness.<br />Multi-Instance is using multiple ASPDNSF instances for multiple stores.<br />“Multi Store” eCommerce is extremely complicated. We have an hour and we won’t even scratch the surface.<br />
  5. 5. My Hope <br />I want to give you enough ammunition to answer the following question when tackling “multi store” eCommerce:<br />Is it more work to customize ASPDNSF Multi-Store or build tooling and process for handling multiple ASPDNSF instances?<br />
  6. 6. Heavy Hitters<br />What exactly does truly map well in Multi-Store?<br />Product Catalog Questions:<br />Same products, different merchandising per store?<br />Different pricing per store?<br />Different categories/structure per store?<br />Infrastructure! How are you going to be hosting? <br />How are you handling deployment? Builds, fixes, testing, etc…<br />Do you need to have different users have access to different stores?<br />Are you doing multi-store for multiple “separate” clients?<br />How different is the purchasing process from store to store? Same payment methods, same shipping methods?<br />Do you know how these site are marketed / connected? <br />
  7. 7. Use Case – Multi-Store (MLx)<br />Case #1: Multi-Store Deployment<br />5 stores. 25 planned and 50 is the target.<br />Lower traffic sites, higher order value.<br />Single vertical server scaling. Deal with web farm challenges if ever arise.<br />Easier deployment of fixes on core code base. <br />More difficult management of store-specific change requests (lots of shared code).<br />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.<br />
  8. 8.
  9. 9. Use Case – Multi-Instance<br />Case #2: Multi-Instance Deployment<br />Currently 10 stores launched, 15 more planned, and 150-200 is the target.<br />Each store owned and operated by a different company.<br />Each store integrated to one wholesale distribution ERP system (Prophet21).<br />Needed to be easier to make store specific customizations.<br />Deployments of core code fixes/patches is much more difficult.<br />Continuous Integration (CruiseControl and MSBuild are useful)<br />Version control is important.<br />Multiple web and database servers hosting all of these sites.<br />
  10. 10.
  11. 11. Maintenance – MI / MS<br />Developing your own build and deployment process. <br />Our Tooling:<br />SVN over GIT / Mercurial<br />CruiseControl.NET & MSBuild<br />Automated builds of checked in code.<br />CSS Compression, FTP Files, Copy Proper License Files Etc…<br />True local dev, staging server, and production server separation.<br />Red Gate SQL Compare & SQL Data Compare<br />Automation<br />Transfer of new DLLs / patches / files to various web servers. <br />Database changes - RPITA<br />
  12. 12.
  13. 13. Database – Schema Differences<br />
  14. 14. Database – Multi-Instance<br />Multiple database instance deployments. Dev, Staging and Production all look like this.<br />Your data tooling must be a huge focus. Replication / Sharing of data (think inventory).<br />
  15. 15. What maps well? - MS<br />The following have default mapping structures and an interface to make the mapping happen. What’s missing?<br />Affiliates<br />Categories<br />Coupons<br />Gift Cards<br />Manufacturers<br />News<br />Topics<br />Order Options<br />Products<br />Departments<br />Shipping Methods<br />String Resources<br />
  16. 16. Mapping Challenges - MS <br />Customers / Users<br />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.<br />Customer Levels<br />If you have a wholesale only store with wholesale customer levels, those same levels will apply to all stores.<br />
  17. 17. Product Catalog - MS<br />You can map products to stores, but you can’t do much past that natively.<br />The Big One: Pricing<br />Price, Cost, Sale Price, Volume Pricing, Customer Level Pricing<br />ML 9 Makes price rule customization a little easier by consolidating everything into one Prices.cs class.<br />Note: If you’ve ever tried to customize pricing in source code you know there are a LOT of touch points.<br />The 2nd Big One: Content<br />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)<br />You could clone products, keeping a copy of each product in each store?<br />
  18. 18. Notice there is no “Store” paramater.<br />
  19. 19. Product Catalog - MI<br />Big Challenge – You have dozens of database instances to push / replicate data into. <br />Our Approach<br />We developed an integration framework that allows us to setup a series of integration “jobs” for each store. These jobs do things like:<br />Update Inventory every 15 minutes from ERP system.<br />Process Orders from www.store.com to ERP system.<br />Copy catalog of products to each store daily.<br />This works for us, but doesn’t mean it works for everyone.<br />Use of Red Gate tools may allow for easier data replication across instances in some cases.<br />
  20. 20. Users / Roles and Store Management - MS<br />Same Company, Different Divisions (Split Resources)<br />Not so nice a fit with Multi-Store License<br />Same Company, Shared Resources<br />Fits nicely with Multi-Store License<br />Multiple Companies<br />You’ll be coding quite a bit to make this work.<br />Locking down sets of data based on user access is not an easy architectural problem to solve. Let alone in code. <br />
  21. 21. Front-End “The Pretty” - MS<br />ASPDNSF has always been good at multiple skins/templates for different uses (think holiday season skin).<br />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.<br />ShoppingCart.aspx<br />Checkout Pages (checkoutshipping.aspx, checkoutpayment.aspx, checkout1.aspx)<br />You can have separate skins / templates for each store. Pretty obvious one and very necessary.<br />Method depends on V8 or ML code base.<br />
  22. 22. Front-End “The Pretty” - MI<br />Organization & Structure to your code is key<br />Each store is a customized version of an existing “Skin” that we pre-designed and developed.<br />We create Skin_#### for each variation where #### is our client ID in the warehouse system.<br />Leverage version control tools heavily to deal with branching, merging, conflicts and common code.<br />
  23. 23. Conclusion<br />Multi-Store is a tough nut to crack, especially for the small to mid sized online merchant. <br />Maintenance is the problem. Good Architecture is the answer.<br />The right tooling can save you a lot of time and headache.<br />Just because multi-store platforms exist, doesn’t make them the right choice for everyone.<br />Q&A / Discussion<br />

×