Migros.chModularizing Magnolia forSwitzerlands Largest RetailerJan Reise, aperto Berlin, Daniel Özbek, Migros CWI@Magnolia...
If you thought ...… that this is what a typicalMagnolia website looks like …                                2
Think again.               3
migros.ch stats• Over 11,000 content pages• Over 14,000 teasers• Over 80 page templates• Over 250 paragraph templates• Ove...
Modularizing migros.ch01   Magnolia relaunch02   Growing into a portal03   Modularization04   Modularization part II05   S...
Magnolia relaunch
2010: Relaunch of existing site• Old system   •   MS Sharepoint based   •   slow to use   •   difficult to extend   •   ex...
Requirements for new system• easy to use for editors• live preview• easy to connect to other systems• central content repo...
Results• Migration in 6 months• System very stable• Workflow “not changed but improved”• Return on investment already afte...
Some features
Data hub: import and improvement Weekly import from ERP systems & editorial improvement in Magnolia                       ...
Data hub: exportDelivery of processed datato other systems, eg. mobile apps                                    12
Teaser management Common teaser pool for site Time based display on pages                               13
Modularizing migros.ch01   Magnolia relaunch02   Growing into a portal03   Modularization04   Modularization part II05   S...
Growing into a portal
Rapid growthNew sub-projects built in a short time frame (1.5 years)  migros.ch relaunch   aus-der region   cumulus       ...
A portal with sub-sitesSeparate themes and templates1 Magnolia webapp, 1 content repository                               ...
Development driven by change requests• Over 250 change requests per year• Different stakeholders (marketing, corporate com...
Feature releases 20113 simultaneous sub-projects January      February        March            April                May   ...
Where‘s the architecture?• Fast growing complexity (new modules)• Fast growing size (permanent development and additions)•...
Dependencies: expensive and slow• Dependencies between projects lead to side effects (bugs)• Make a change in one project ...
Modularizing migros.ch01   Magnolia relaunch02   Growing into a portal03   Modularization04   Modularization part II05   S...
Modularization
Why not do it like Magnolia?• Magnolia itself has a modular  architecture• Remove dependencies  between projects• Put comm...
Architecture at relaunchLike a simple project: just a webapp, a theme, and magnolia                                       ...
„Organic“ evolutionNew projects in new modules, depending on common functionality …… which is in the webapp with the first...
Common functionality in common modulesNo software dependencies between sub-projects                                       ...
Even more modulesEach feature in its own module                                 28
Over 25 Magnolia modulesEach module has its own independent software lifecycle                                            ...
The result: better (and less expensive)software architecture• less dependencies     less technical complexity• easier to u...
Releases are containers for modules… and modules are containers for features                                            31
Releases on a steady schedule2012: Feature releases every 5 weeks March          April    May       June           July   ...
Easy integration of third party modulesThird party modules based on Magnolia or on Migros common stack                    ...
Third party modulesEasily integrated as software dependencies                                             34
Third party stuff put into a moduleMagnolia wrapper for aFlash / PHP microsite                                      35
Modularizing migros.ch01   Magnolia relaunch02   Growing into a portal03   Modularization04   Modularization part II05   S...
Modularization part II
The last dependency: the release cycle• Good: stable, dependable, predictable like Swiss train system• Not so good: rigid ...
Speeding up feature releases• Scenario: new features in one sub-project require changes in the   common stack• What we wan...
Release and deploy separatelyEach project in a separate webapp and in a separate magnolia instanceEven on separate version...
Handling shared data• Some data cannot be kept redundantly• Administer data in “master project webapp”• Provide data to ot...
Modularizing migros.ch01   Magnolia relaunch02   Growing into a portal03   Modularization04   Modularization part II05   S...
Summary
What have we gained?• Fewer dependencies between projects• Less coordination between projects• Agile testing• Free choice ...
New challenges
Integration challenges• Coordination necessary between portal owner and project owners• Coordination necessary between pro...
Management challenges• which Magnolia instances for which editors?• access right management• support of the plattform• dep...
Cost challenges• hosting and maintenance of all projects in several environments   •   development   •   testing   •   pro...
To sum up• Magnolia is good for large, multi-project, portal-type sites• Too much complexity makes projects expensive and ...
Thank you.
Upcoming SlideShare
Loading in …5
×

Migros.ch - Modularizing Magnolia for Switzerland's Largest Retailer

939 views
883 views

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
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
939
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Migros.ch - 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. migros.ch 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) migros.ch 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 (migros.ch) 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.

×