With years of experience in portal consultations and all-round analysis using our Liferay Healthcheck service, we’ve collected a number of important observations and identified some (anti-)patterns that repeat over many Liferay implementations. This article is one from a series uncovering the lessons we’ve learned.
Liferay SME is a key element in the portal development cycle
Liferay is a portal platform. In other words, it’s a complex software product. Even if you don’t know Liferay well, just a glimpse over its architecture diagram with many subsystems, modules, and APIs tells you that to implement and integrate the product into your environment can’t be a trivial task. And not just that. Being an enterprise platform, almost every Liferay implementation involves further customization and custom development.
And here comes the problem. With the portal platform, you choose also its technical design with its own architectural and design specifics. And when the time comes when you need to further customize your platform and develop new features, you have to make an important decision, which — according to our experience from many observed Liferay projects — has a serious impact on:
- implementation complexity and resources
- speed of delivery (time-to-market)
- future maintainability and maintenance costs
So what is that important decision about? It’s whether you are going to follow the portal architecture, technology stack, and tech design principles.
Or not — and start implementing portal extensions without taking care of those principles. Usually, such a decision comes from a combination of facts — lack of Liferay know-how at least in some points of the delivery cycle or/and gravitation towards some known technical stack used for other systems.
Leading your portal development “against” the platform principles can completely erase the business value for which Liferay was chosen at the beginning (stability, ease of adaptation, etc.)
So how to avoid the problems and make the most of your Liferay platform? Take the complexity of the product and its technical ecosystem seriously. Be sure you have a Liferay expert available not only for coding of new features and customizations but more importantly, also during the requirement engineering and new features design phase. Cooperating with the experts that can design the solution that is fully compliant with the underlying product will result in a solution that will likely fulfill the expectations. And that keeps the platform flexible, easy to extend, and easy to maintain or upgrade.
Here is what we advise our clients who have issues with the problematic design of their custom modules and customizations:
- Put a senior Liferay consultant as a key person during the process of design/architecture of new features
- Create functional and technical requirements with a strong voice and right to stop plans that can lead to the wrong design.
Be prepared to let the expert explain their arguments with foreseen risks and this way provide you with a Liferay compliant solution.
Another important area, where using Liferay SME (subject matter expert) can be very useful, is the portal content editor’s team. Choosing the right CMS tool and workflow path for their purposes can save the editors a lot of effort and nerves (and complains about Liferay later 🙂 ).
Here are some real-world examples that demonstrate the same problem:
- The most obvious, yet quite common is the wrong usage of invasive customizations where a much easier solution exists. For example usage of EXT modules or JSP fragments where extensions points allow clean and easy to maintain the solution.
- More than once we also saw attempts to customize or avoid using the Liferay permission system, that is otherwise proven to be very mature and flexible. In both cases, the decision was made most probably because of a lack of knowledge on how the Liferay permission system works in detail and what are its capabilities.
- Another very common situation is the inefficient usage of front-end resources. Sometimes frontend team decides to use jQuery (probably because they knew well the technology) for common DOM manipulations where they can simply reuse already present AlloyUI/YUI that is out-of-the-box loaded with Liferay.
OK, this was the first lesson we’ve learned by watching closely some Liferay projects. The series is about the importance of being professional in each part of your delivery cycle. Stay tuned for the next one!
Lessons Learned from Liferay Healthchecks: The need for SME was originally published in ableneo Technology on Medium, where people are continuing the conversation by highlighting and responding to this story.