Joined: Aug 11, 2006 Posts: 262 Location: Netherlands
Posted: Tue Aug 15, 2006 7:51 am Post subject:
Sure, what you describe is a configuration and should be registered in the cmdb. The process of configuration management (aided by the cmdb which is only a tool) is responsible for registration and audit. This is an entirely different subject than ownership. Basicly, I would say that those who pay, own!
Therefor, i would say that if your organisation pays it's bills it owns these configurations. Resonsiblity lays with your organisation, yet the actual maintenance and design can be delegated to your suppliers (you haven't outsourced the operational part of IT for no reason!). However, being the owner you should stay in control:
When an organisation has outsourced it's IT, at least the steering of it should still be within the organisation. This stearing can / should focus on:
* financial: is the service delivered according to the right price
* accountability: do providers deliver the service on the level agreed and can they be held responsible if they don't
* supply & demand: how do providers deal with a change in your demand?
And here it comes: it should / could also be technical. A small team of tech. architects in your organisation can ensure that you can communicate with your suppliers on tech. issues, and it prevents you from getting a nasty suprise (for instance a sudden change in those 'standard' products).
Basicly, you want a service to be delivered. And a service is a different thing than the tech. aspects mentioned above. However, not many supplier/customer relationships can realy say that they are able to leave the tech. part out of any discussion. Therefor, you might as well make tech. control part of the overall steering of your suppliers.
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Tue Aug 15, 2006 10:49 am Post subject: Re: Configuration Management and Software Ownership
Hello all!Who "owns" or is responsible for the design and maintenance of the "standard" build desktop software?
Rumors are that this is Configuration however my opinion is that Configuration audit the design, not own it.
The answer to this lies outside of ITIL, as ITIL is very weak in this area. The owner of the solution is the "Product Owner". In this case, it is most likely an engineering team or someone who runs or represents the engineering team. Ultimately, the enterprise owns everything but whoever acts as the Product Owner for that product dictates the solution based on collecting and managing Requirements, Problems, Risks, and Incidents that help dictate strategy for that product.
Once that desktop build is deployed and is installed on any machine, the instance of that build is now an Asset and may be supported by a Service Delivery team that acts on behalf of the Product Owner and is ultimately accountable to the Product Owner. But, ultimately, it is the Product Owner that is responsible for all aspects of it.
Configuration Management is the process by which all teams associated with the Product manage the detailed Configurations for that Product. Typically, it is the Product Ownership team that dictates the Configuration for the build, however, a master Configuration Management team might have some insight into or requirements for the Product Ownership team that help define how to manage, generate, and/or document Configurations in specific ways so as to accommodate the needs of other teams and the enterprise, itself.
A very common problem that I run into in many enterprises is that they have not created a clear and single owner for each and every Product in their enterprise. I have found that it is critical to have that accountability in place, as it eliminates redundancy, contention, and confusion. It makes a single person accountable for the success and issues associated with that one Product. NOTE: This does not mean that you have to have as many individual Product Owners as you do Products. It simply means that you need to have a single accountable "name" or "team" that everyone can go to for any and all issues and strategy for that Product. Another mistake is that they let the teams that use the Products be Owners for them. I've found this to be dangerous, as it builds little kingdoms of power, where teams try to create job security for themselves. I recommend a centralized Product Ownership team for common or "like" Products so that economies of scale can be leveraged.
Anyhow, I hope this helps.
Regards, _________________ [Edited by Admin to remove link]
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum