Archive for November 13th, 2008

4 portals to start a long tail portal platform

Thursday, November 13th, 2008
After having implemented more than hundred portals in different programs we can say that it must be possible to start a generic portal platform after 4 portals. Just implementing 4 portals, even if they incorporate the most successful business requirements, will not do the job. The goal is to get to the start of a generic platform, that is ready to deploy and maintain 20, 30, 40, … portals. The key is to ensure that the generic requirement is well guarded, as too much custom work will surely take you further away from your long tail ambitions.

The first portal is to keep everyone on board.
Although portal is meant to be the window of your integration framework, it doesn’t mean that it will be easy. On the contrary, developing portals is challenging for any developer who hasn’t developed a portlet before. Thus with limited time and changes you will have to make choices what requirements to implement. The following guidelines will help you to make choices to keep everyone on board:

  • Proof that the portal is the excellent environment to combine different applications into 1 composite application that is richer and has more value for your users than existing applications.
  • Pick those applications that have proven to be successful and improve their usability or add value to them with related content or applications.
  • Solve at least one crucial business process that took too much time and lost too many requests in the process.
  • Make sure that your new search functionality is substantially better than the current search.
  • Include Web 2.0 elements to show a clear sign of progress. (rating, RSS, scraping, AJAX, widgets)
  • Include a generic application to use as a HTTP proxy (scraper). In the many portals that will follow, such a solution will allow each portal to include external applications that have specific added value for the portal.
  • Add more ways to do business with your customers. Don’t worry if new methods like pay-per-download do not succeed immediately, they might work better for another target group in one of your other future portals.

The second one is to improve the concept and to keep the platform generic
You need to get a second business unit on the portal platform to earn back your investments faster. Usually a second portal should take less than 25% of the initial investments for the first portal, presuming that the portal is similar to the first portal. Do allow custom work for the second portal, as probably some of it’s high priority requirements were not implemented during the first portal. Do challenge the ROI for these applications, as custom work in a portal will require substantial investments.

During the first implementation you will see that some parts were designed and/or implemented poorly due to several reasons like time / budget pressure or unclear requirements from the business. In the process of getting the second portal the following development aspects must be taken into account to make the platform mature enough:

  • The performance of the portal and it’s applications must be sufficient to handle the load of many more portals. Evaluate if your ROI / TCO is still valid. At Componence we have a portal caching solution that can increase the throughput on your portal up to 10 times. In any case save enough time and budget to profile your application and increase the performance of your applications. Your long-tail strategy cannot succeed if your platform doesn’t perform well.
  • The applications must become as generic as possible. Validate this with the requirements and specifications for your second portal. Setting up your second portal must be possible with at least 60% through only configuration. In this stage you will probably have to refactor a substantial part of your applications to make them really generic.
  • Time to market of the second portal must be within 2-3 months. It might take 1-2 months to refactor necessary parts of the portal, but after that it should be possible to construct and launch the second portal within 1 month .


The third and fourth portal must be the proof
With two major portals launched the platform has enough components that make both concepts interesting. It’s time to use these components to launch new portals for new segments / niches of your target markets; it’s time to access new revenues with minimal budgets. Let your marketing choose 2 target groups that were not big enough to be serviced before, but not too small to be ignored.

In this phase it’s all about proving the concept. It is important that no specific custom requirements are taken into the concept, as they will ruin your time to market. As the portals will be serving a new market, your business will have a hard time providing the ROI for any custom request anyway.

Create 2 fitting concepts for these markets and only use the existing components of the portal framework. The budget requirements should be 40-60% of the second portal and the development time should be less than 2 months.

Portal technology is perfect for your long-tail strategy

Thursday, November 13th, 2008
To achieve a succesfull long tail strategy you need an online services platform that uses specific technology that is meant to integrate, aggregate and personalize data and services. The Java Portal technology is the only real technology that is meant for such a purpose. Other systems like CMS, CRM or E-commerce are meant to service specific content and transactions. Portal and SOA are proven technologies to organize these content and services in such a way that it will be easy to combine them into different offerings.
A typical portal is a dashboard with a combination of content and data from different applications. Such applications are integrated in the integration layer with SOA principles and are presented through portlets. The following key aspects make a portal the perfect window to your integrated systems:

  • Each portlet represents an application and can function as such by offering different actions, views, preferences. As such a portal page contains many applications at the same time.
  • Portlets can easily use the webservices that are enabled in your SOA architecture to provide online services in many different context.
  • Portlets are meant to store preferences for specific user roles or users. This makes personalization for users very convenient.
  • With inter portlet communication portlets can use events to show content / services that are relevant to each other. In combination with AJAX technologies a portal page can continuously change based on the actions of within some portlets.
  • A portal framework contains very flexible layout and look & feel features to support different visual concepts. Different enterprise portal platforms offer user friendly management tools. Applying such chances can be as easy as setting up your own iGoogle page.

With all of the above combined a long-tail strategy will be within reach. After first 3 or 4 portals the portal platform will be generic and complete enough to initiate a more aggressive portal strategy. Your organization will be able to launch new portals with different configurations to service specific target audiences within 1-2 months with just 5-10% of the initial investments.