Commonality vs Compromise

I have been working on a major project to implement a system that can be used across a large number of business processes. Many of the users recognise that the system is not optimal for their particular needs, but they are willing (or have been forced) to accept the “advantages” of using the system throughout the business lifecycle. The IT department spouts benefits such as lower TCO, more consistency when people change jobs etc. The business sucks it up and accepts the “loss of functionality”

And yet in more and more areas of life we are seeing the same approach: In the past much military technology was customised for each particular machine so there was little to no commonality between versions and certainly no commonality between services. But (possibly driven by budget constraints) the latest generation of aircraft (e.g. the F35), multi role vehicles etc are all based on a common platform.

So my question is: Is this simply another example of the latest vogue in creating platforms and providing non-best of breed solutions to the end user? Or is it that the standardisations forced by the adoption of a common platform result in more consistent, repeatable solutions that users eventually find to be better than the multiple individual solutions previously available?

And if the common approach does result in a better overall system, is the previous post on getting people to change to meet the system rather than the other way around more relevant than ever?

Have a little faith

I have worked for some large (very large) companies that have engaged with a small to medium software companies and the relationships have been far from optimal: Poor delivery of software, incomplete functionality and occasionally a complete breakdown in the professional relationship. So how (and why) does happen? And what can you do to prevent it? Here, I present some thoughts:

1. It is almost impossible to have enough documentation at the requirements and design phase
2. Make sure that both sides of the relationship are involved in and have ownership of those documents
3. For goodness sake, keep the requirements and design documents live

This is just basic stuff and should be nothing new. What comes next is a bit more controversial:

4. As a client do not suppose that you know more about your business than the software vendor. As a software vendor do not suppose you know less about the intellectual process behind your software product than the client.

The justification for this statement is two-fold:

i. At an Oracle presentation in 2001 (oh how I wish I could actually find this stat) the presenter stated that Oracle had recently completed a survey to gauge satisfaction with one of their ERP style applications: Of the companies that had modified the system to match their business process there was a 20% satisfaction. Of the companies that had modified their business process to match the system there was an 80% satisfaction.
Now, yes this was provided by a software vendor, so you can expect more than a bit of self congratulation. And on its own it might not have stood up were it not for the following:

ii. Just because you work for a large company, does not necessarily make you smarter or your processes better than the ones provided by the software vendor. Of course, your processes may be better, but chances are that the software vendor has studied many many organisations to design their system- if you have been working at the same large company for a long time, you have studied precisely one organisation.

Hidden in that paragraph is a little dig at workers at large companies and a compliment to workers at the software houses: It is really tough for a small company to dictate to a really large company (who may be offering a contract big enough to keep you in clover for a year) but as a software vendor you have to have faith in your own product. Because if you don’t then the client will try to impose their thought processes (which may be wrong) on your product.

Trust me, I know. I’ve seen it done and been unable to stop it

Remember who you are working for

Sometimes you forget just who the customer of a system is: We get so buried in the detail of what we are doing (and what we like to play with) that we forget the real world metrics that are applied.

The following is a video released by Yahoo! concerning how to optimise their web site. After the first few minutes it gets really techy (even I tuned it out about half way through) but the salutory point is made early: Traditional optimisation programs focussed on server and back-end performance (Yahoo are a web application after all); however, measurement show that the actual back end performance contributes 8-12% of the total time a user waits for a web page to display.

So performing a dynamite optimisation and halving your server time (which would take loads of effort and money) will result in a 4-6% reduction in the time it takes your web page to display. Or put another way, almost no noticeable reduction whatsoever.

 http://video.yahoo.com/video/play?vid=1040890

So, the moral of the video: Remember that the system you are building is designed to deliver functionality to the user, not just get information from the back tier of your n-tier application to the n+1 tier.

Loyalty

I sold my soul long ago to the devil that is the mighty greenback: I work as a consultant in the oil industry so it is pretty clear what my driver is. And since I got divorced that need has pretty much been prescribed by a nice judge and a court order.

But when I work at a company I consider that I am as loyal to the company as I would be as if I were an employee. Now that may not be as loyal as some employees, but that is because I have never seen myself staying at a company for years on end; I like working for myself and I like the independence it brings.

So what brings about this rant? A conversation overheard in the coffee bar: 

Older Employee: “I am worried that we have too many consultants and we will not be able to capture the knowledge”

To which I can only comment: Then pay us to stay here long enough to complete the job, design a proper knowledge capture system and enable a decent search of the knowledge to allow future users to understand what went on.

Just don’t think it is the consultants fault for not being an employee, like so many things in life, it is far more complex than that.

Battle of the Sports

Another contribution the eternal pub debate of which is better:

Football or Rugby

(I’ll work on turning the links into better table in the meantime, for now click on the links)

Me? I’ve been a rugby man since I can’t remember, even choosing which school to go to based upon the sport that they played. But then so did my brother too. Madness, who says it isn’t hereditary. At which point I offer an apology to my kids.

P Company

This goes firmly in the category of “things that make you laugh (but really shouldn’t)”

P Company is the selection process used by the Parachute Regiment (2 Para or 3 Para) to determine who is eligible to take parachute training. It is a brutal week seven weeks (thanks to Smudge for providing me the correct information) of physical and mental examinations to weed out anyone deemed unsuitable. Needless to say I have no idea of what these men go through and it is a long time since I had any pretensions of even starting such a test, never mind finish it.

