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

Migros.ch

ModularizingMagnolia for

Switzerland'sLargestRetailer

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 …

3

Think again.

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

Modularizing migros.ch

01 Magnolia relaunch

02 Growing into a portal

03 Modularization

04 Modularization part II

05 Summary

5

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

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 ☺

9

Results

• Migration in 6 months

• System very stable

• Workflow “not changed but improved”

• Return on investment already after a few months

Some features

11

Data hub: import and improvement

Weekly import from ERP systems & editorial improvement in Magnolia

12

Data hub: exportDelivery of processed data

to other systems, eg. mobile apps

13

Teaser management

Common teaser pool for site

Time based display on pages




03 Modularization


05 Summary

14

Growing into a portal

Rapid growthNew sub-projects built in a short time frame (1.5 years)

16

aus-der regionmigros.ch relaunch cumulus generation-m

A portal with sub-sitesSeparate 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

Feature releases 20113 simultaneous sub-projects

19

January February March April May June July

R 4.2

R 4.3

R 4.5 (migros.ch)

R 5.0 (aus der region)

R 6.0 (cumulus

R 6.1

R 5.1

R 6.2

R 6.3 (all in one)

4.1

R 4.4

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

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




03 Modularization


05 Summary

22

Modularization

24

Why not do it like Magnolia?

• Magnolia itself has a modular

architecture

• Remove dependencies

between projects

• Put common stuff into

modules

Architecture at relaunchLike a simple project: just a webapp, a theme, and magnolia

25

New projects in new modules, depending on common functionality …

… which is in the webapp with the first project

26

„Organic“ evolution

27

Common functionality in common modulesNo software dependencies between sub-projects

28

Even more modulesEach feature in its own module

29

Over 25 Magnolia modulesEach module has its own independent software lifecycle

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

31

Releases are containers for modules… and modules are containers for features

Releases on a steady schedule2012: Feature releases every 5 weeks

32

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

33

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 a

Flash / PHP microsite

35




03 Modularization


05 Summary

36

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

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

40

Release and deploy separatelyEach project in a separate webapp and in a separate magnolia instance

Even on separate versions of common stack

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




03 Modularization


05 Summary

42

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

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

47

Management challenges

• which Magnolia instances for which editors?

• access right management

• support of the plattform

• deployments

48

Cost challenges

• hosting and maintenance of all projects in several environments

• development

• testing

• productive

• who pays for the development of common functionality?

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!

Thank you.