Technology does not fix process

People are drawn to IT by a fascination with complex technology. This is most unfortunate because this fascination blinds so many of us to the importance of the People/Process/Product trilogy.

Change and Configuration Management are processes. If the process is working, they collect and maintain good configration data (in a repository that you can call a CMDB if you insist). If the process is broken technology is not going to fix it. Bang your head hard against the desk while repeating five times "technology is not going to fix it".

If your people do not have a service management culture; if your service management processes are not well designed, bedded in to the organisation, and measured and monitored; if you do not have this situation then all the cool tools in the world are not going to fix it dammit!

Once you have the right people doing the right things in the right way, only then can you indulge yourself and spend what is left of the project budget on the shiny geegaws peddled by the vendors.

OK, that is an exaggeration: there is a place, well into the process design, when we identify opportunities for tools to help manage the process and in rare cases even help automate the process. Once we understand our people's capabilities and desires, once we understand exactly what we want the process to do, then yes we may be able to build a solid business case to buy a tool, most likely a service desk but also other operational software or even document management systems etc... START with people, then START with process, then start with technology, so in the end all three streams are in parallel.

That does not in any way undermine my basic premise though: if you have a process problem there is not a technology solution.

Here at the IT Skeptic we are not above picking on organisations, so let me use an example drawn to my attention today: Tideway. I don't doubt their product, Foundation, takes autodiscovery to the next level of embedded intelligence, to try to unravel the service dependencies. I do doubt that they have removed the manual element from the process: there are plenty of clues that they haven't: "Reduces manual effort of building business service views by up to 80%". There ought to be a law defining use of the term "up to" as an illegal business practice. I have already discussed how I'm skeptical of the ability of these tools not to be excrutiatingly stupid.

And most of all I do doubt that, except in the most complex of organisations, there will be a solid business case for replacing "up to 80%" of the manual effort with an expensive, complex, high-learning-curve tool that still requires a manual effort to check it, work out what it did, tell it when it got it wrong, add the really interesting data that it simply doesn't understand, and keep it correct in a dynamically changing environment.

Auto-discovery is very useful where initial data is rubbish: it is good for helping get a baseline set of CIs. If your Change processes are any good then you don't need it after that, though you can use it to audit data quality and detect non-compliance. And if your processes are no good, then it is not a substitute.

So, folks, please let's grow up as an industry. If you are paunchy and aging, buying a red sportscar does not fix the problem. If all the kids shun you at school, a HotWheels set is not going to change that. If you can't get your people to write down what they changed, a shiny "Automated Application Dependency Mapping" (or any of the other gadgets being peddled around the ITIL world right now) is not going to make any difference.



Indeed, points that no doubt resonate with my colleagues and I at 413 Technologies.

Having been witness and party to several extensive projects ranging from compliance to audit over the last 20 years we always felt the issue returned to one of timely discovery.

For other vendors to pile on top of 'discovery' their interpretation of how a network should be managed and what is required does constrain choices - one can find oneself stuck with nowhere to turn to when getting in bed with the more extensive toolsets (NB: these start at $50k and rise to $250k very quickly) - one prospective client, from the financial industry, told us they were avoiding Tivoli as the cost to implement and manage the Tivoli solution would have broken the budget and required hiring more resource to do things the Tivoli way.

Recently N(i)2 announced a deal with a similar tool to Tideway's Foundation - EMC Smarts - to help them provide effective discovery and configuration item mapping that would ensure they had a 'better' CMDB - see here: One may care to note they had already started selling the inferior solution and must have discovered the product was not delivering on customer expectations which no doubt they had created.

Tools are a-plenty, and becoming more capable but at what point do you allow a vendor to impose their vision of service management on your organisation.

It's a risk many ill-informed C-level IT managers may well ignore in the belief that the vendor knows best.

When all you have is a hammer, the nail looks like the problem.

Hi Ed

I'm sure you do feel "the issue returned to one of timely discovery" when that is what the tool you sell does. When all you have is a hammer, the nail looks like the problem.

Here at this blog, I have never taken the position that the monolithic single-vendor solutions are inherently wrong. Caveat emptor: buyers should go in realising that the vendor will want to lock them in, and that thye will probably be locked in. On the other hand, they will lock in with a big user base, which means a big revenue stream, which means better odds that the products will still be around in 3-5 years despite acquisitions and bankruptcies - which can not always be said of niche products like yours. Usually niche products are acquired and integrated, but sometimes they are acquired and just rubbed out, and occasionally they just sink without trace. The big vendors also have services (of varying quality) in most countries, and a third-party services industry following them around. Most of all, big vendors fund R&D out of revenues, not out of capital investment, so assuming the product is successful development of the next version is under way as this one comes to market.

