I managed to discuss a presentation recently with a colleague on the future of Portals. Having had experience of delivering major Portal programmes in a number of different sectors, with varying success, I was interested to hear the insight into where the Portal market will develop.
Five years ago if you were looking to implement an employee Intranet the buzz was about Portals. Vendors such as Vignette, IBM and Aqualogic had the products which would enable the enterprise to share, collaborate and work together. I worked on one such major programme and the biggest drive was cost, bringing multiple feudal intranet sites into a single Portal for commonality and reduced servicing costs. Another, more subtle, driver was around the knowledge sharing and collaborative products which were starting to become available then. The result was a fairly structured implementation which did give users access to features and information from a single view.
Now though the world is a different place, largely due to the advancement in sites such as MySpace, iGoogle and Facebook. These sites are generally less structured than the Portal which was delivered, the model for its growth is more on the trust which is granted to the developers to create new features and share them. Add to this the increases use of Blogs and Wikis and there is a big increase in the means through which people can keep in touch. Its my opinion that the Portal products which were at the top of the list five years ago are no longer the products to be considered now.
One thing which struck me on two of the major Portal programmes I worked was the relative inflexibility of the Portal container framework, note I was involved in two different Portal products. At the time of the first delivery Web 2.0 was not a term people were aware of, the second delivery was around the time of the emergence of the term. Both programmes had different business drivers and difference goals, one was a B2E portal which was primarily aimed at consolidation of a large and feudal group of intranet sites in a large company. The second was more about bringing together information from various information applications into a single application to aid in business efficiency. Users would act on and process the information to complete the business process.
In the first programme we thought long and hard how to manage and then expose the content which was currently displayed in the intranet sites, this was achieved through integration of a Portal product and a leading WCM system. This was achieved but I was concerned at the approach which developed in the first few weeks of operation, content was ‘thrown’ into the Portal with little regard for its relevance and structure in relation to the wider picture. Add to this the other Portlets which were developed, largely based around collaboration and it is now clear to me that the organisation were actually ahead of the technology in their thinking around social networking within the Enterprise. However the organisation were very ‘brand’ oriented with several unique brands contained within it, this focus meant there was a strong desire to retain the brands of the sites which were being migrated into the Portal. At times I felt as though the stakeholders were more concerned with the appearance of their specific areas than the content which went into it. This was very much a content driven Portal and whilst great savings were made in bringing numerous disparate sites into a single Portal framework I am sure things could have been done better if senior support for a more radical approach was forthcoming. As ever the technology was a challenge but in fact the greatest challenge was with the people.
The second programme demonstrated weaknesses in the Portal container as we sought to build an application within the container. The application was the first in many to be built into the Portal framework with the long term goal of users having a single entry point into the applications they used. Experience has taught me that to build a single web application in a Portal container usually leaves the project incurring additional effort that would not necessarily have been required if a pure web application had been built. However with multiple future applications being discussed this was the correct approach. The difficulty though was in designing the Portlets which would be developed for the application. We had two forces in play, one to keep things simple and reduce complexity through implementing as few Portlets as possible. The other force was to increase the possibility of information and feature reuse by breaking down the Portlets into more discrete components. For example consider a Portlet which displays a list of Products, by selecting a Product the Portlet could be developed to publish the selected Product information to the Portal container; other Portlets could then receive and react to this event e.g. a Stock Level Portlet which could display the current Stock Levels for the selected Portlet. This is an interesting, and exciting, prospect but the reality is that the difficulty in developing, and then maintaining, this portlet interaction is difficult in current Portal containers. I admit to not having looked closely at the latest JSR spec for Portlets but I have doubts that the JSR spec is the correct way forward as it is technology specific and does not allow for Portets (or rather Web Parts) from SharePoint to reside in the same paradigm.
Putting the technology to one side though the only way in which different teams could develop Portlets for this level of interaction is through a common Information Model, i.e. only when it is agreed that constitutes the identifier for each Product can this be progressed. In fact a current complaint of mine with some of our internal tools in this space is that we have too many different information repositories and it is very difficult to get a view of all relevant information in one place. Whilst introducing some technology can help this it will only work when the Information is stored and managed correctly; if I did not tag this as Portals then it would not appear as a Portals blog entry.
There is a lot in this post, although there is a theme underpinning it. For organisations to embrace Enterprise 2.0, and by that I mean the use of Web 2.0 tools within the Enterprise, we will need to address three key challenges:
– what is the purpose. Too often this is missed but what are the business objectives and the benefits which can be seen. If this statement includes the use of terms such as Web 2.0, Enterprise 2.0 or SOA then it has missed the mark completely.
– what is our current information model, how is information captured and stored, how can this information be presented?
– given the two previous statements what do we need from the technology to support this?
Observing Content Management 