itSMFI 2016 Forum Focus - December Forum Focus ITSMFIV3 | Page 25

transformations will become more business driven delivering
immediate business values.
What are Service Architecture components?
A visual of the key components is provided below. The
components are requirements; support model; support
organisation and people; governance; communications; tools
and service management processes.
Service requirements: Business expectations of how a service
should behave are identified and translated to tangible
service requirements. The requirements could be service
level targets (e.g. high priority incidents to be resolved within
4 hours), desired end user experience (e.g. working on
corporate email should be no different from working on
personal Gmail), specifications for catalogue providing service
selection (e.g. portal to easily order IT requests), language
requirements (e.g. ability to raise tickets in five languages) and
so on.
A typical model is to group the IT capabilities into towers and
allocate the services and underpinning technologies each
tower can support. The operational support is provided
through service tickets such as incidents, requests, changes
and problems. Major service changes trigger a launch of
projects or programme with a valid business case.
Organisation and people: ‘Who’ element of the support is
addressed here. A landscape of entities supporting the
towers, or services within the towers, is developed
collaboratively with the vendor management. Existing and
strategic sourcing models are assessed, a number of
options are derived and a most suitable sourcing model is
selected. Size of the support teams, roles, responsibilities and
skills are defined to bring in the right set of support
resources.
Governance: The governance assures the Business that IT
services are under control. Service quality assurance and
management of suppliers will be of paramount importance
to any successful transition. Governance structure is
developed factoring in business functions, IT functions and
suppliers. Maturity of pre-existing forums is assessed and
more formalised where required.
New strategic, management and operational forums are
defined through Terms of Reference where necessary.
Mechanisms for consistent interactions with the business
stakeholders, service owners and suppliers are established.
Communications: A key for the success or failure of any
project. It articulates the user impacts, benefits, timelines,
statuses and service features to the end users. This is
Support model: A blueprint of how new or changed critical to gain end user and thereby Business confidence
technologies will be supported post implementation. An and instill a good user perception of the service.
Communications are typically of three types -“service is
example model for a banking sector shown below.
coming”; “service has come”; and “tips for using new
service”.
Service architects work with communication and
organisation change specialists to design the messages and
agree the most suitable communication channels for
distribution. The scope also includes user training and
awareness sessions.
Tools: Design of Service management tools as part of
service enablement is inevitable as almost all organisations
embrace process automation. This will define the
configuration and potential customisations required to
build the service models in the tool (e.g. new support
groups, service levels configuration for new support groups,
amendment of change approval workflow, self-service
portal etc.).
Processes: The most popular and bulky one – service
management process. The process diagrams are designed
adopting ITIL framework and common practices where
25 itSMFI Forum Focus—December 2016