Wednesday Mar 19, 2008
Friday May 04, 2007
By jskogsta on May 04, 2007
For a long time, I've been meaning to blog some thoughts around Pragmatic Service Management, and I recon it's about time I get to do it. Hence... here we go:
Pragmatic service management have been an area of specific interest to me for a number of years, and I am referring to the way one can take Service Management 'principles' and create an actionable implementation framework in place to drive requirements into actual architectures. Sounds easy, but in reality it's not. So to give you a brief introduction of what I am thinking of.. consider the 'ideal' state where you as an IT Service Manager can sit down with your business service representative (and owner?), and discuss, define and select the appropriate 'business level requirements' for either an existing service or a new one. Being able to articulate the requirements and document them is key to being able to drive SLA (and OLA!) creation and henceforth the architectural selection. However, it is always prudent to involve the technical 'owner' of that service as well, as the business requirements are generally 'overkill' compared to the cost of implementing and supporting it. So you need a balanced definition of requirements (from business and technical) to ensure a balance that takes into requirements, cost of deliver, sustainability and other factual drivers. In the end, what you agree of requirements can then be used to articulate service levels, which in term are used to select the architecture to implement on, and again preferably a standards based architecture from the defined Service Catalogue.
Have a look at the illustration beneath for the practical framework we've worked on to do this. It's a pretty neat method to drive requirements into standards based architectures, and also have a consistent, defined and agreed way to operate and manage your services.
So what does the illustration really describe? When I am referring to business requirements and technical requirements, I am in reality referring to a negotiation process that occurs. Within our process, we use questionaires and a mapping methodology to define an agreeance based on requirements and an associated service level category. If there is agreeance, the defined service level is driving the architectureal selection which is implemented in the real physical IT architecture that exists. The other important facet here is that all artifacts generated and used throughout the process is saved in the Service Catalogue (and Configuration Management DataBase - CMDB).
Sound good in theory, so does it work in practice? Being realistic, it does to a certain degree. You are able to implement the process, and drive it from there. However, being overly descriptive on how your standards are being used is another thing. hence the role of the service manager is critical, where you will have to assess the requirements of the busines and the teir technical counterparts against the 'costs' of not adopting organizational standards. That's a given, and probably something you will never get out of. However, the process itself is a good facilitative way to drive an understanding that both business and technical requirements have an impact on the organizational ability to plan, implement and operate their services. Just being able to somehow articulate requirements from both sides is a step in the right direction, and also being able to have the artifacts developed to support the agreeance is key. How many times have you seen evidence of this occuring within organizations? Probably not too often! At least I have not.
So what I have experienced with clients that I've worked with is that whatever they have done in the IT Service Management space, they have not defined an actionable framework to address something like 'this'. Most have adopted ITIL, Cobit and other 'standards' in some form. However, they are an organizational adoption of the 'standard' processes, and nothing more. Inherent in this lies the problem: these processes again need further complementing processes and actionable frameworks (could be policies as well) to "enforce" them. The Service Definiton Process is but one example of how to drive true business and IT alignment on the basis of existing Service Management and Governance processes.
I'll leave it at that, and let you ponder about this. I'll provide some more musings on the same topic 'soon', and see where it leads.
Thanks, and all the best ..
Friday Dec 30, 2005
By jskogsta on Dec 30, 2005
Here is the abstract text from the paper itself:
"Since IT Infrastructure Library's (“ITIL”) inception in the 1980's, IT as we knew it have changed. The notion of busi-ness driven IT have mandated changes to traditional IT service delivery and resource management. This reality cou-pled with the technology shift will also demand change in how process orientation in IT organizations will be handled now and in the future. This does not mean that ITIL as a best practice framework in itself is outdated. Since ITIL is a collection of generic best practices that address process orientation in any kind of IT organization, most of it holds true and will do for a long time. However, it has it's flaws, and over time it does need to change to absorb the reality of infrastructure virtualisation and hence a revised reality for IT resource management. This paper delves into how ITIL's definition of the 'Definitive Software Library' (“DSL”) is limited seen in relation to infrastructure-, application- and service virtualisation (aka provisioning) and the forthcoming technology shift."
If you find this interesting you can find the paper here [@the Sun blog site] or here [@my personal website].
If you ever get to read the paper itself and either like it, dislike it, approve or do not approve of it; I would love your comments. Hence, do not hessitate to send me any kind of comments, suggestions, notes on it. You can either reach me at my Sun email (firstname.lastname@example.org) or at my private email (email@example.com).
In any case; have a good one!
Monday Nov 07, 2005
Applied application and service provisioning can underpin and improve your Service Management "adoption" ..
By jskogsta on Nov 07, 2005
With that in mind, I was fortunate enough that I had the chance of writing up a paper for the Australian Unix User Group's ("AUUG") conferfence that was just held in Sydney Australia. The topic was "Applied application and service provisioning" and it was a general and generic approach to it. Obviously Sun have the technological base to execute in this space, but what I wanted to present was how the application and adoption of automated solutions in this space solves a number of the practical issues concerning ITSM and ITIL adoptions, irrespective of technology chosen to implement it on. To give you a feeling of what the paper is all about, the following paragraph is an extract of the paper (the abstract):
"This paper addresses facets pertaining to a software life cycle management and how application of provisioning techniques can rationalize the management of it. It describes some of the problems and challenges many organizations face today; most of them related to either people, process and/or technology. It also provides some insight into how they may be addressed through the application of provisioning techniques, though not in technical terms. This would be impossible to do within the scope of this paper. The paper also provides some real-life examples of the tangible and intangible benefits an organization could typically expect when moving to apply concepts of application and service provisioning into their environments."
I find this space extremely interesting. It's not just about the technology, but more on how it is an 'engine' that the people and processes relies on. If used carefully, it can achieve that necessary balance between the people, the processes and the technology that is required to drive alignment. Not only within IT, but even between the "business" and IT. In an agile and dynamic enterprise these solutions can lay the foundation for breaking down the barriers between the business, the 'developers', the infrastructure and operations. Obviously, care have to be taken when doing the actual implementation, but if adopted and implemented successfully it can yield substantial benefits. Just have a look at the actual findings in the paper. They stem from actual real-life projects and are just simple 'hard-facts' that came from the implementations of these projects.
All of that said, I have to say (as noted in the paper too!) that any work in this space relies on the people aspects. Without their acceptance, any work will fail. It's like one of the paper's conclusions: "Never underestimate the people when adopting a provisioning strategy. Process and technology is simple, people are not!".
... I guess this was enough for this time! Off to do some more work .. related to the 'Governance' stack. If you wonder what I am meaning with this; I might (if time permits) delve into that in a later blog entry some time ...
Comment: You can find the soft-copy of the paper at http://www.skogstad.com/AUUG/AUUG-2005-Applied-application-and-service-provisioning-0210905-FINAL.pdf
.. alternatively you can find it here too: http://blogs.sun.com/roller/resources/jskogsta/AUUG-2005-Applied-application-and-service-provisioning-0210905-FINAL.pdf
Have a nice one!
Jorgen Skogstad (a Norwegian expat living in the sunny down under ..)
- Pink Elephant's 4th annual ITSM conference in Mexico ..
- We've been doing road-shows and launches of Sun's Managed Operations services throughout Asia/Pacific over the last year ..
- Pragmatic Service Management - The Service Definition Process - Part I
- The ITIL DSL is somewhat limited seen in context of agile infrastructures! (?)
- Applied application and service provisioning can underpin and improve your Service Management "adoption" ..
- The Australian Tourism FAQ
- The Outsourcing epidemic; the saga continues ..