First, we must deal with the formative processes that brought us to this little semantical circus. I point fingers here!

First, at ITIL, for putting a "thing" and a "process" in one definition, SACM. Service Asset is the "thing" and Configuration Management is the "process". Now we may charitably concede that the title was meant semantically to mean, the Management (process) of both Service Assets and Configurations. But this gets problematic. To solve the problem we must first think about why the definition of "asset" differs depending on the context and who is doing the defining.

At ITAM - IT Asset Management - for attempting to own everything that contains the word "asset". Because of the first problem, an undetected and process-affecting dynamic is inserted into the ITSM process-building. Symptoms include

- TCO creep and bloat. Can't seem to quite account for the operational overspend when the plan looked great? What is Operations having to do to make it do what we want it to do? There is time and cost leaking out of some miniscule process whose implementation turned out to be less-than-optimal.

- Difficulties aligning technology to the assigned tasks. You have a product whose vendor doesn't quite seem to get what you are doing and why you are trying to make it do something? Make sure you are using the right tool for the right job. For example, don't try to make your Asset Management system be your CMDB or try to understand service dependencies and complex topology.

- Similarly, the inverse is true for CMDB. Pressing a CMDB into service as an Asset Management system places scale and cost limits on what you're going to get done.

At Individual perspectives, for emphasizing their strengths and experiences. But of course I jest - wouldn't you? The constructive part here is realizing that it is our formative experiences that remain ununified, causing problems when we try to bring these things together without a clear understanding of the domain boundaries and interactions.

So what is an "asset"? There are at least three definitions. You've got your traditional definition, balance sheets, debits and credits, etc. An asset is something of fiscal relevance. ITIL's definition differed in common understanding vs.. Intent - what they meant "asset" to mean was, some type of useful grouping of CIs. But the implementation was all over the place. "assets" could be whatever was in the CMDB, whatever was in the AM system, whatever was "on the books", or even whatever might be changed (all actual definitions I have heard over the years).

We also have this thing called a "service asset". Whatever is part of a service. Wait a minute, Jody, did you mean, "whatever is a configurable part of a service? Or maybe a "real" part of a service?

A service asset is not just a "thing" or not just an "asset". It's anything required to manage, support, operate, or provide a service. Real and "unreal" things included. Unreal? I mean an ephemeral entity that is part of a service's configuration, such as, what port an application that is part of the service may use to communicate between a client and a server. So yes, "443" might be a service asset, even if it has no cost (fiscal relevance). So a "port" type CI does belong in the CMDB. Problem is, the server that uses the port is clearly a "real" asset and is hijacked to the asset management system, unable to be properly present - and authoritative - along with it's ephemeral friend the port. So now you have duplication and synchronization between the asset management system and the CMDB, you have to decide who consumes from which when, etc.

I am not going to try to redefine any of these "asset" definitions. If I can understand them all - and know when to ask for the proper context - we can align and get our CMS projects working optimally. That's all I ask - don't get confused by multiple definitions of the word "asset". Understand that there are multiple definitions that are highly interactive. You can get control of this by establishing a pocket of purity - within one group, one team, one data center, one IT environment, one company - THIS is what we mean when we say "asset".

Now, we are just getting warmed up on the CMS value chain. I'll stop here and hope this helps some of you. If it does, or if this makes sense or not, please let us know with a reply. Thanks!

Neither ITIL or ITAM is dispositive on anyone in the United States. They are both good practice references to be adopted in a way that achieves the prize for that organization.

Second, it is a false choice to decide that something has to be either in one system or the other. Different systems have different views and different purposes.

ITIL is focused on the operational aspects of internal systems. It seems to take a view similar to Ford's old River Rouge plant - that IT must do everything.

At one point, River Rouge was the single largest plant in the world - iron ore, coke and other resources coming in one side, cars coming out the other. Now is the final assembly plant for Ford trucks. Because manufacturing changed from producing everything in one place to a view of design and assembly - with management of the supply chain in between.

And, just like River Rouge, IT will change. The Supply Chain of Cloud is ensuring that. Configuration Management may no longer be as important as it once was. Now the focus will be on management of contractual rights and responsibilities.

The prize would seem to be managing IT as a business within a business - managing the different services and their parts. Because, the means of production, the configuration, is likely to be out of IT's view and provided as a service by someone else.

Then will not that "someone else" need configuration management? The names may change but the games remain the same. Do we think cloud is going to alleviate the need for change management? incident/problem/release management? I agree the app focus will shift, and configuration management will commoditize to those who do it best - I'm fine with all that business I can bring my way. A proven, affordable model that's easy to operate and fix is a very fine customer base to grow the real visionary stuff.

As you pointed out, however, one does not preclude the other. Services from an IT point of view must align with that of the business's, or IT will never 'grow up', no matter what the delivery mechanism is. Cloudy with a change of configuration management? We'll see.