Strategizing an Intranet for the government
My team recently attended a presentation by Gartner Research called “Enterprise Portals: Their Strategic Future, Market and Value.” This was an exciting time for us because it gave us a few ideas on our own Intranet Portal project, and it helped validate most of the decisions we’ve made about the project.
Some ideas we got from the presentation
Deploying an Intranet or portal to the whole enterprise at once is a bad idea. We should deploy the new Portal to a few agencies at a time and investigate their needs before moving on.
When an agency is migrated to the new portal, we must cut off their access to the old portal immediately. People resist change and will not use the new portal if the old one is still present.
There is an open web service standard called WSRP that we should look into. The standard ensures a maximum amount of interoperability between portal applications, also known as “portlets.”
The pages at www.franklincountyohio.gov are basically a portal too; they just serve a different audience.
Our portal can bring these other applications together. We should consider doing iterations through the following elements:
- Business Intelligence
- Knowledge Management
- Document Management
- Shared Team Space
- Mobile Access
Decisions of ours that were validated by the presentation
The value of a portal is that it allows access to a large amount of data, all using a single user interface.
When developing a portal, the portal team should be entirely focused on the user. The team should design for your everyday user, not power users. Users care about their perspective on the data, not the enterprise’s org chart.
Microsoft SharePoint is not a good product to use for enterprise-level portals. It offers a good service framework built into Windows 2003, but its interfaces are not well-suited for an everyday user. Most deployments in the government are at the department or agency level, not the enterprise level. Most deployments happen because SharePoint is cheap and the IT staffs don’t have the resources to build a portal using another technology.
Portals and content management are two entirely different problem sets.
It is smart to build a portal with a Service Oriented Architecture (SOA). Two of our Portal v2 applications have open web service APIs.
By 2010, 30% of portals will include some interfaces that use a rich client (AJAX, Adobe Flex, Microsoft Avalon). The infrastructure we have built is ready for such interface elements.
Other applications Gartner suggested that our new Portal already includes at some capacity (or will include soon):
- Content Management
- Web Services
- Business Process Management