Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime. - Modularizing Magnolia for Switzerland's Largest Retailer


Published on

Switzerland's leading retailer, Migros, has a Magnolia website with

- A high volume of change requests
- Several internal stakeholders with their own project teams, budgets, and timelines
- Several contractors providing software and content for the website.

This led to complex dependencies requiring exceedingly long and costly testing.

Using Magnolia's module architecture, we have disassembled the project into smaller components with independent software lifecycles and separate deployment capabilities. This way, we have been able to minimize dependencies and to establish a tight release schedule, shipping a bundle of 15-20 change requests, including third party components, every 5 weeks.

Published in: Technology
  • Be the first to comment

  • Be the first to like this - Modularizing Magnolia for Switzerland's Largest Retailer

  1. 1. Migros.chModularizing Magnolia forSwitzerlands Largest RetailerJan Reise, aperto Berlin, Daniel Özbek, Migros CWI@Magnolia Conference Basel, 4.9.2012
  2. 2. If you thought ...… that this is what a typicalMagnolia website looks like … 2
  3. 3. Think again. 3
  4. 4. stats• Over 11,000 content pages• Over 14,000 teasers• Over 80 page templates• Over 250 paragraph templates• Over 1300 Java classes 4
  5. 5. Modularizing migros.ch01 Magnolia relaunch02 Growing into a portal03 Modularization04 Modularization part II05 Summary 5
  6. 6. Magnolia relaunch
  7. 7. 2010: Relaunch of existing site• Old system • MS Sharepoint based • slow to use • difficult to extend • expensive to maintain• Plan: • keep the contents • keep the workflow • fix the problems 7
  8. 8. Requirements for new system• easy to use for editors• live preview• easy to connect to other systems• central content repository (for other systems)• save costs• Migros chose Magnolia ☺ 8
  9. 9. Results• Migration in 6 months• System very stable• Workflow “not changed but improved”• Return on investment already after a few months 9
  10. 10. Some features
  11. 11. Data hub: import and improvement Weekly import from ERP systems & editorial improvement in Magnolia 11
  12. 12. Data hub: exportDelivery of processed datato other systems, eg. mobile apps 12
  13. 13. Teaser management Common teaser pool for site Time based display on pages 13
  14. 14. Modularizing migros.ch01 Magnolia relaunch02 Growing into a portal03 Modularization04 Modularization part II05 Summary 14
  15. 15. Growing into a portal
  16. 16. Rapid growthNew sub-projects built in a short time frame (1.5 years) relaunch aus-der region cumulus generation-m 16
  17. 17. A portal with sub-sitesSeparate themes and templates1 Magnolia webapp, 1 content repository 17
  18. 18. Development driven by change requests• Over 250 change requests per year• Different stakeholders (marketing, corporate communication, regional cooperatives, …)• Budgets only for visible features, not for improving or refactoring the overall project 18
  19. 19. Feature releases 20113 simultaneous sub-projects January February March April May June July4.1 R 4.2 R 4.3 R 4.4 R 4.5 ( R 5.0 (aus der region) R 5.1 R 6.0 (cumulus R 6.1 R 6.2 R 6.3 (all in one) 19
  20. 20. Where‘s the architecture?• Fast growing complexity (new modules)• Fast growing size (permanent development and additions)• Still using the architecture we started with: • Magnolia • Webapp with first project • Modules for new projects• But: common functionality still in with the first project• All new projects depend on the first project 20
  21. 21. Dependencies: expensive and slow• Dependencies between projects lead to side effects (bugs)• Make a change in one project and you have to test all projects• Testing becomes expensive• Testing slows down the project 21
  22. 22. Modularizing migros.ch01 Magnolia relaunch02 Growing into a portal03 Modularization04 Modularization part II05 Summary 22
  23. 23. Modularization
  24. 24. Why not do it like Magnolia?• Magnolia itself has a modular architecture• Remove dependencies between projects• Put common stuff into modules 24
  25. 25. Architecture at relaunchLike a simple project: just a webapp, a theme, and magnolia 25
  26. 26. „Organic“ evolutionNew projects in new modules, depending on common functionality …… which is in the webapp with the first project 26
  27. 27. Common functionality in common modulesNo software dependencies between sub-projects 27
  28. 28. Even more modulesEach feature in its own module 28
  29. 29. Over 25 Magnolia modulesEach module has its own independent software lifecycle 29
  30. 30. The result: better (and less expensive)software architecture• less dependencies less technical complexity• easier to understand for developers (new and old)• more re-use by having a set of well-documented basic templates• easier to test: test only the module that has been changed 30
  31. 31. Releases are containers for modules… and modules are containers for features 31
  32. 32. Releases on a steady schedule2012: Feature releases every 5 weeks March April May June July August SeptemberR 7.0 R 7.1 R 7.2 R 7.3 R 7.4 R 8.0 R 8.1 32
  33. 33. Easy integration of third party modulesThird party modules based on Magnolia or on Migros common stack 33
  34. 34. Third party modulesEasily integrated as software dependencies 34
  35. 35. Third party stuff put into a moduleMagnolia wrapper for aFlash / PHP microsite 35
  36. 36. Modularizing migros.ch01 Magnolia relaunch02 Growing into a portal03 Modularization04 Modularization part II05 Summary 36
  37. 37. Modularization part II
  38. 38. The last dependency: the release cycle• Good: stable, dependable, predictable like Swiss train system• Not so good: rigid and potentially slow• Up to 9 weeks before a new feature goes online 38
  39. 39. Speeding up feature releases• Scenario: new features in one sub-project require changes in the common stack• What we want: Focus test and release cycle on this sub-project• Test and release everything else later 39
  40. 40. Release and deploy separatelyEach project in a separate webapp and in a separate magnolia instanceEven on separate versions of common stack 40
  41. 41. Handling shared data• Some data cannot be kept redundantly• Administer data in “master project webapp”• Provide data to other project webapps via web services 41
  42. 42. Modularizing migros.ch01 Magnolia relaunch02 Growing into a portal03 Modularization04 Modularization part II05 Summary 42
  43. 43. Summary
  44. 44. What have we gained?• Fewer dependencies between projects• Less coordination between projects• Agile testing• Free choice of development teams• More flexibility• More scaling possibilities• Better scaling of development resources 44
  45. 45. New challenges
  46. 46. Integration challenges• Coordination necessary between portal owner and project owners• Coordination necessary between project owners and development teams, in order to prevent double developments• Projects have to share information• Continuous development of the common stack 46
  47. 47. Management challenges• which Magnolia instances for which editors?• access right management• support of the plattform• deployments 47
  48. 48. Cost challenges• hosting and maintenance of all projects in several environments • development • testing • productive• who pays for the development of common functionality? 48
  49. 49. To sum up• Magnolia is good for large, multi-project, portal-type sites• Too much complexity makes projects expensive and slow• A modular architecture helps reduce complexity• Magnolia offers an excellent foundation for this• Separate deployment of sub-projects provides even more agility• But: if you have several platforms you will have to support them! 49
  50. 50. Thank you.