Your SlideShare is downloading. × - Modularizing Magnolia for Switzerland's Largest Retailer
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply - Modularizing Magnolia for Switzerland's Largest Retailer


Published on

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

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

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Migros.chModularizing Magnolia forSwitzerlands Largest RetailerJan Reise, aperto Berlin, Daniel Özbek, Migros CWI@Magnolia Conference Basel, 4.9.2012
  • 2. If you thought ...… that this is what a typicalMagnolia website looks like … 2
  • 3. Think again. 3
  • 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. Modularizing migros.ch01 Magnolia relaunch02 Growing into a portal03 Modularization04 Modularization part II05 Summary 5
  • 6. Magnolia relaunch
  • 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. 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. Results• Migration in 6 months• System very stable• Workflow “not changed but improved”• Return on investment already after a few months 9
  • 10. Some features
  • 11. Data hub: import and improvement Weekly import from ERP systems & editorial improvement in Magnolia 11
  • 12. Data hub: exportDelivery of processed datato other systems, eg. mobile apps 12
  • 13. Teaser management Common teaser pool for site Time based display on pages 13
  • 14. Modularizing migros.ch01 Magnolia relaunch02 Growing into a portal03 Modularization04 Modularization part II05 Summary 14
  • 15. Growing into a portal
  • 16. Rapid growthNew sub-projects built in a short time frame (1.5 years) relaunch aus-der region cumulus generation-m 16
  • 17. A portal with sub-sitesSeparate themes and templates1 Magnolia webapp, 1 content repository 17
  • 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. 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. 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. 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. Modularizing migros.ch01 Magnolia relaunch02 Growing into a portal03 Modularization04 Modularization part II05 Summary 22
  • 23. Modularization
  • 24. Why not do it like Magnolia?• Magnolia itself has a modular architecture• Remove dependencies between projects• Put common stuff into modules 24
  • 25. Architecture at relaunchLike a simple project: just a webapp, a theme, and magnolia 25
  • 26. „Organic“ evolutionNew projects in new modules, depending on common functionality …… which is in the webapp with the first project 26
  • 27. Common functionality in common modulesNo software dependencies between sub-projects 27
  • 28. Even more modulesEach feature in its own module 28
  • 29. Over 25 Magnolia modulesEach module has its own independent software lifecycle 29
  • 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. Releases are containers for modules… and modules are containers for features 31
  • 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. Easy integration of third party modulesThird party modules based on Magnolia or on Migros common stack 33
  • 34. Third party modulesEasily integrated as software dependencies 34
  • 35. Third party stuff put into a moduleMagnolia wrapper for aFlash / PHP microsite 35
  • 36. Modularizing migros.ch01 Magnolia relaunch02 Growing into a portal03 Modularization04 Modularization part II05 Summary 36
  • 37. Modularization part II
  • 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. 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. Release and deploy separatelyEach project in a separate webapp and in a separate magnolia instanceEven on separate versions of common stack 40
  • 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. Modularizing migros.ch01 Magnolia relaunch02 Growing into a portal03 Modularization04 Modularization part II05 Summary 42
  • 43. Summary
  • 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. New challenges
  • 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. Management challenges• which Magnolia instances for which editors?• access right management• support of the plattform• deployments 47
  • 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. 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. Thank you.