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.

1. Migros.ch
Modularizing Magnolia for
Switzerland's Largest Retailer
Jan Reise, aperto Berlin, Daniel Özbek, Migros CWI
@Magnolia Conference Basel, 4.9.2012

2. If you thought ...
… that this is what a typical
Magnolia website looks like …
2

3. Think again.
3

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. Modularizing migros.ch
01 Magnolia relaunch
02 Growing into a portal
03 Modularization
04 Modularization part II
05 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: export
Delivery of processed data
to other systems, eg. mobile apps
12

13. Teaser management
Common teaser pool for site
Time based display on pages
13

14. Modularizing migros.ch
01 Magnolia relaunch
02 Growing into a portal
03 Modularization
04 Modularization part II
05 Summary
14

15. Growing into a portal

16. Rapid growth
New sub-projects built in a short time frame (1.5 years)
migros.ch relaunch aus-der region cumulus generation-m
16

17. A portal with sub-sites
Separate themes and templates
1 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 2011
3 simultaneous sub-projects
January February March April May June July
4.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. 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.ch
01 Magnolia relaunch
02 Growing into a portal
03 Modularization
04 Modularization part II
05 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 relaunch
Like a simple project: just a webapp, a theme, and magnolia
25

26. „Organic“ evolution
New projects in new modules, depending on common functionality …
… which is in the webapp with the first project
26

27. Common functionality in common modules
No software dependencies between sub-projects
27

28. Even more modules
Each feature in its own module
28

29. Over 25 Magnolia modules
Each 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 schedule
2012: Feature releases every 5 weeks
March April May June July August September
R 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 modules
Third party modules based on Magnolia or on Migros common stack
33

34. Third party modules
Easily integrated as software dependencies
34

35. Third party stuff put into a module
Magnolia wrapper for a
Flash / PHP microsite
35

36. Modularizing migros.ch
01 Magnolia relaunch
02 Growing into a portal
03 Modularization
04 Modularization part II
05 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 separately
Each project in a separate webapp and in a separate magnolia instance
Even 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.ch
01 Magnolia relaunch
02 Growing into a portal
03 Modularization
04 Modularization part II
05 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.