Jorgen Skogstad's Weblog. A smallish domain where I get to express my thoughts and views on important (?!) things that I care about; ITSM, ITIL, Governance, Infrastructure Intelligence.. and so forth! Jorgen Skogstad's Weblog

Sun Microsystems Mexico sponsored the Pink Elephant 4th annual ITSM conference in Mexico, and Sun presented a session based on Pragmatic Service Management.[Read More]

 

Kindest! 

This year has been fun!! We've enabled a true global delivery enablement for our Managed Operations services portfolio, and we've done road-shows, events, press briefings, talks across the region. Looking back we've been to the following cities across the Asia/Pacific region: Tokyo/Japan, Singapore, Kuala Lumpur/Malaysia, Bangkok/Thailand, Seoul/South Korea, Delhi/Mumbai/Chennai in India, Melbourne/Perth/Brisbane/Sydney in Australia and Auckland/Wellington in New Zealand. Shortly there will be a Greater China event in Macau as well.. all in all we've met a lot of interesting people, talked to a number of them, had great fun, shared thought leadership, ideas, road-maps, capabilities .. and just to give you an example of the content we went through, I thought I would share a quick pod-cast from one of the events we held. This pod-cast stems from a Customer Briefing Series event that was held in Sydney/Australia on the 22nd of November 2006. The file itself is about 16mb and is an edited version of the whole session. Most of the talk is done by myself and Stephen Power (Sun colleague), and you can find it here! Due to the size, I had to place it on my own system for easy access.

.. and not forgetting; if you have any questions, comments, suggestions etc.. please do not hesitate to get in touch .. anytime .. anywhere! 

Enjoy!

 /Jorgen Skogstad

 

 

 

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

 /Jorgen Skogstad

 

Over time I have been engaged with several 'agile infrastructure' projects and many of them with organizations that have adopted ITIL as their best practice foundation. All of that is just fine, but there is a gap in how 'infrastructure agility' is adopted/implemented and how the adopted ITIL 'framework' is able to cope with it and support it. This becomes very evident in the application and service provisioning space as the current definition and scope of the 'definitive software libraries' within "ITIL" is somewhat limited. For a long time I have been wanting to capture some of these 'findings' and write up a paper on it and finally I have completed it.

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 (jorgen.skogstad@sun.com) or at my private email (jskogsta@pogostick.net).

In any case; have a good one!

Many organisations are frequently investing in IT Service Management and ITIL in particular. In my experience the focus of most of this, is in the 'standard' ITIL Service Support 'domain'. Why? Well, I guess it is since it shows how a well functioned IT organisation should work with an integrated process set. The misconception though, is that the ITIL processes themselves will 'solve' most of the deficiencies experienced in this field. This, according to my experience, is not true. An adoption of ITIL's best practices has to be augmented with the practical working processes and routines that makes 'IT tick'. There is so much more to working IT than just adopting ITSM and ITIL best practices, hence one of my focus areas have been the practical approaches that are required to augment and underpin such initiatives.

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!

With respect,
Jorgen Skogstad (a Norwegian expat living in the sunny down under ..)

I got this before heading off for vacation half a year ago. I still find it amusing since it - sort of - captures the typical aussie replies ... I love their mentality!

Australian Tourism FAQ

These questions about Australia were posted on an Australian Tourism Website and obviously the answers came from a Aussie.

1. Q: Does it ever get windy in Australia? I have never seen it rain on TV, so how do the plants grow? (UK)
A: We import all plants fully grown and then just sit around watching them die.

2. Q: Will I be able to see kangaroos in the street? (USA)
A: Depends how much you've been drinking

3. Q: I want to walk from Perth to Sydney - can I follow the railroad tracks? (Sweden)
A: Sure, it's only three thousand miles, take lots of water...

4. Q: Is it safe to run around in the bushes in Australia? (Sweden)
A: So its true what they say about Swedes.

5. Q: It is imperative that I find the names and addresses of places to contact for a stuffed porpoise. (Italy)
A: Let's not touch this one.

6. Q: Are there any ATMs (cash machines) in Australia? Can you send me a list of them in Brisbane, Cairns, Townsville and Hervey Bay? (UK)
A: What did your last slave die of?

