Global Reference Architecture for Multiple Brand Deployments on Magento
•Télécharger en tant que PPTX, PDF•
2 j'aime•1,107 vues
This document outlines a global reference architecture for deploying multiple Magento storefronts or brands on a shared codebase. It discusses using a single Magento instance or multiple instances to support multiple stores or websites for different brands. The reference architecture proposes a shared codebase with core, common, and brand-specific code to maximize code reuse. It also describes using a change control board process to manage feature requests and updates across brands. The benefits are seen as independence for each brand, lower costs through a shared platform, and reduced time to market for new features or brands.
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Global Reference Architecture for Multiple Brand Deployments on Magento
Similaire à Global Reference Architecture for Multiple Brand Deployments on Magento (20)
Dernier
Dernier (20)
Global Reference Architecture for Multiple Brand Deployments on Magento
- 1. Global Reference Architecture for Multiple Brand Deployments Kimberely Thomas Practice Lead Magento Services
- 2. Magento Services helps ensure your success with Magento.
- 3. Magento Services • Advisory • Development • Strategy • Analytics • Training 60 Consultants Worldwide
- 4. Why do we need a reference architecture?
- 5. Brands Requirements Scalability Agility Innovation
- 6. Company Requirements Company Brand A Brand B Brand C Brand D Brand E Lower Total Cost of Ownership Faster Time to Market
- 7. Reference Architecture • Shared codebase supporting multiple instances of Magento • Core code base • Custom features • Extensions • Core theme • Shared Integrations • Brand code base • Brand custom features (few) • Brand theme • Brand integrations
- 8. How do we architect a solution?
- 10. Magento Websites Website Can have unique Prices Can have unique Shipping Method Can have unique Payment Method Can have unique Currency Does not share Shopping Cart Does share Customers Store Can have unique Catalog Can Share Cart Can Share User Sessions Store View Can have unique Language Can have unique Theme
- 11. Magento Admin
- 13. Magento Multiple Stores – Single Instance
- 15. Magento Multiple Stores – Multiple Instance • Per Brand
- 16. Single Instances Benefits • Single point of administration • Content can be shared • Combined reporting Single deployment process • Customer account sharing across brands and countries Multiple Instances Benefits • Store data is independent from other countries and/or brands • Dedicated integrations with backend systems • Independently scalable • Independently deployable • Unique Catalog attributes and attribute set Single Instance vs Multiple Instances
- 17. What does it look like?
- 18. Global Reference Architecture – Multi-Brand MAGENTO CLOUD MAGENTO CLOUD MAGENTO CLOUD
- 19. Code Repository core common brand A brand B brand C
- 20. Code Repository •Magento 2.2 common •Custom Feature 1 •Custom Feature 2 •Custom Feature 2 •Integration 1 •Parent Theme core •Brand Theme brand A •Brand Theme brand B •Brand Theme •Brand Custom Feature 1 •Brand Integration 1 brand C
- 21. Theme Inheritance Parent: common Brand A Brand B Brand C Theme inheritance is based on the fallback mechanism, which guarantees that if a view file is not found in the current theme, the system searches in the ancestor themes, module view files or library.
- 24. What are the challenges?
- 25. Challenges • Consensus across Brands • Every enhancement is made available for other Brands • QA Reference Architecture Changes
- 26. What are the benefits?
- 27. Outcome • Independent Brands, one platform • Multiple Countries and Languages • Less total time on Support • Ability to focus on enhancements • Support Brand Specifics
- 28. Key Benefits Brand Independence Lower Total Cost of Ownership Reduced Time to Market
- 29. Reference Architecture Timeline Reference Architecture Brand A Brand B Enhancements Brand C Brand D Brand E
- 30. How do you make it work?
- 31. Key to Success Business Alignment across Brands
- 32. Change Control Board • Change Control Board • eCommerce Director • Brand Representatives • Duties • Prioritize Requests • Approve Estimates • Plan Roadmap Maintains the integrity of Client’s Reference Architecture and prioritizes development based on benefit to the business.
- 33. Change Control Process Board Approval Implement Feature In Reference Architecture Implement Feature in Brand(s) Deploy to Production for Brand(s) Feature Request
- 34. Happy Customers
- 35. Thank you! Q & A Email: kimbthomas@magento.com Twitter: @magentogirl
Notes de l'éditeur
- Welcome to Global Reference Architecture for Multiple Brand Deployments I am Kimberely Thomas, Practice Lead at Magento Services I have been working with Magento for about 9 years, I started as a developer and now lead the US Practice at Magento Services. I am a certified Solution Specialist and a Certified Scrum Master. I’ve been very involved with the Community and I started Meet Magento NY organizing it in 2014 and 2015. Thank you for attending
- Magento Services is the professional services arm of Magento. We partner with merchants, vendors and SIs and everyone in the Magento ecosystme to ensure the success of Magento projects. That’s our goal.
- Here are the types of Services we offer We are a group of 60 consultants across the globe. We do advisory services like Health Checks and Code Audits, and development like extension, implementations and migrations. Strategy – our strategy engagements can transform your digital business. Analytics can help you understand your data (and make sure you are collect what data you need to do this) and we round that all out with training from Magento U. Another role of Magento Services is to provide thought leadership through speaking engagements, white-papers, and webinars, giving back to the community
- So why do we need a reference archtiecture? Magento supports multiple websites and stores to support multiple brands and countries. So why are we here?
- Well Brands want to be scalable but they also want agility and innovation. They don’t want to be on shared architecture where they have to coordinate marketing calendars to prevent overloading the platform. They want to innovate and innovate fast but they spend most of their budget on support.
- Then there is the company requirements. The company wants all their brands on the same platform, and they want to add more brands quickly. But most of all they want a Lower Total Cost of Ownership
- This is where a reference architecture comes into play. We create a shared codebase supporting multiple instances of Magento The core code base contains the custom features, extensions, a core theme and shared Integrations The brand code base contains brand specific features (which there should be few of), the brand’s theme and any brand specific integrations This allows to have a common code base but addresses the concerns for scalability and agility by allowing brands to be on their instance. Brands can then control their own marketing calendars, deployment schedules and infrastructure changes.
- Ok, so how do we architect a solution?
- Magento supports multiple websites, stores and store views. This allows you to create different websites for Brands or Countries and different stores for a regular store and a flash sale sites and different store views for different langauges.
- Before setting up your websites and store views you first you have to understand the features of each of these so that you can determine what is the best setup for your brands, countries and languages. Websites can have unique prices, shipping and payment methods. They can have unique currency. But they do not share shopping carts. Stores can have a unique catalog so you can have a different catalog at the store level. They do share carts and user sessions. Store views can have a unique Language and theme – these are usually used for localization.
- All configurations can be done at the scope level and you can see that level that it is in the Magento admin. You can see here the scope of this setting is store view and this one is website.
- If you were to deploy Magento on a single instance, It might look like this from a logical view – with 3 domains, 1 instance of the Magento application and 1 instance of the database. Of course you might have multiple web servers or database servers – this is just a simple view.
- The websites and stores might be setup like this – with each Brand being set up as a websites the the Store views for each language. So we See Brand A has Store A and English and Spanish. Brand C has – is an example of where they want to use another catalog for the private sale and then they just have English for both languages. This is a typical setup but it depends on your requirements. This can affect performance so it’s really improtant to get right.
- Here is an example of multiple instances – each brand has it’s own domain and it’s own instance of the Magento application running with it’s own database.
- Here is an example of how the websties and store views could be setup. So this is for each brand. Each country gets their own website – this allows for different shipping and payment methods by country. Then each language gets it own store view. So we have country a, with store a because there is only 1 catalog needed and then store views for English and spanish.
- This is the money slide. This is what it is all about right here. Starting at the bottom – this shows it being hosted on magento cloud – each brand has it’s own instance. Then on top of that –the Magento Application and the Core Custom Modules/Integrations For the reference architecture we have the responsive theme that will be inherited by all other themes. Then for brand 1 on top of magento cloud and the reference architecture we have the brand modules and the brand theme. And so on for brand 2.
- Here is what the code repository looks like Core contains the Magento application Common contains the reference architecture – so all the common modules and reference theme Then each brand has their own repo with their customizations (should be few) and theme
- Digging more into the code repository this is what the details look like
- A little bit about Theme Inheritance. Themes inherit from a parent theme – so this is where we make the reference theme – which will be the starter theme for all brands. So for example if you added a quick view feature – that module would get added to common and the theme files would get added to the common theme. This way just the styling, look and feel need to be applied for each brand.
- This is what the reference architecture looks like – there is a jenkins deployment server that runs the build scripts grabbing the code from git and deploying to dev and qa. There is no production environment for the reference architecture. We have this so we can run tests and do QA here first. Then test on Brands
- This is what the Brand’s environment looks like – they have dev, qa, staging and production. Again jenkins grabs the code from git and deploys.
- Well what are some of the challenges of using a reference architecture? First you have to have consensus across Brands. What does the roadmap look like? What features will be prioritized? Brand A may want Feature A and Brand B may want integration A first. So you have to have a way to have consensus across brands. I will come back to this. Next every enhancement is made available for other brands. Well this is a good thing right? It is and this is what we want. But it does create some challenges by creating more work to be done and there is not always enough time to enable all new features right away on all brands. Or one brand may have the budget for it while another brand does not. And lastly you have QA reference architecture changes – so this is another step in the process that you have to add.
- The outcome is great. We have independent brands on one platform. They have their own instances, but we have a shared code base. Here we ability to have a website for each country and store views for each language Less total time is spent on support – since there is one common code base and shared support less time is spent on support. With less time spent on support this frees up time to focus on enhancements so that brands can be innovative. And finally we are able to support brand specifics – by them having the ability to add customizations and having their own envrionments.
- And these are the big benefits – meeting the company requirements.
- Another big benefit is the ability to onboard new brands. The company roadmap may look like this with the implementation of each brand taking less time as lessons are learned and processes are made more efficient. So they deployed Brand A, B, C and then did some enhancements and then they wanted to onboard a new brand, brand d and they were able to that quickly.
- The Key to Success is Business Alignment across Brands
- Well how do we do that. By establishing a Change Control Board. The Change Control Board Maintains the integrity of Client’s Reference Architecture and prioritizes development based on benefit to the business. On the board you will want to have your ecommerce director and a representative from each brand. Their duties will then be to prioritize requests and approve estimates as well as plan the entire roadmap.
- What does the change control process look like?
- And what is the final outcome? We met the brand requirements and the company requirements so we have happy customers.
- Thank you. If you have any questions about Magento or Magento Services come by and talk to me!