Float like a butterfly. Sting like a bee.
(Muhammad Ali)
 

How intranet portals differ

The special thing about web-based portal intranets is that they are at one-and-the- same-time an infrastructure, an application set, a development framework and a repository of content. As such, a one-size- fits-all approach to support will just not work well.

Just like Ali's infamous catch-phrase, you will need to be quick and nimble enough to handle the small things, whilst powerful enough to also tackle more major issues.
 

The three-tier model applied to intranet

The so-called 'three tier' support model is still appropriate for intranet portals and (in fact) works particularly well if sensibly applied to the challenge.

Tier One Support

The first tier (as for any system in your organisation) is fault management, where a helpdesk operation acts as a single point of contact for all faults to be logged.

It is only by logging faults in one place that the customer can have a single team to go to for progress updates on all the IT problems they are currently experiencing.
 

Tier Two Support

The second tier is problem management, whereby faults are converted to problems.

All faults logged by the helpdesk as being 'with the portal' should be passed to the level 2 portal support team for analysis. The level 2 team will investigate the 'symptoms' of the problem: For example, if someone is having problems accessing the portal, does this appear to be an isolated incident (suggesting a problem with the user's PC) or a wider problem (say in an entire building)?

Following this investigation, an initial 'diagnosis' of the problem is made and the problem passed to a specialist unit for 'treatment' and resolution.
 

Tier Three Support

Where the level 2 diagnosis suggests a problem specific to the portal, the level 3 portal support team will take on the item for problem resolution.

Where the problem appears to be related to (say) the user's desktop, then a separate team (in this case desktop support) would be allocated the item. All three level of support access the same support systems to progress the item.

Why this works well for web technology

One of the features of web technology is the many layers to the architecture and (along with that) the multiple possible points of failure.

For example, a problem could turn out to be be hardware related in either the web server, app server, database, firewalls, routers, load balancers, etc. etc. Or software (including operating systems) residing on any or all of those boxes could be at fault. Alternatively, middleware or problems in underlying legacy systems or networks could have caused the fault.

As there are so many possible causes, your level 2 support team will need to be particularly strong; experienced and multi-skilled ('stinging like a bee').
 

Configuration Management

Again, because there are so many points of failure, configuration management is of particular importance. Your level 2 support team will need to be kept informed of any changes to any of the systems that may affect the portal on a real-time basis.
 

Managing changes to the intranet portal

In the steady state governance chapter
above, I highlighted the importance of having 'small change' resources working alongside the support team, to maintain agility ('floating like a butterfly').

In many cases, it will be expedient to hire people into the level 2/3 support team that are also capable of managing small changes to applications (or even building new small apps themselves). This will help to keep costs down and allow for tighter configuration management.