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

Modularizing migros.ch

01 Magnolia relaunch

02 Growing into a portal

03 Modularization

04 Modularization part II

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

Modularizing migros.ch

01 Magnolia relaunch

02 Growing into a portal

03 Modularization

04 Modularization part II

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

Modularizing migros.ch

01 Magnolia relaunch

02 Growing into a portal

03 Modularization

04 Modularization part II

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

Modularizing migros.ch

01 Magnolia relaunch

02 Growing into a portal

03 Modularization

04 Modularization part II

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.