CYA - or the art of doing bugger all through paperwork

Cover your arse (or ass for those in North America, although why you cover donkeys I don't know) or CYA is one of the most crippling inhibitors to change in any organisation. Often dressed up in the weasel words of "considering all the possibilities" it is all about making any job seem so much bigger than it actually is.

IT, in particular Enterprise Architecture and IT operations, can be the major creators of CYA within a project or organisation. Asking people to consider every potential outcome, and embarking on long studies to consider the full long term impacts on the Albanian watch industry of that SAP upgrade or application to support the marketing campaign.

These people delight in the "what if" scenario and fight back against suggestions like "There aren't even 10 billion people on the planet" by accusing the rationalists of being unprofessional and just trying to get things out the door without the proper controls.

You can tell organisations that suffer from this problem because they tend to be burdened down with paper, paper that is very rarely read even once after being written. Projects have to complete lots of different assessments and studies to get anything working, all due to the fear that if something does go wrong that it will bounce back. Because after all if you do all the paperwork and still produce a crappy system at least you can prove you did the bad work according to the process.

During projects this comes down to project managers asking for daily status reports, Enterprise Architects asking for "justification documents" on technical decisions that make you think about "how will this work in 5 years time" while operations ask for a full set of documentation, training courses, security audits, penetration tests and the like before you can even speak to them.

Now some people will howl "but you do need to think about these things" and to that I say "sometimes you do, sometimes you don't" and there in is the problem. IT organisations rarely think about what is appropriate for the job being done. In the same way as IT sets up projects to be rubbish in support so the CYA culture makes sure that everything moves at the same snails pace.

What is the solution? Well in part its about more formalism around specifications so you can get rid of all of these reports because you can say "look the SLA on the service says 99.99 availability and here is the test suite for it" and "look the Security Policy says that all Albanian Watch sellers are banned from using this". This increase in formalism means a decrease in the amount of documentation required because these elements can be used to enforce the boundaries of the service and highlight when those boundaries are in danger of being breached.

The other part is for IT people to be more professional, so not producing crap software and projects, not having documentation so poor that support can't use it and not continually releasing things that don't scale to the market. The CYA crowd also needs to become more proactive in determining what success is for a given element and then applying the right set of principles and audit to that solution rather than a blanket one size fits all.

Formalism and Professionalism, is it too much to ask?

Technorati Tags: SOA, Service Architecture

Why contracts give flexibility....

As per the last post there has been the standard "flashback" from a bunch of people who crusade first and think later.

So lets explain in simple terms how strict contracts give flexibility, and to make it really easy I'm going to use four examples, firstly REST (which the "don't validate" crowd follow) and secondly LEGO(r) which the "I don't understand SOA but I'm going to use this as an analogy" crowd try to go for. The final examples are... well I won't spoil the surprise... So I should cover lots of bases here

So first off lets look at HTTP, it has a very strict contract with a limited number of possible actions, GET/POST/PUT/etc and an extremely limited way of getting to those actions. Now interestingly the entire concept of REST is that this limited and tightly specified set of actions when rigorously enforced provides an infinitely flexible architecture on which to built things. So HTTP is in fact an area which has a pretty tight set of up front validation (try sending random packets to Apache or Firefox to see where it gets you) and an extremely limited and well specified set of actions with which to interact with the server.

So simply put the REST people who are claiming that you shouldn't validate are exactly the same people who are claiming that you should rigidly adhere to a tight specification and reject anything that (for instance) stops GET being idempotent. So here is a great example of a tight specification being used as the implementation approach for complete flexibility.

Next up lets take Lego, you have a "brick" it has a bottom which has set dimensions and a top which has set dimensions, amazingly despite limiting the specification of the brick to having exactly the same form and function top and bottom the potential for Lego is practically infinite, you can do Star Wars, Air Force One and really odd stuff. This is all managed via a very strict contract as to how the different bricks connect.

My third example is the wonderful world of IKEA. IKEA uses pretty much the same screws in every thing they do, they use the same sort of connectors in everything they do, and lots of times they use the same size of wood, just combined in different ways. Having tight specifications like this that mean they only need certain sizes of doweling or screw gives them an immense (and profitable) flexibility in what they can create.

Tight specification can often be used as the basis of flexibility rather than rigidity, but having these tight specification means that you, as an engineer, need to understand the boundaries within which you operate.

The final example comes from the wonderful world of Pimp my Ride and more particularly the world of tyres and "rims". Having a set size for wheels and a tight specification doesn't decrease the flexibility it positively increases it. There are a massive amount of tyre and rim combinations available so one car could have three tyres from one manufacture alone and a set of 4 rims from the first hit on Google. For the mathematically minded that is 12 different combinations on a single crappy Ford Focus.

This is why specifications are engineering, if you could say "I wish that I could just do this because its cool" then you'd be a liberal arts major. Having specifications can increase flexibility when you know how to use them and use them in a smart way. This is the reason that screws, nails, hinges, doors, trains and lots of other things obey a specification. Specifications are the best way to get things to inter-operate. The REST crowd should know this better than most with their mantra of "standard HTTP", but unfortunately too often people are beguiled by an idea which makes them contradict the benefits of what they are saying is right.

Specifications give flexibility because they tell people what can and cannot be done, people are then very adept at modifying their behaviour and their world to cope with these limitations.

It would be completely wrong to say that this was Darwin in action, but its completely right to say its how adaptation works.

Technorati Tags: SOA, REST, Service Architecture