For all that I love portal and collaboration technology, I recognize there are time when you shouldn’t use it.  It can be heavy if it’s a one-off type application.  Portal can be difficult to implement if you are trying to recreate an entire application from scratch.  It can be really difficult and time consuming if the application is a really complex one.  Hence this post.

What Happened

I refer not to just one but several companies.  A few unwisely chose to use portal as the full interface rather than a side by side implementation.  Others chose to back off that approach once they understood the complexities.

If your architecture looks like this then consider well what you will surface on portal

Choosing a Global Software Development Partner to Accelerate Your Digital Strategy

To be successful and outpace the competition, you need a software development partner that excels in exactly the type of digital projects you are now faced with accelerating, and in the most cost effective and optimized way possible.

Get the Guide

All of these companies had one thing in common, they had a complex existing system with it’s own web interface.  These complex systems already had a complex interactions with back end systems to perform campaign, product display, checkout, and other functionality.  Those that chose to move forward with a complete replacement of the existing front end with a portal front end saw the expected results.  Those results include either a successful launch with a blown budget and timeline or a failed project.  The risks of this approach are numerous. The consequences are large.

What Should Have Happened

We find another case where following a pragmatic approach leads you down the path of glory and successful launches.  The rules are pretty simple:

1. Use your judgement before surfacing anything in the portal
2. If it is best built as a one off application or you only intend to use the portal to build one small application, don’t do it.  Build a standalone application and be happy.
3. If it sports a complex web interface then consider the side by side approach.
4. If it has complex rules, validations, etc in the web interface then consider the side by side approach.
5. See a previous post on the how to surface decision tree.

What is the Side by Side Approach?

Side by side means the portal and other complex applications live side by side.  I’m not talking ERP.   The typical approach to an ERP or CRM system is to surface up a small amount of functionality in the portal.  I reserve this approach for things like commerce systems and learning management systems.  In order to make this approach work you should do the following:

• Get Single Sign On (SSO) to work between the two systems
• Create a shared look and feel so it’s not jarring when moving between the two web sites
• Create a shared taxonomy at at least level 1 of your site structure
• If possible use similar button labels, button types, locations for search, etc.  You are trying to create a shared experience without recreating it all in portal.

I grant that this approach will not deliver the best user experience.  However, sometimes perfection must bow at the feet of pragmatism.  These examples qualify as one of those times.

Previous Installments

1. Where’s My Homepage?!?
2. The Business Asked for It
3. Methodology for Methodology’s Sake
4. The Never Ending Strategy
5. I Built It But Now I Can’t Support It
6. We Can Get Big ROI From a Portal
7. Is Best of Breed Always Best?
8. When Developers Can’t Develop

Join us this month on Wed, June 29th for our Perficient Perspectives webinar in which we explore the 12 Things You Shouldn’t Do on a Portal Project in depth.  More Info / Register