In many organisations there is often a challenge of “justifying the need for quality” – ie: justifying the cost of selling (for vendors) or cost of purchasing (for consumers) those products which incorporate aspects of desirable design, performance and usability which are a strong part of the value proposition of goods that you (the person in the middle) are trying to sell or buy.

If you are a brand-leader of course, the matter is moot – people will easily sell or buy products or brands which have strong associations with particular desirable qualities, or even a degree of cachet:

• vehicle luxury: rolls royce
• vehicle performance: bmw, porsche, ferrari, …
• vehicle safety: volvo
• mp3 player: ipod
• camera: leica, hasselblad
• watches: any of the big-name swiss ones
• television: sony
• foodie lust: keller, ramsay, anyone with multiple michelin stars, …

Note: you don’t even have to be a particular brand; sometimes even a kind of brand is enough, for instance being A Swiss Watch was enough to help launch Swatch in 1983, even though Swatch was not priced as a luxury item like other Swiss watches. Thus in certain markets where cost is not much of an issue, there are brands/brand-types which are already half-sold before the customer asks about them.

However: as a vendor playing outside your “cachet space” your product’s other qualitative differentiators have to go head-to-head with your competition without the benefit of pre-existing mindshare. You don’t necessarily have the luxury of people equating your product with the foo-quality for whichever foo-quality your customers desire.

Worse: if you don’t deliver the particular foo-quality that customers desire, then you shall surely suffer until you do.

Consider the IT industry, and consider particularly the infrastructural (sometimes called “horizontal”) qualities and technologies which customers demand of IT products.

These horizontal technologies will include, but are not limited to:

• Operating Platform Functionality
• Security Functionality, Integration and Implementation Services
• System Software Integration and Performance-Tuning Services
• Networking Integration and Performance-Tuning Services
• Application Integration and Performance-Tuning Services

Deep in their qualitative nature is the implication that a clever someone’s valuable previous experience needs/needed to be deployed for there to be a product of value worth purchasing.

Consider “Operating Platform Functionality”: the value of an operating system certainly comes in that it provides an efficient hardware abstraction for execution of applications, BUT ALSO it comes from the fact that that platform should arrive preconfigured (by clever people) with a number of clever and sensible defaults, of which once the user has the gist they may later go and tweak – however in the meantime the users are “safe”.

Got a BMW M5? The traction-control is switched on by default. Somebody clever decided to do that. You may switch it off “for more control” should you want, but that’s a voluntary act. This freedom to choose after a sensible default has been established is a matter of design and architecture and is something not inherent in the product technology itself. It is meta-technology. It’s a reflection of the cleverness that stands among the product development.

Further with regard to “a clever someone’s valuable previous experience” – if you go to one of Gordon Ramsey’s restaurants then it is deeply unlikely that the man will be cooking for you himself; you’ll instead be cooked-for by a number of chefs who may have been mentored by him, and probably verbally lashed some number of times in order to keep them sharp.

However it is a fair expectation that a meal you have at a Ramsay restaurant will be up to the phenomenal standards for which Ramsay is famous, and it’s likely that you’ll be happy to pay accordingly.

The value of cleverness and attention to detail is generally unappreciated in the IT space – if you go into a McDonalds you’ld probably think it weird if your Big Mac arrived with a chiffonade of parsley – and this unappreciation is the great tragedy of security, performance, configuration and all the other “horizontals”. People just seem to forget that qualities matter, assuming they will be the ignorably similar across competitive products.

In short: Big-Mac versus Whopper. But that’s not the case in computing and IT.

Computers are tools. They benefit from being operated by someone who’s experienced. If you’re aggregating them to expand your compute power (and who isn’t, nowadays?) then plugging them together in one fashion may be several magnitudes less effective and efficient than doing it in another fashion.

Back to the restaurant analogy: it should not be up to the customers to serve themselves. As a customer you don’t walk into Les Halles and expect to be handed a bunch of carrots and a peeler.

