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
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').
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').
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.