Often mischaracterized as archaic relics from the 1990s, portals today serve as the foundation for personalized content experiences and underpin the communication and collaboration efforts of large organizations around the world.

To find out more about how portals are used in the field and the changing role of open source software in the enterprise, I sat down with Dave Pierovich, Senior Portal Solutions Architect at Liferay partner Perficient.

How have portals gained more relevance in the past five years?

Executives increasingly see the importance of creating personalized experiences for their customers and portals offer one of the best ways to do that. That’s true not only of the Fortune 500 but midsize and smaller organizations as well. The corporate world is also beginning to understand that doing 100% custom builds is simply not efficient.

Ultimately, when customers ask for a “portal” what they’re asking for is a platform made up of many pre-integrated frameworks that provides a lot of functionality out-of-the-box (OOB), so you don’t have to “reinvent the wheel.” It’s much more cost-effective to purchase portal platforms like Liferay where most of the common requirements are available OOB. Custom means you have to create and maintain much more code, hire more developers, etc. With Liferay you get a lot of functionality already built for you and can focus your development effort on the functionality your company needs to differentiate itself in the market.

What are some common misconceptions you’ve encountered regarding portal technology?

What can sometimes happen is that engineering leadership at an organization says “we know Java” and think that equals “we know portal.” But there’s a huge difference between developing standard J2EE and developing for a portal. J2EE provides a framework but there’s not much there. The challenge is that development teams that aren’t familiar with portal platforms like Liferay assume that they are as limited as J2EE. As a result, unfamiliar development teams have a tendency to under-utilize and over-customize their portals, ending up with a clunky, poorly performing result that’s hard to maintain and even harder to upgrade to the next version of the platform.

Unfortunately, this sometimes results in the portal itself being blamed when the core issue is not the technology but how it’s developed and used. For example, I’ve seen organizations build custom integrations with LDAP when Liferay already provides one. There’s sometimes the idea that you should just build whatever you need. Since J2EE may not offer something, people who don’t know Liferay might not know something already exists. That’s a big mistake and one of the reasons I strongly encourage those new to Liferay to get training. Many issues arise as a result of developers trying to use Liferay before familiarizing themselves with the software.

When thinking about a new portal deployment, how do you scope the resources you’ll need for that particular implementation?

It really depends on the specifics of each implementation and what the client needs. Client requirements are quite varied. Enterprises today have come to understand the need to create personalized experiences for their customers and there’s just so much you can do with a portal. However, I typically spend two to three weeks on discovery work before development work on a project begins. I use that time to understand the client’s needs - what’s a “nice to have” versus a “need to have” - and what systems I’ll need to integrate with. From there I can create a project plan that allows me to allocate work to individual team members based on their experience, location (an offshore team can present a different set of challenges than one based locally), etc.

Can you tell me about a deployment you worked on recently that you’re particularly proud of?

I recently had the opportunity to work on a project for a major financial institution that involved developing a prototype of the system used by their internal advisors. The client was looking for a single-page application that gave them the ability to do a lot of different things. Despite being based on Angular, the previous version of the application was very clunky and slow.

With only a small team we rapidly demonstrated high-end UI capabilities built on top of Liferay. Not only was the system faster but it also recognized each user’s permissions and tailored their experience accordingly. This is something Liferay does OOB but Angular has no concept for. We were even able to integrate with React and Angular to provide a more powerful solution.

I’m incredibly proud of what my team was able to accomplish in a very short period of time. The system we built was very well received and really demonstrated what Liferay DXP can do. Liferay DXP can easily stand up to any other solution and fare well as it brings a lot of OOB functionality to the table that few others do.

How does an organization benefit from using open source technology?

There used to be a fear that open source was somehow “risky” or “not secure” because everyone could see your code. Red Hat proved that wrong with Linux in the 1990’s. In fact, open source is actually more secure thanks to Linus’s Law: “given enough eyeballs, all bugs are shallow.” With a proprietary product, a bad actor can find a vulnerability and exploit it for years before it’s discovered, reported to the vendor and patched. That’s not likely to be true of an open source offering.

In addition, open source solutions are very cost-effective thanks to their ability to leverage a wider developer community. When it comes to portals, leveraging an open source offering allows organizations to save money on software licenses and the initial purchase price, resources that can instead be used to build a custom implementation unique to an organization’s needs.

In Conclusion

Portals are powerful tools but they require investment in understanding their functionality, core strengths and weaknesses. As businesses move towards delivering more personalized experiences to prospects and customers, portals play a key role in addressing customer needs and surfacing the right content at the right time. However, like all other tools, they are best used in the hands of experienced professionals who understand their in’s and out’s.

To learn more about Perficient, be sure to check out their website and the work they’ve done to help organizations improve their digital initiatives and make better use of data.