The advantage of going with a multiple-tool vendor is that one is effectively outsourcing the integration problem to them, which allows them to charge the premium they do. If two of their tools don't play nicely it is their problem under the support contract. If your product does not work with my systems monitoring tool then which vendor do I turn to? Heaven forbid that the two vendors would get intio a finger-pointing war!

Finally, this bog shows that I don't agree at all that the issue is one of timely discovery.

First of all I don't see auto-discovery as an essential capability: see the very entry we are on now and this one. Auto-discovery is a nice-to-have accessory to the essential tools. It assists enormously in the initial population of a new repository if you don't have decent data already somewhere else. It is useful after that for checking the contents of the repository for accuracy and completeness, i.e. for quality assurance and subversion detection. But auto-discovery creates a dangerous illusion amongst the techno-centric that they have solved the configuration problem, which they haven't at all. It won't map to truly useful conceptual entities, and it won't get everything.

The important technology is the service desk. The next most important is the systems management tool. Then asset management, especially financial. Most of those tools come with discovery capabilities anyway.

Second, you are falling into the same old trap of seeing technology as the solution to the process problem that is the very point of this blog entry. If your configuration data is crap then auto-discovering some more data is not the solution.

Discovery contd.

You're not wrong Mr. Skeptic, and I won't try to argue that you're not right either - I would like to say a bit more though...

Our product was named ZENmetrics because we feel there is a need to continuously measure and to do so with the least effort and disruption to existing tools and services.

Your point about discovery (automated) not being essential might be plausible but I feel one has to eat the recipe of ITSM every day and being able to know what you have is part of that recipe - how you act on what you know is related to much of what you debate here around the nirvana of CMDB.

Our goal has been to add value to the processes of ITSM and integrate with other vendor solutions that benefit from exceptionally fast and accurate discovery/audit.

Simply - if you require an agentless audit/discovery capability whether it be stand-alone or as part of an existing service that you are trying to implement then it's our aim to be on your shortlist of tools for selection.

I did not mean to imply timely discovery is #1 of ITSM concerns nor that it should be independent of process discipline and common sense - as you observe our tool IS discrete and niche - i.e. a better engine for the task of discovery/audit. I do feel that one can drive process more effectively when the IT ecosystem is well known.

The point I tried to convey is that being able to measure is essential to better decisions, no matter what process you put in place if the knowledge that process depends upon is out-of-date, for example, what use is it? Does a CFO report his cashflows in such a manner? Why do traders want to be able to transact as quickly as possible? Where change is the one thing that is certain - timeliness may well be something you should pay attention to as part of your process mantra.

As an aside... Tripwire ( has been doing interesting work on building up CI relationships. I'm curious to see how AI evolves in the area of predictive CI mapping but it's still early days for most and many vendors are spending marketing dollars on market share acquisition with existing product lines, not R&D. No doubt, they have bigger pockets to hire more rocket scientists than we do, although I'm very proud of ours.

Thanks for listening.

Configuration data does not go out of date

Configuration data does not go out of date if processes are functioning properly: data is updated realtime by processes as it changes. In an ITIL shop where processes are working, discovery tools are required only to check for errors and cheating, never as a source of CMDB data (other than the initial source).

One other thing: no more product plugs please. I've edited other vendors' posts.

It's just a maturity subject

Ed and Skep:

I've been arround this subject a few years, first from the tooling side of life and then from the process side (just like when Brian was crucified).

From the tool point of view, the vendor will say that discovery is something very important that should be bought from the begining; and Mr. Skeptic says that when he says "a source of CMDB data (other than the initial source)"

Of course, when you see the subject from the process side you can think that information will be flood into the CMDB when the process works right, so you don't need autodiscovery.

a) The idea that an ITIL shop will have the processes working so good that a discovery tool is not needed assumes that the maturity level is high enough.

b)When you start buying your tools usually is in the first stage, so your maturity levels are low and then your ITIL shop is not working well.

c) It can (with a high probability) a problem of volume: if you want to make the inventory of an order of magnitude of 2 ceroes CI's it is possible, but if the order of magnitude is 3 ceroes it becomes not cost effective, so discovery will help (a nice to have tool).

So my proposal is the the discovery tool can help us in the initial discovery for the initial population of the CMDB, in auditing to detect errors and cheats and in populating the most technical fields in the CMDB in an automated way; but of course will not replace the process and will not avoid some human interaction with the data input

Lastly, you can live with a good process and without a tool, but having the tool without the right process is a nightmare, a money sink and a silly way to waste time, effort, morale and money.

Antonio Valle
G2, Gobierno y Gestión de TI

Defying the Vendors, heh?

