Published on November 28, 2016 by Christopher Zimmermann
I recently conducted a series of interviews with Magnolia partners, asking them about their development experiences. One thing that came up again and again was the importance of parallelizing the work on a project. If you cannot easily divide the work and share it among teams, then the project is going to take longer. It got me thinking about the bigger picture of what makes for a successful project. In this post, I'd like to share with you how Magnolia's new Light Development can give projects a boost through parallelization and collaboration.
When teams cannot work in parallel, they have to wait for other parts of the project to be finished before they can start. Even if you have the financial resources or available staff on hand, you cannot effectively apply them to the project. It's difficult to scale up a project effort. This means that being able to parallelize work helps both with hitting project deadlines and keeping staff occupied. So how does Light Development help here?
Light Development brings a new way to contribute to Magnolia projects: Light Modules. Light Modules are simple, they are just a directory of files. This means that without any Java experience, front-end developers can create and contribute to them. While back-end Java developers work on integrations and custom business logic, front-end development teams can work on templates and web resources at the same time. The front-end developers are not dependent on Java experts to integrate their work, the groups can work efficiently in parallel. It's easy to bring on multiple vendors to contribute to one project.
"Luckily when we started the project, Magnolia 5.4 came out introducing Light Modules. We now have four front-end guys working on our project and zero issues with concurrency."
- Niko Salminen, Frontend Developer - Houston Inc. Consulting
The top diagram illustrates the bottleneck when teams cannot contribute on their own.
The bottom diagram shows contributions from three teams entering the project in parallel, no bottleneck - thanks to Light Modules.
I want to explore this collaboration between back-end and front-end developers more. This was another topic that came up in many of the interviews: issues between front-end and back-end development. Have you ever experienced the pain of keeping CMS templates in-sync with a static frontend HTML design prototype? Picture this: You are a back-end developer, and based on a provided HTML prototype, you've built out the CMS templates and everything is working great. But now the designers or front-end devs have changed the prototype, and you have to sync those changes in the templates. It can be hard to know exactly what has changed. Another common problem on projects is knowing who is responsible when there are bugs in the HTML, when both the front-end and back-end teams have their fingers in the templates.
Light Modules provide an approach to cleanly separate the responsibilities of the development teams. Back-end developers are primarily responsible for the Java modules, sometimes providing custom templating functions or template models to expose the desired content to the templates. Meanwhile front-end development teams own the Light Modules which supply the actual HTML via templates and web resources. The front-end team is then responsible for both the static prototype and the CMS templates, and can more easily keep them in sync.
Of course how you divide the work depends on the type of project and the people involved, but the feature and the opportunity are now available and can be used or adapted as appropriate.
Let's zoom out a little further to consider the business ecosystem. It's common for enterprise CMS projects to be implemented by a technical solution provider and a creative agency working together in collaboration. A collaboration in harmony, or in dischord as the case may be. A good relationship between technical and creative providers stands to benefit both. The Magnolia technical partners that I've spoken to get up to half of their projects through creative agencies! And vice-versa, creative agencies are often contacted by Magnolia partners to help complete projects for their clients.
From this business perspective, technical partners provide the integrations and other sophisticated features in Java modules, while creative agencies can provide templating and web resources via Light Modules. Each company has more freedom and is less dependent or "tightly coupled" to the other company to get their job done. With less bottlenecks, development can be faster and friction-free. Even if as a technical partner you don't want to entirely "give away" the templating to the creative agency - Light Modules allow the agency access to the web resources and templates in case of bugs or maintenance.
"As a Magnolia partner, we love the way Magnolia empowers front-end developers with Light Development. Besides making life easier for our own developers, it also enhances our relationship with creative agencies. Agencies like that they can be involved in more of the project. We noticed that this fact is a "turn on" for them to choose Magnolia as a CMS, and Tricode as a partner to team up for the back-end development and managing the technical environment. Light Development creates a win-win situation for both the creative agencies and Tricode."
- Remco van Iersel, Marketing and Communications Manager - Tricode Professional Services BV
If you are a Magnolia partner, I encourage you to use Light Development to strengthen your relationship with creative agencies, and attract new ones.
We know how important it is for our customers to be able to bring in multiple vendors on a project. Above, I've called out the specific relationship between frontend, backend, agency and partners - but the principles apply to all teams really. With Light Modules, and project configuration stored in simple text files, it's easy for multiple teams to contribute to one project.
Image: "There's no place like the death star 2" by JD Hancock cc-by-2.0
See all posts on Christopher Zimmermann