- Ontology (Computer Science), Service Design, Requirements Engineering, ITIL, Business Analysis, IT Service Management, and 16 moreITSM, Requirements Management, Service Design Package, SDP, Service Portfolio, Ontology, Service Management, ITIL BABOK Requirements Analysis "Service Management" itSMF "Business Analysis", Sdp Itil V3, Itil V3 Service Design Package, Example Service Design Package, Itil Sdp Template, History, Information Technology, Development Studies, Ethics, and Moral Philosophyedit
- I am now the author of four books: Collaborative Consulting – TSO 2013 An Integrated Requirements Process - Governing Cost & Risk in Business Analysis - itSMFsa 2013 Metrics for Service Management: Designing for ITIL – VHP 2012 Metrics for IT Service Management – VHP 2006 The book on an integrated requirements process started as a white paper that won the itSMF International's annual white paper pri... moreI am now the author of four books:
Collaborative Consulting – TSO 2013
An Integrated Requirements Process - Governing Cost & Risk in Business Analysis - itSMFsa 2013
Metrics for Service Management: Designing for ITIL – VHP 2012
Metrics for IT Service Management – VHP 2006
The book on an integrated requirements process started as a white paper that won the itSMF International's annual white paper prize. It is here: http://independent.academia.edu/PeterBrooks
I first became interested in the subject of metrics when I went to help deliver an ITSM project (based on ITIL) to Samsung Semiconductor in South Korea for Hewlett Packard. In the end the project went really well - so well that Samsung won an achievement award from the itSMF in the UK. It was quite a challenge, though, working in a different culture and language.
One day it came to the time to help Samsung define metrics for all the processes they were designing for their Service Management processes. I went to see if there were any samples of the sort of thing on the web - and there was nothing. So I had to work with Samsung, and the ITIL books, to design some from scratch.
When I got back to Cape Town, I thought it would make sense to use this work so that others could benefit from my experience - and not find, as I did, that there was not advice on this important topic.
So, working with the very helpful editors at Van Haren Publishing and a large and very helpfully critical group of reviewers, all members of the itSMF (IT Service Management Forum), I produced the first book, based on ITIL version 2, 'Metrics for IT Service Management'.
A few years later, with ITIL version 3 out and the new update ITIL 2011 on the horizon, it was time to re-visit metrics again. I started from scratch an wrote a quite different book, looking at metrics from the ITIL 2011 perspective, in particular, understanding the design of metrics to enable an organisation to deliver more value to its stakeholders.
Again, a large team of reviewers helped me improve the book - in particular, I changed the whole flow of the book to make it more approachable and the diagram on the back cover is a guide to the structor of the book to help navigate readers through it.edit
A reliable, secure, integrated platform will be required for Free OpenSource (FOSS) to be generally accepted as, from a reliability and security perspective, the only responsible platform to select. There are shortcomings with existing... more
A reliable, secure, integrated platform will be required for Free OpenSource (FOSS) to be generally accepted as, from a reliability and security perspective, the only responsible platform to select. There are shortcomings with existing platforms and this paper, after discussing them, proposes an Ada FOSS platform as a replacement, as well as a candidate for a reliable Internet of Things (IoT) network. A possible programme to achieve this end is discussed.
Key words: API, APSE, Ada, Cyber Resilience, CyberSecurity, D5London, Efficiency, FOSS, Futurology, Future, Governance, IT Service Management, ITIL, Infosec, IoT, Linux, Maintainability, OS, Open Source, OpenSource, Operating System, Resilience, Risk, Security, Service Governance, Simplicity, Software
Key words: API, APSE, Ada, Cyber Resilience, CyberSecurity, D5London, Efficiency, FOSS, Futurology, Future, Governance, IT Service Management, ITIL, Infosec, IoT, Linux, Maintainability, OS, Open Source, OpenSource, Operating System, Resilience, Risk, Security, Service Governance, Simplicity, Software
Research Interests:
Service Management has been defined, in part, by ITIL since the last century. It is a mature library of five core books that had their third major revision in 2007. Business Analysis has, as a discipline, been around probably as long as... more
Service Management has been defined, in part, by ITIL since the last century. It is a mature library of five core books that had their third major revision in 2007.
Business Analysis has, as a discipline, been around probably as long as Service Management, but only relatively recently has its practices been codified. Firstly by the formation of the IIBA in and the publication of A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) in 2003. This book has most recently been updated in 2009 and provides an excellent description of the Knowledge Areas and work involved in Business Analysis as a discipline. The book also makes the important differences between Business Analysis and Project management very clear, something that should help remove the common confusion between these activities.
Unfortunately, to read both ITIL and BABOK would be to believe that they had arisen in quite different universes. Though they both cover important, very closely related areas, they use different terminology and different approaches to the same things.
Both, however, add much value to the job of Managing IT so that it provides value to the business. Combining the best practices found in both ITIL and BABOK would add considerable value to practitioners in these areas, as well as in the development of the valuable knowledge in both disciplines.
Business Analysis has, as a discipline, been around probably as long as Service Management, but only relatively recently has its practices been codified. Firstly by the formation of the IIBA in and the publication of A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) in 2003. This book has most recently been updated in 2009 and provides an excellent description of the Knowledge Areas and work involved in Business Analysis as a discipline. The book also makes the important differences between Business Analysis and Project management very clear, something that should help remove the common confusion between these activities.
Unfortunately, to read both ITIL and BABOK would be to believe that they had arisen in quite different universes. Though they both cover important, very closely related areas, they use different terminology and different approaches to the same things.
Both, however, add much value to the job of Managing IT so that it provides value to the business. Combining the best practices found in both ITIL and BABOK would add considerable value to practitioners in these areas, as well as in the development of the valuable knowledge in both disciplines.
Research Interests:
Economists predict that we will see a massive increase in the number of mergers and acquisitions over the next few years as a natural outcome of the great recession. In financial terms mergers nearly always result in a net loss of value.... more
Economists predict that we will see a massive increase in the number of mergers and acquisitions over the next few years as a natural outcome of the great recession. In financial terms mergers nearly always result in a net loss of value. To minimise this risk and to be successful, the new company needs return to normal operating conditions as soon as possible. The longer the disruption, the greater the loss of value to shareholders and other stakeholders is likely to be.
An ability to identify and then adopt, merge or adapt the services from the two operations quickly and effectively would enable the time to a return to normal operation to be kept as short as possible. It is just that ability that the Service Design Package (SDP) provides to businesses. This is a powerful message for any Board of Directors seeking a long-term preservation of value.
The ability to implement a real SDP, as opposed to showing slides of the concept, is something of genuine and lasting value to businesses. The crucial requirement for these organisational re-structuring, and even for a consistent approach to Services in a large, multi-divisional company, is that systems are compatible. That is, they can inter- operate, and that historical information can be preserved through the merging of different service delivery platforms and mechanisms without extensive and expensive re-work.
This is not possible today, and this will become more visible as a problem as the predicted increase in the rate of mergers develops.
The fundamental reason that it is not possible is that there is no common, underlying structure defined for services. Such common underlying structures are known as ‘ontologies’ and are recognised as a desirable end-point. They have been seen as very difficult to implement.
This white paper presents a pragmatic, and practical approach to developing an ontology for Service Management that allows simple, reliable, easy to use, structuresthat can incorporate existing tools. This approach allows for a gradual, staged transition from the current state of tools that can’t easily exchange data with other tools, to one where they can.
At first encounter, the SDP appears to be a useful, simplifying notion, drawing together the different phases of the ITIL V3 lifecycle. It is, but the closer you look, the more complex and difficult to implement it appears.
This white paper paints a picture of what an effective SDP would look like, and suggests a simple and practical method for implementing one. As usual, it is important to note that what matters is the overall delivery of services and a defined data structure is most certainly not enough for that, it is, however, a powerful facilitator to the design of tools to make the effective and efficient delivery of services much easier to achieve.
An ability to identify and then adopt, merge or adapt the services from the two operations quickly and effectively would enable the time to a return to normal operation to be kept as short as possible. It is just that ability that the Service Design Package (SDP) provides to businesses. This is a powerful message for any Board of Directors seeking a long-term preservation of value.
The ability to implement a real SDP, as opposed to showing slides of the concept, is something of genuine and lasting value to businesses. The crucial requirement for these organisational re-structuring, and even for a consistent approach to Services in a large, multi-divisional company, is that systems are compatible. That is, they can inter- operate, and that historical information can be preserved through the merging of different service delivery platforms and mechanisms without extensive and expensive re-work.
This is not possible today, and this will become more visible as a problem as the predicted increase in the rate of mergers develops.
The fundamental reason that it is not possible is that there is no common, underlying structure defined for services. Such common underlying structures are known as ‘ontologies’ and are recognised as a desirable end-point. They have been seen as very difficult to implement.
This white paper presents a pragmatic, and practical approach to developing an ontology for Service Management that allows simple, reliable, easy to use, structuresthat can incorporate existing tools. This approach allows for a gradual, staged transition from the current state of tools that can’t easily exchange data with other tools, to one where they can.
At first encounter, the SDP appears to be a useful, simplifying notion, drawing together the different phases of the ITIL V3 lifecycle. It is, but the closer you look, the more complex and difficult to implement it appears.
This white paper paints a picture of what an effective SDP would look like, and suggests a simple and practical method for implementing one. As usual, it is important to note that what matters is the overall delivery of services and a defined data structure is most certainly not enough for that, it is, however, a powerful facilitator to the design of tools to make the effective and efficient delivery of services much easier to achieve.