Hi,
as intranets typically center around HTML pages and documents, they offer a valuable source of information that should also be available via a portal (e.g via the integration approach for documents that is provided by the KM platform).
However, if you talk to people, they very often have a clear distinction between a portal (this is more application driven e.g. via integration of business systems) and an intranet (HTML pages, documents as said above).
I would like to get some views on how you the connection between portals and intranets is seen by the group in this forum:
Will intranets (and web content management applications) gradually merge into the 'Super-Portal' or will they continue to exist next to each other with more or less sophisticated integration mechanisms ?
Cheers,
Joerg
Hi Joerg,
In the US we call that 'Opening a can of worms".
I feel as if the super portal is already here today with the SAP Portal product being one of the premier examples.
If I may, I'd like to reflect on some of my own experiences.
The distinction you made between the two areas of Application interface and (what I would call) the KM area seemed more appropriate to the state of technology in the early and mid 1990s. This is when some software giants like SAP and Oracle started to put GUI front ends to their former character based ERP systems. In doing so, they introduced a customizable front end that was designed to present a slightly different "face" to the user based on their job. While there was a considerable expense and effort up front, once in place, it was relatively easy to use. However, the repository capabilities, even for financial reporting, was limited.
At the same time, many in house IT departments began to experiment with creating simple repositories for their most important documents and reports. However, we found this to be highly labor intensive requiring a lot of html and perl effort to maintain since linkages to specific documents was done by hand.
In the end, we were still left with multiple icons sitting on the Windows desktop for different purposes.
With the advent of true portal products, we have the marriage of both worlds in a far less labor intensive scenario. The integration with various ERP systems takes time, but the will eventually be perfected. The KM capabilites of portal products is also maturing and is far more robust than anything I or my collegues thought possible back then.
Best Regards,
David
Hi all,
If we take this discussion on a level higher, not talking too much about document or applications, but about the information, which should be transported to a user, one will see, that only the Use Case is different. In a Portal both (application and documents) are using a "document" container to transport the information to the user.
The Enterprise Portal Content Management uses Repository Managers to deliver Information in Documents from various sources. (Mail, Web..., web content,) or even from non document sources like users. This Repository Manager then delivers information about a user in a document container (like a business card).
Since CM offers a wide set of services on those "documentes" the user is able to extract/find the information from the documents faster (e.g. search, rating, discussion....).
The Portal Content Directory on the other side delivers information to the user mainly from application sources, by structering this applications in "document" like containers (Pages, iViews)
Since The Portal Content Directory is able to deliver this Information "User Centric" (Role based) the user is able to get infomormation for his tasks faster and more relevant.
Why not help the user in allowing him to use the additional services CM is offering for "documents" beeing iViews/Pages. wouldn't it be usefull to search or rate a portal page or having a discussion there???
Why not having a Repository Manager for the PCD?
On the other hand side would't it be nice to be able integration CM Documents "user centric" inforamtion delivery of the PCD. E.g. a CM document could be a PCD iview strait away without having to manually create it? this way a Content Admin can search or navigation to such a document and add it to any portal page, without hassle.
Cheers,
Markus
Hi Crew,
There are so many dimensions to the question is difficult to know where to start...
As a naive answer you could say that Intranets are similar to in-house developed legacy systems, and the Portal is similar to a commercially produced ERP system, in terms of progression...
If you wanted to use the Portal to replace your Intranet, you would fragment your Intranet into its most granular form... Remove navigation links from pages... Populate the Portal with the fragmented content...
The Portal in it's present and future form is the evolution of the Intranet and applications...
In simple terms, the intranet will become content for the Portal because it just does not deliver the same functionality for the same amout of effort, cost, and time...
Regards
Paul Chambers
Add a comment