- Channel HP
- :
- Enterprise Business Blogs
- :
- Services
- :
- ITILigent Service Management
- :
- How to architect a Service Management System? The ...
- Subscribe to RSS Feed
- Bookmark
- Subscribe
- Email to a Friend
- Printer Friendly Page
- Report Inappropriate Content
How to architect a Service Management System? The Implementation View...
Architecting an ITIL based Service Management System for a medium to large enterprise organization requires more than a single picture to be produced. There are typically many stakeholders to take into account and multiple views are required to understand added value, positioning, content and implementation aspects.
This is the last of four blog posts that will each describe a different architectural view on realizing a Service Management System. The last view is called: The Implementation View. This view is targeted at project managers, developers, testers, deployers and operators and provides an answer to the main question: "how to implement a service management system?".
And in order to answer the main question a number of related questions need to be looked at, e.g.:
- What specific products and services?
- How to develop and deploy?
- How to validate the service management system?
- How will the service management system be managed?
Previously in the Functional View we have seen that ITIL v3 is addressing the business problem by putting the focus on services as the main output of a service management system. In addition we looked at what's inside a service management system by zooming in on service asset types (resources and capability) and their relationships.
Now these are all interesting concepts, however… ITIL is a framework, not a cookbook while each organization consists of a unique mixture of service assets. So, how to actually implement a service management system?Answer: by transforming IT!
Large IT transformations are mostly realized via comprehensive programs that consists of multiple projects that are each cost justified to deliver tangible results and measurable benefits. From a big picture perspective the program as a whole as well as each sub-project typically goes through a number of phases:
Analyze and Plan
- Assign project resources
- Validate & approve initial project plan
- Create business case
- Perform assessment
- Create solution architecture
- Select & acquire products
- Develop training plan for project resources
- Conduct project kick-off
- Finalize planning documentation for next phase
Design
- Install technology test & development environment
- Train project resources
- Perform process workshops
- Create organizational design
- Design technology architecture
- Create build & test plans
- Define deployment strategy
Build & Test
- Configure technology development & test environment
- Develop work instructions
- Perform solution testing
- Build organization details
- Create deployment plan
- Prepare staff training
- Install & configure new technology production environment
- Perform pilot tests
Deploy
- Communicate solution go-live
- Activate technology production environment
- Execute organization transition plan
- Train staff
- Activate processes
- Support staff
- Evaluate deployment
Operate and Improve
- Execute processes
- Monitor and manage daily operations
- Coach staff
- Generate reports
- Identify & implement solution improvements
- Establish continuous improvement plan
- Review and evaluate project
- Obtain project signoff
In going through these phases and activities, you will learn that ITIL alone is not enough. There are more standards that can/should be considered, such as the Capability Maturity Model Integrated (CMMI) and/or the Control Objectives for IT (COBIT).
Another key thing is that processes are defined within (lots) of documentation, however they are realized by people working with technology. Which brings me to one of my favorite remarks during presentations:
“It is easy to (re-)configure technology but…it takes a lot more effort to (re-)configure people” Jeroen Bronkhorst
And if you look at the typical reasons on why IT transformations fail, it mostly comes down to people aspects such as:
- People don’t understand the business case
- People are not integrated & engaged
- Technology changes outpace people’s preparedness
- People fear the impact on their current jobs
- Leaders do not “walk the talk”
This is also why there are many people related activities listed in each of the phases above. It all comes down to a "simple mathematical formula":
Do you agree?
Regards,
Jeroen Bronkhorst