You could push the problem back on your Suppliers – Product Engineering – and demand that they supply pre-formed TV dinners which are ready to sell, but then everyone gets boring monotonous food and the customers have to pick-out the bits they don’t like.

You could outsource the problem to franchisees – but that just shifts the problem of customised delivery, causing you need to fund a sizable body of inspectors to ensure that quality standards are met, train the franchisees up regarding new product, etc. Life can be good if you can get this to work – but if you fail to do this then your reputation will soon be down with the roaches.

In order to cater to your customers’ tastes you need a staff of people close to your customer who know what they’re doing. I’m not talking about burger-flippers, box-pushers and people who can only read from scripts. As a vendor you really need a buffer layer of real people – clever people who have valuable previous experience – to sit between the Product Engineer and the Seller, in a position to touch the Customer.

So where’s the security in all this?

Pop back a few paragraphs; if you wish to maintain a bunch of clever people who have valuable previous experience then you will have to pay for them, and from where should that money come? Pretty obviously if their expertise can be tied to sales of a particular product then you can use that product to fund the people. It makes great sense. If you’re selling more product, you’ll need a greater number of clever people to help deliver it.

But what about “the horizontals”? With those topics – integrity, configuration, tuning, aggregation – there isn’t any specific product with which to associate sales metrics, and hence no easy formula to determine the associated “expertise headcount”.

In my 20 years of messing with security I have heard this expressed innumerable times, most often as a complaint about lack of investment:

Security is Everywhere! It’s a quality of an entire system! It’s everything from the colour-coding of your ethernet cables (red = internet = danger) to the buffer-overflow protection in your kernel, to the software API that your webserver uses to query the authentication server. In fact, you only should ever notice security when it goes wrong. And you will, when it does, unless we [do something or other] …

So some clever person decided to colour-code your cables – and make ongoing checks that the rules are adhered-to. Some clever person implemented Unix buffer-overflow protection, and another one audited your software to make sure that it’s unlikely to happen anyway. Another clever person set up a Single Sign-On solution and plumbed all your applications into it, so you can centrally control whom can do what within the network that some other clever person designed for you such that it’s proof against Denial-of-Service attacks, and yet another performance-tuned your server so that it’ll never choke.

But who’ll pay for these people to exist, and to continue to exist? Customers, certainly, but they will only occasionally touch upon these clever folk, so what will cover their salary in the meantime?

So here’s a little thesis, focused on Security but it works for prettymuch any qualitative aspect of a system:

• Security Is Everywhere
• Therefore Everything Has Security In It
• Therefore All Sales Include Security
• Therefore All Sales Should Fund Security
• therefore we should carve-off a percentage of all sales in order to fund security…
• …and measure the utilisation of the security team purely by how temporally busy they are, rather than tying their performance to some artificial sales or engineering goal.

Are you a Corporate Security Tiger-Team seeking self-justification? Are you a system administrator wanting to upgrade an ancient telnet-based terminal server? I can’t promise that the above argument will help you, but at least you now have an article written by a “noted security expert” which you can cite to your superiors.

I call this Socialized Security – people in the UK won’t get the deeper joke because we already have the NHS, which is kinda the point; it’s essentially the imposition of a flat tax for an essential service that is of equal value to all. Monies should actually be put en-bloc towards funding clever people with valuable previous experience in all the key disciplines – and if they’re not up to scratch and/or not busy enough, then you fire them.

This all probably smells deeply anti-American and anti-Corporate since it inherently separates funding from measurable performance metrics, but there’s nothing to stop you reviewing the percentage carve-off upon an annual or quarterly basis. Put a savvy “people person” – an honest Lieutenant – in charge of the group and make him/her responsible for collating and documenting experience, putting the clever people in front of customers, and (in short) keeping them busy.

I’m pretty sure that’s what Gordon Ramsey would do, if he worked in the IT industry.