We are planning our cfg prc, and have defined all roles and responsibilities, except the one the deals with the DSL/DHS.

I really think we should have someone responsible for them. Someone to control the in/out of CIs, checking that they are correctly identified and correctly registered in the cmdb. It would be like the "one that has the key", as no one would have access to he DSL/DHS but him.

I would like to hear from you guys if you have this kind of role in your cfg prc. I did not see a role like this in itil books, but I think that the DSL/DHS must have an owner, otherwise it will be difficult to enforce control...

This is the challenging issue for ITILers, but basically the answer would be like Viking's favorite words: it depends (evil laughter)

DSL and DHS are usually associated with CMDB, so this means Config Mgmt should be the one who takes care but in relation with the structure of the databases.
The book says that "The CMDB is updated and referred to throughout the Release Management process concurrently with updates to the DSL ..."

On the other hand, the contents of the DSL and DHS should be the responsibility of Release Management, whether they make updates by themselves or ask Config Mgmt to do the updating.

So, there would be two possibilities about who owns the DSL/DHS: Config and Release Mgmt.

Actually, we could have all of it with the configuration manager. But the logical DSL is already managed by another team, they are used with it and they do it quite well. So we rather not change it, as it would not give us any benefit. At least, we can't see it for the moment.

Another issue is that currently the physical DSL and the hardware store are with the Help Desk team. I think they will not like loosing it, arguing that they need it, as they are always installing software or changing hardware. But they are so disorganized that I think it is worth the fight.

We also do not have a formal release management process, nor are we working on one right now. But all this DSL/DHS thing looks much more like a release responsibility than actually a configuration one. So I am trying to think only in terms of configuration management. Then the question: What would be the responsibilities of configuration management regarding the DSL? Maybe only the control of its integrity and its security ("the key holder"). When we start planning a formal release management process, we will sure dive deep into the DSL needs, but for the moment I tend to only worry about keeping it safe and organized.

Is this one way you and other guys in this forum deal with it? I would like to hear some experiences from the "real" world, as theory is important, but it does not pay our bills...

More or less the same, in relation with which one comes up first.
One thing to clarify:
I have to disagree with the physical-logical owner thing.
What I have in my company is that:
Physical hardware store is owned by General Affair
Physical software and document store are owned by Quality Management System Library (some contracts are also kept by General Affair).
Before the CMDB was created, they have their own list of inventory, not yet integrated and subject to their respective needs.

Configuration Manager deals more with the logical things of hardware, software, documents and HR.
Release Manager is the user of the DSL/DHS although when they were created, it was based on the RM's requirement.

Document store: Configuration Manager (he already does that anyway)
Physical store (hw/sw): A guy from the HD (I lost the fight, but at least now that the responsibility is clear, they will have to be more organized, otherwise they will loose it definitely)
Logical store (sw): As we have different DSLs for each "brand" (Windows, UNIX, Oracle) we will have a person from each group responsible for its own "brand".

My opinion is that it is a little against the "take down the silos" approach of ITIL, but anyway theory must always be adapted to each organization needs and culture...

Maybe we can change that when we begin planning the release process... Maybe not...

I am reading V3 books (again, because in order to really get it one must read it 250 times ) and I've noticed that in this version the DML (the new name for the old DSL) is now under the full responsibility of the config process.

The release mgm process is now only a user of the DML. It asks for an asset and after using it, it returns the asset. But it is now clear that config mgm holds the key to the DML.

Of course that is just theory, and one should always adapt it. But it is important to point out this shift in thinking...

Really?? I am getting a bit confused now on my knowledge the DSL/DML/DHL (all are libraries in V3) are all controlled by
release Management, configuration management is always informed on changes to these DSL/DML/DHL (eg. version change/control). release management is accountable and responsible too for managing these libraries._________________------------------------------------------------------
ITIL V3 Certified --Intermediate level
Service Transition management.
Manage the change and change the management to an improvised tool

It's a good thing it's a sunny day here. Otherwise my head would hurt wading through this acronym soup.

I say the above in case the following demonstrates a total ignorance of your topic.

Quote:

"The CMDB is updated and referred to throughout the Release Management process concurrently with updates to the DSL ..."

- asrilrm quoting the "book"

Quote:

Maintain the integrity of the DML is explicitly mentioned as one of the procedures that must be put in place by CM process in ITIL V3 Service Transition book.

- ChasingSleep

Quote:

All software in the DML is under the control of Change and Release Management and is recorded in the Configuration Management System.

- IT Process Wiki by a company called IT Process Maps GbR (easy to find through google).

That's as far as I've got. I'm not saying this is complete or definitive (!), but it seems enough to proceed as follows:

1. a) The DML is a library and therefore
b) needs to be in the hands of a librarian who
c) has the appropriate skills and expertise for the role.

2. The DML librarian is responsible for the maintenance and access and use of the library.

3. The DML librarian is required to ensure that the library is subject to change management, release management and configuration management, just like any other CIs in the ITSM system.

4. The DML librarian is no more required to be "owned" by ChM, RelM or ConfM than is the (say) the server manager.

If we are to make sense of such statements as "X is controlled by release management [configuration management, change management, or anything else management] it is that X is subject to those processes, not that X is their responsibility. Everything is subject to, and everyone (whatever their role) is required to adhere to, those processes. Thus:

Quote:

My opinion is that it is a little against the "take down the silos" approach of ITIL, but anyway theory must always be adapted to each organization needs and culture...

- ChasingSleep

... doesn't go far enough for me. The issue is not an ITIL issue in that sense. In this context ITIL is about process, not about organization (it's hardly ever about organization). Even if you build your organization around the processes, at most, that becomes a factor in deciding where to place ownership of "physical" entities as distinct from owning the control of how they are managed. So who the DML librarian answers to is down to the practicalities of your particular organization and is not an ITIL matter beyond the fact that ITIL helps you understand those practicalities.

One useful thing, especially in large organizations, is to follow the chain of command up from the DML librarian and see if it rests sensibly further up or if a dotted line is appropriate for it. If neither of these fits, then perhaps it is in the wrong place._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718