7. Q: Can you give me some information about hippo racing in Australia? (USA)
A: A-fri-ca is the big triangle shaped continent south of Europe. Aus-tra-lia is that big island in the middle of the pacific which does not... oh forget it. Sure, the hippo racing is every Tuesday night in Kings Cross. Come naked.

8. Q: Which direction is North in Australia? (USA)
A: Face south and then turn 180 degrees. Contact us when you get here and we'll send the rest of the directions.

9. Q: Can I bring cutlery into Australia? (UK)
A: Why? Just use your fingers like we do.

10. Q: Can you send me the Vienna Boys' Choir schedule? (USA)
A: Aus-tri-a is that quaint little country bordering Ger-man-y, which is...oh forget it. Sure, the Vienna Boys Choir plays every Tuesday night in Kings Cross, straight after the hippo races. Come naked.

11. Q: Do you have perfume in Australia? (France)
A: No, WE don't stink.

12. Q: I have developed a new product that is the fountain of youth. Can you tell me where I can sell it in Australia (USA)
A: Anywhere significant numbers of Americans gather.

13. Q: Can I wear high heels in Australia? (UK)
A: You are a British politician, right?

14. Q: Can you tell me the regions in Tasmania where the female population is smaller than the male population?(Italy)
A: Yes, gay nightclubs.

15. Q: Do you celebrate Christmas in Australia? (France)
A: Only at Christmas.

17. Q: Are there supermarkets in Sydney and is milk available all year round? (Germany)
A: No, we are a peaceful civilisation of vegan hunter gatherers. Milk is illegal.

18. Q: Please send a list of all doctors in Australia who can dispense rattlesnake serum. (USA)
A: Rattlesnakes live in A-meri-ca which is where YOU come from. All Australian snakes are perfectly harmless, can be safely handled and make good pets.

19. Q: I have a question about a famous animal in Australia, but I forget its name. It's a kind of bear and lives in trees. (USA)
A: It's called a Drop Bear. They are so called because they drop out of gum trees and eat the brains of anyone walking underneath them. You can scare them off by spraying yourself with human urine before you go out walking.

21. Q: I was in Australia in 1969 on R+R, and I want to contact the girl I dated while I was staying in Kings Cross. Can you help? (USA)
A: Yes, and you will still have to pay her by the hour.

22. Q: Will I be able to speek English most places I go? (USA)
A: Yes, but you'll have to learn it first.

These days it seems that everyone considers outsourcing actually believing it will solve all business 'problems'. And every time I get to read articles, rants, reviews, stories and the likes there are always the financial advisor (or the likes) and someone who have no clue what technology actually is who actually drives the dash for outsourcing. Most often the argument is to reduce IT cost and bring better 'service quality' to the enterprise. "Bring technology under business control" I keep hearing. The principle is good. The motivation too, but what is most often missed is the indirect values of keeping IT internal rather than doing outsourcing all the way. Don't be mislead; I do think that outsourcing, in the ideal sitation, could be a good move - BUT - it should be the end result of a looong business and IT alignment - and NOT thought of as a quick-fix for "all your business driven IT needs". That last road bears a great chance of failing and in the long run induce greater IT operating expenses to the organisation.

So; what is the right way? I guess no one could actually be precise since every organisation is different, but one thing is constant. When even considering any type of sourcing it is evident that the organisation should have a clear cut and defined view on how IT and the business relates and align to eachother. Without having this clearly defined ANY type of sourcing will carry (to me) an intolerable risk of failing. In my head (out)sourcing is as such a good thing after actually have implemented a Service Management 'regime' within the organiasation. ITIL as a framework is a really good example. Through aligning and defining the IT organisations offerings, revising them and creating a process driven datacenter you carry a really good chance of being successful and delivering substantial IT cost reductions.

On the other hand; you might even find that your IT organisation now actually have delivered "on it's promises" and it is delivering the business benefits sought by the (financial) management responsible within the organisation. There are a number of examples and stories that this carries some truth. After re-defining/inventing the way IT supports the business and it's drivers; the IT organisation and the business as a whole end up being closey aligned. Why then consider breaking them when the understanding of the business as a whole is at it's greatest??? For some this does not make sense (in my head too!). The problem with this "idea scenario" is of course that implementing and driving Service Management initiatives is hard; really hard. If successful though, there is no greater weapon available!!