How-Tos for implementation of Open Source Portal and ECM Projects
Join the DZone community and get the full member experience.Join For Free
It is always a big challenge when you want to extend your current web presence and manageability of your content produced by your existing legacy applications. There are a variety of different implementations on how to achieve this goal. In this post I will try to list some of the main criteria and constraints and evaluate their impact and order of magnitude on successful execution of such projects.
- Available budget and time (this includes current license fees for proprietary solutions)
- Volume of new requirements
- Non functional requirements
- Complexity of current applications
- Volume of Legacy Data
- Technologies used in the current applications
- Size of client organization, on board technical team and existing technical knowledge
- Foreseeable vision in the industry and its impact on you
Based on the constraints above and some additional requirements companies decide about their choice of framework or application.
In fact, your budget and window of time is often the main driver of most of the projects. But how can you receive a solution in a tight window with an already limited budget? It makes sense to adopt an already developed framework and build on top of that to cut time and cost. So, how are you supposed to train your team (if you have any) to pick up that framework? The answer is easy; you need creditable system integrators and reliable open source solution providers. Hence, you will have your project delivered and concurrently train the team during implementation.
Alright, let’s say you are pretty convinced about dancing with open source Portal/ECM technologies. Obviously it is not going to end up like an arranged marriage because you should not pay an arm and a leg for it. You are just dating some open source solution providers, just like high school days. The whole idea is to not anchor yourself.
Now the question is how could an open source Portal/ECM solution help you in satisfying your requirements? To be quite frank, open source frameworks may require light to heavy customization in order to satisfy some of your requirements. What makes them quite compelling is that being open source makes it possible to extend and customize them. Indeed, volume of your requirements should be balanced with your time and budget.
Currently there are a variety of different Open Source Portal and CMS frameworks in the market, frameworks built on Python, Java, PHP, C++, ROR, and basically any language or technology out there. Most of these frameworks come with tons of OOTB (Out of the Box) features and cool stuff. However, often most of these freebies must be polished and re-skinned to match your requirements. In fact, assessing these frameworks and matching their OOTB features with the requirement list is the first thing you need to do.
After benchmarking your requirements with available frameworks or having someone to do it, you can shortlist a handful of products for your project. Next step is to categorize the requirements in respect to the shortlisted frameworks as below:
- Requirement is satisfied by OOTB feature: The selected framework will contain the code and services.
- Requirement will be satisfied by extending the OOTB feature(s): The customizations and extensions should be done in an extensible pluggable way, I will describe after this section.
- Requirement is custom and must be developed. This type of requirement could be broken into the following sub categories:
- Singular requirement: For instance custom Admin, dashboard, contact us page, custom Portlets, unique user attributes and etc. Basically anything that is unique and not repeatable: Such requirements should be implemented as external services or components as much as possible. You do not need to bind the developed components to any frameworks. This is vital for near future extensions. Especially when you consider the trend of technology where services will be hosted on the cloud in near future.
- Repeatable requirements: For instance email templates, Product Pages, Order entities, Workflows, Search function, etc. Basically anything that is repeatable or could be generalized to be reusable: For such requirements a custom framework must be designed containing generic extensible services configurable for your repeatable requirements. This is imperative especially with big projects where amount of time put in designing and creating such framework pays off in reducing overall production time
After or even before this analysis you should compare the shortlisted frameworks with your current in house expertise. Basically a framework is discarded if it does not match your in house knowledge. Let’s say your team knows PHP like the back of their hand in which case, it would not be wise to pick a Java based framework. But what if you are coming from a big corporate using several technologies, what should be your approach? What if you want to implement a Portal or ECM aggregating legacy services or content from different sources each built on a different technology?
To answer this question it is better to analyze the impact of complexity of current legacy applications and their data on architecture of the solution first.
You may think your new solution must fully replace the existing legacy applications and the current data should be migrated. I would agree if you are using a solution from the eighties or you want to get rid of licensing fees of proprietary products. Otherwise, most of the time it is not necessary or even wrong to fully replace the existing systems. Let me categorize the cases where you need to replace a product:
- The current product is using an old technology and you receive no in house or external support for it. In other words, it is impossible to extend, alter, or even maintain it.
- The current produc is an expensive proprietary solution and you need to cut cost.
In other cases it is much better to wire all or some parts of the old legacy applications with the new Portal or ECM solution. It is recommended to do the wiring through Web Service, REST, CMIS or other widely supported interfaces. By the way, this kind of wiring is affordable if the new Portal or ECM is an Open Source one.
Integration of old and new applications through adaptable and extensible interfaces helps you in cutting cost and reducing production time. In a nutshell, my idea is about maximizing utilization of useful components and increasing their reusability by wrapping them with configurable interfaces.
So far we have discussed different types of requirements and techniques to implement them and how to integrate applications together. It is very important to execute the integration via pluggable, extensible and reconfigurable interfaces. Following these design patterns enables you to be able to box solutions in atomic packages and make them independent of each other. All you need to do is to make sure that they can communicate with each other. This way your dependency on technologies will be reduced and your near future customizations could be done much easier.
As mentioned before it is really important what Portal or ECM technology is selected. On the other hand, it is vital to have a flexible Portal and ECM backbone for hosting different types of technologies and content. It is better recognized, if your company is serving a big volume of data produced by different applications. In a nutshell, considering the pace of change in the industry you always need to be able to reuse your existing services instead of renewing them constantly.
You should be hearing cloud computing, cloud services, social networking and things like that every day. The fact is you need to be ready to publish your services to the cloud or be able to consume services from it. In order to do that, you need to focus on the integration level and extension of the current services more than recreating services with new technologies.
As illustrated in the diagram below generic modules and components should be loosely coupled to each other so in future extensions you would go through smaller changes.
To recap, it is important to be technology agnostic and be flexible to interact with components developed in any language. As depicted in the diagram above it is highly imperative to separate the components from each other and make them as reusable as possible. In order to achieve such goal the following steps are necessary to be considered.
- Have the right vision about the future of your requirements.
- Prioritize your requirements based on your budget and time and cross check them with the framework you select.
- Do not fall in love with any technology, they change every day.
- Develop the components in standalone packages and modules. Even avoid developing them within the open source Portal and ECM stack. You do not want to marry them either. Remember, you are just dating them for maximum five years. Standalone packages could later be reconfigured and reused over and over. But if you change the framework chances of reusability drop drastically.
- Try to maximize usage of the existing services and save money and time for more important requirements. Try to componentize existing functions and equip them with configurable, extensible and reusable interfaces.
- Execute the project by the right people who know the open source stack and technologies inside out. Do not worry to outsource the project. You always can have your people trained on the job during project implementation.
- Try to separate rendition of your content from its processing and population. The only thing you need to display in a Portal is the rendered content not the way it is processed. In other words package the rendering layer separately. The view or rendering layer should fetch data from other components through the discussed interfaces.
- Do not used heavy technologies in the view layer. Try to use lightweight ones instead. Your Portlets should be designed as shell rendering your already processed content by other modules. If you execute this correctly, you could render your services in any Portal, or application.
- Keep your content components separate from the other components and access them through generic and configurable services. You do not need to be bound to one particular CMS framework. Remember you are dating.
- The middle layer and business logic services should be template agnostic. The rendering layer is responsible for templating the processed content. The business layer services should be designed in such a way to be consumable by any Portal (for instance iGoogle, iTunes, Facebook, etc.) with minimum effort.
Finally, I need to mention that I have exercised this idea for several big clients and it has worked out pretty well. My concept is pretty easy, do not waste your time by repeating yourself, look for already developed code and try to make it reusable and extensible. Ain’t it easy?
Opinions expressed by DZone contributors are their own.