There were two documentaries made in the early to mid 1980’s about this selection process, probably as a direct result of the Parachute Regiment’s involvement in the Falklands Conflict. The BBC made a 6 part documentary, Channel 4 made a 1 hour special. At the very end of the Channel 4 version a new recruit is shown taking his first training parachute jump. The process is well known: Jump, count to 3, look up and check your company. The following is what this new recruit said as he made his first jump

“One thousand. Two thousand. Three thousand. Check canopy”

Short pause as canopy inflates

“Thank f^c& for that”

And here is the video to prove it (the clip is right at the end), courtesy of You Tube.

Country Casual and Money

There is a particular style of fashion in the UK that is probably familiar to anyone who has ever seen a TV drama, set in the UK that takes place over a weekend: It consists of a green-ish sport coat, worn over a check patterned shirt, possibly with a tie, matched with either corduroy trouser or jeans and either brogues or wellington boots as footwear. When done right it is the epitome of an english gentleman (or woman) at home in their country manor.

As I was picking my son up from his swimming lesson today I saw a family (man, woman, 2 daughters) where she had got it completely correct, but he just didn’t look quite right; the jacket didn’t go with the shirt, the tie was out of place, the jeans were OK but the shoes were all wrong. Add to that the fact that he looked all sorts of uncomfortable and the impression was not good.

However, the family happened to be wearing name badges. Hers I didn’t see, his I did: “Lord Carnavon” at which point my opinion of his fashion sense changed from “doesn’t quite get it” to “with a title like that he can wear whatever he wants”

And who says that England isn’t still ruled by class.

Train Crash TV

I am still managing to stick to my New Year Resolution of only watching worthwhile TV. I fall off the bandwagon occasionally, but try to stick to the resolution, because I feel it is worth it. Anyway, the result of whatching these different TV shows, often back to back is that you see the differences between the watching experience:

Studio 60 on the Sunset Strip

Is a glorious, life affirming experience that wants to make me a better, smarter person. And was the cause of the post I want to live in TV land

What About Brian

Reminds me of a shambles of a group of friends that I know called the Strollers

Heroes

Is kind of cool and I can’t help but watch it even though it doesn’t give a warm buzz I keep watching it.

Dirt

Is an apt name for the show. Courtney Cox is completely unlikeable as the lead actress (and she blew guest star Jennifer Aniston off the screen), the show is completely unsuitable to watch with your parents (or your kids) and it focuses almost entirely on the seamy underbelly of Hollwood.And yet I have been entirely unable to switch it off. Part of this is due to an outstanding performance from Ian Hart but beyond that I have no idea why I have been able to turn it off.

Which is the reason for the title. I have never witnessed a train crash, but apparently we can’t look away. Which is what I found with Dirt. I don’t really want to watch it, but I can’t not. At least the first season is done now and I can find something else to watch. Any suggestions? Anyone?

Musical Convergence

Under the category of “whatever happened to…”

In the early 90’s music combined styles from all over: bhangra, reggae, rave etc. Proponents of this included Apache Indian, SL2 and probably loads of others that I don’t know about. I just wonder what happened to the whole movement, on account of “On a Ragga Trip” and “Boom Shack-A-Lack” were great songs (in fact Boom Shack-A-Lack makes a great wake up ring tone)

Or maybe it just grew up, after all Island Records who were one of the pioneers in moving reggae into global consciousness are now part of Def Jam who were influential in making rap into the dominant sound of today.

IT and Helicoptering

The IT world is changing: We are starting to try to create a clever, semantic web that understands things (but why does web 2.0 seem to consist of endless Facebook applications and bad MySpace pages?) we are trying to capture tricky data (that will be pretty much all metadata) by defining the Web Ontology Language (http://www.w3.org/2004/OWL/)

BTW I think I finally know what an ontology is: An ontology is a taxonomy with attributes. And a taxonomy is a controlled vocabulary organised into a hierarchical structure (http://www.metamodel.com/article.php?story=20030115211223271)

This creates a nice logical progression: controlled vocabulary -> taxonomy -> ontology. So why can’t I find a straightforward description of this anywhere on the web? I can think of two reasons:

1. I am wrong. Eminently possible. I make mistakes all the time.
2. The people involved with ontologies are so buried in the weeds that they are unable to abstract their passion and make it accessible.

There are more examples of this attempt to move IT into semantics and meaning  http://www.regdeveloper.co.uk/2007/10/03/business_data_context/ or http://www.regdeveloper.co.uk/2007/10/01/dark_ages_programming/

And this brings me on to helicoptering: I work as a Solution Architect, meaning I have to understand quite a lot about data, applications, process and infrastructure (though I tend to leave the boxes and cables to other guys) and then ensure that the system I am involved with meets the business’ needs. So when articles are presented about giving data meaning (which is what users expect) or enabling users to define the system (which they try to do and invariably fail) it has to be possible to provide a logical connection between the technical detail (which is in the articles), the system specification (the sort of thing that I will create) and the business strategic leaders (the management speak)

The abiilty for one person to dive into the technical detail, ensure it is consistent with the overall architecture and can be communicated to the strategic leaders is called helicoptering. And IT people are generally extremely bad at helicoptering.

I can’t complain too much, because part of why I get the work that I do is that I have some ability to transcend these levels. But as a larger body of people, I implore us:

Use people who can operate at multiple levels of detail. Please. Otherwise all these smart ideas will struggle to gain wider acceptance. And we do, genuinely, need them to be accepted.