Cookie cutters and IT fashion

I have had reason to look at the job boards recently. I am struck by something: nearly all the jobs in the IT industry have a sameness to them: there is some list of acronyms that you are supposed to have had x years of experience with (sometimes x is longer than the technology has been available) and apply those acronyms to the job at hand.

There is very little room, it seems to me, for someone who has a deeper experience but who does not fit into the cookie mould.

There are several unfortunate consequences of this (apart from the obvious one): any business that seeks to differentiate themselves from the competition cannot do so effectively if they slavishly follow the deeply rutted road trod by those before them; and some of the hardest problems in the Industry have nothing to do with applying the latest technology to yesterday’s problems.

One thing that I have learned in life (here he puts on his tri-cornered hat) is that there is always someone who will be faster than you, and there will also be people who are slower than you. Instead of trying to win the race, it might be better to think more carefully about what you really need.

It is also true that what you need may not be what is on offer at the local store.

But, it seems to me, the biggest problem in the IT industry is the relationship with its customers: the business community (shorthand for anyone who needs computers to do their work).

The gap between IT and business is famous; famously difficult and famously wide. Yet, you very rarely see ‘able to cross the divide between IT and business’ on a job listing; even on senior ones. That takes something other than acronym soup.

A Policy Reference Model

We had such fun doing the SOA reference model (we have just had a successful vote to go to Committee Specification status) that I thought we might be able to repeat the exercise in a different domain.

The primary benefit of the RM4SOA was that it establishes a common technology-neutral way of talking about Service Oriented Architecture. Precisely because we didn’t take a stand on the technology meant that it was less useful to potential SOA vendors (who want to know what to implement) and more useful to everyone else (who want to know what all the fuss is about).

I see a similar need and potential for Policy. Policies are becoming more and more visibly important; specifically declaratively stated policies. The reason is clear enough: who do you want to be setting the policy in your organization: you (or another relevant stakeholder) or the programmer who built the system that you are trying to use.

Explicit, declaratively written policies are a key technique for putting decision making power back in the hands of ordinary people; without requiring that they be alpha computer-geeks.

A Reference model for Policy would identify the key concepts around policies and policy frameworks (such as policy language, policy decision point, policy subject and so on). This should be expressed in a way that is neutral to specific technology proposals.

Like the RM4SOA, a carefully written RM4Policy would establish a common language for policies that could get a lot of traction in the industry.