The extreme focus on Technology is deeply fostered by the vendors - IBM, HP, BMC, CA, etc. - so they can sell more product. Darn few of their customers use even 50% of the capability of their products, and none of them actually offer expertise on process - just how to use their product to maximize sales.

It's interesting, don't you think, that it is those same vendors that "sponsor" ITIL?

Many vendors see ITIL as

Many vendors see ITIL as answering client demand for process: "we don't have to provide it because ITIL does". Some of them, HP for instance, are smart enough to see the revenue opportunities of process consulting (most, as you say, don't: they might offer some basic ITIL training, or nothing at all). Unfortunately many installations do not include these services. I think this is for two reasons:

1) sales hacks. So many IT sales people are ignorant hustlers who barely manage to grasp the main concepts of the technology and only know how to sell something that comes in a box. Selling services is all too complicated.

2) product-fixated clients. Let's not heap all the blame on the vendors. Too many clients want to "buy an ITIL". They don't want the effort of setting up process and they don't want to pay more than the sticker price on the technology.

Wasting Money Efficiently - The IT Way

Totally agree with comments. Why bother buying shiny new tools when you haven't worked out how they will be used, who by and have decided how to monitor you get your moneys worth. In any other branch of a business, if millions were spent to get a result and it didn't happen there would be egg on face and embarassment all round. Yet cancelling an overdue software contract leaves no trace, no hole on the ground, no half finished building to remind us of the waste involved.

I have had a few recent experiences where buying decisions have been made by technical teams for CMDB like tools where no users of the system have been involved, so they are doomed to failure. One system is so complex to use, that the idea of distributing knowledge about the infrastructure will never happen - it will be in the hands of the few. If you want to know what a server does, just call the CM team, why is that better than calling the server manager? What a waste....

I think it also goes the other way, that IT teams are not allowed to bring in an "expert", or don't want one anyway to help them decide on buying things they have little experience of. So time is wasted gathering requirements ineffectively, a wooly spec is created and no one is sure what people really want. In other business areas, using experts to reduce the time taken to decide is a good thing, especially where the experts can be sued for bad advice. How many auto-discovery tools are bought with no understanding of how they will keep knowledge up to date after the first audit?

On a specific point, any one forced to agree the buying of any IT autodiscovery tool software, network, desktop, application mapping etc. ask the following;
a. Are deletions from the CMDB carried out manually - so we need a process!
b. How is it validated as being accurate - we need a process and something to compare against!
c. How do we distinguish between test, dev, live versions of the same software or hardware - we need to have some rules and a process!

Or we buy, try it once, say it didn't meet our needs and start looking for another. What a waste...

Valuable fresh ideas on why technology doesn't come first

Thankyou Dave for those valuable fresh points on why technology doesn't come first. A couple of things you said really resonated with me:

"No hole in the ground". There is an old engineer's joke: "Doctors bury their mistakes. Engineers' mistakes stand forever to humilate them". What a great point, Dave: when IT cock up, there is no trace left but infuriated users and missing money.

"How is [auto-discovery] validated as being accurate?". We usually think of using the auto-discovery tool to validate the data, but how do we validate the tool's output?

Thanks again for a great contribution

Old words, but still valid

Do you remember that oldie whitepaper called "A fool with a tool is still a fool" ? :-)
Anyway, I keep thinking that these kind of tools can save a lot of time:

First, for create the baseline, and to "fill the repositori with initial data".
Second, as a great tool for auditing and detecting unauthorized changes to the productive environment

But of course, and here I agree with you, no people --> no process (it doesnt matter wich technology do you use).

PS: It is interesting how the ideas flow from one blog to other, since I have read almost 4 posts in the last 2 weeks related to how people is so important to run the processes, the need of consequences and the need of discipline and motivation.

Regards, Mr. Skeptic.

Antonio Valle

"The safe course leads ever downward into stagnation." -- Frank Herbert

People Process Technology

...or People Process Product Partners, or other variants. My consulting clients get sick of hearing it from me, but then I get sick of hearing violations of it from some of them.

"Yes but what is the change form going to look like"
"I want an out-of-the-box solution"
"we've just bought this service desk and now we need to figure out how to use it"
"We thought the processes would come with the tool"
"All we need from you is a document"
"All we need from you is some forms"
"All we need from you is to set up the processes in the tool"
"I can't figure out why no-one is following the process we published"
"Doesn't anyone around here read?"
"[The vendor] will provide services to install the product, load the sample data, and run one training course"
"I can't fire him, he's the best technical guy we have"
"If we had a better system than this clunky old thing, people might start to use it"
"How can we integrate the processes without integrated tools?"
"He doesn't have to go through procurement, he's a GM"
"When we decided to introduce Change I didn't realise it would have so much impact"

etc etc etc

Syndicate content