Portals

A portal is often a collation/marshalling point, retrieving and integrating content from disparate and decentralised stores. Sharing information rather than managing it. The portal itself may not initially be an app-dev platform.

There are going to be other legacy and future portals existing in parallel with any central one for some time. Existing app/portal developers should be encouraged to provide interfaces that allow the portal to query/fetch/interact w them.

Timelyness: core facilities are only now available enterprise wide through things like authentication services, groups etc, topics and subjects, corporate data feeds

Buzzword alert: don't need to build an all-encompassing portal just because everyone else is

Measuring Impact, Success, Failure, Buy-in.

Impact:

Have existing portal initiatives actually improved experience of users, if nothing to compare to how can they tell

Feedback/survey systems, how have they measured client-satisfaction Success:

can they find it: location of information, a problem with large webs is redundancy/replication of content/intent

support: what systems are in place to help

community: if user actually felt a part of the community, then that might be major success indicator

audience: content classification aiming channels at specific audiences, identification of them, taxonomies

contribution: ease of contribution to the environment or corpus, content, comment, discussion, collaboration

personalisation: useful where stock audience type not appropriate, or where member crosses many audience groups

internationalisation: high maintenance effort if iln8 content, but even stock stuff might help

extensibility: must be a framework which can be extended to cope with developing technical/culture influences, both internal and external

integration: with other enterprise data stores, authentication mechanisms, authorisation, existing portals, websites, applications, and external portals and agencies and eCommerce providers/partners Failure:

will probably be difficult to extract from portal reps, not publicised

security or privacy breaches, compromised data exposure

support resource: developer community, technical knowledge, content admins, commercial support all critical

build/buy/partner: failure of loads of CMS/portal implementations

Buy-In:

must be collaboration across all stakeholders, technical/business/academic input

legacy portal app owners/stakeholders might be resistive, integration and syndication key here initially instead or re-engineering

If the majority of your functionality is bundled in one portal, then youre gonna use that and not the enterprise one. its possible that existing portlets will present this 80%/20% and will become the focus for some folks.

Existing Stores and Info Sources

These stores may be static or dynamic in nature. They may also be portals in their own right.

• Portals
• Databases
• Applications
• Web Content
• App/Office Documents, Streaming Audio/Video

---

See Also: Web Hosting | Plum Tree | Notes Index

---

 Top Of Page     Home     Wiki Home     Contact     Author