Fibonacci - word of the week

I haven't rolled this into the project yet but its something that I've done before to raise the sense of community. Basically you pick an unusual word, but not too unusual, that people need to get into either a conference call, document or email. The word must fit within the context of the communication, not just a random shout out, and the non-included people on the call must not notice.

Today I decided on the word Fibonacci to test out the theory again, this was placed into a call with the phrase "we are starting from 1 and with any Fibonacci or exponential growth that means its about getting the next one".

Its the sort of little thing that helps bring people together and works very well in small teams within large scale programmes. Don't make it ridiculous or offensive just make it so its a word that could be used but requires some elegance to get it into context.

Technorati Tags: SOA, Service Architecture

Will the Credit Crunch kill the hype?

At the Netherlands Java Night 08 I moderated a discussion on Java futures and chatted with a bunch of people doing real, and large, Java projects. The overwhelming plea was "please stop the hype and the crap, lets make it work properly first". Now with the credit crunch this got me thinking about what a credit crunch could mean to IT spending.

Now apart from the obvious of more outsourcing there is the impact on technology selection, namely not as much new product being bought and a focus on the TCO more than just the development time. Now this could be a very good thing for SOA programmes out there as it helps them focus on what really matters and away from technology bells and whistles and helps them to upgrade slower and thus have more consistency and thus reduce their governance and overheads.

The other bit could be its impact on things like scripting and the various other language developments going on at the moment. These are great if there is loads of cash to spend on investigating new things but not so good if you are interested in keeping your TCO down (which is aided by consistency more than by technology) and don't want to spend loads of cash training people in something new.

Clearly the credit crunch isn't a good thing, but there could be some advantages in terms of its impact on IT spending and in particular its impact on practicallity over hype. Less of the big software purchase and random building where there is no value and more of a focus on repeatable and measurable reduction in TCO.

I can hope anyway.

Technorati Tags: SOA, Service Architecture

IT Hype and the valley reality distortion field

One of the problems that I have in my job is the problem of IT Hype, most especially the huge distortion field that appears to fall over Silicon Valley. When I'm working with companies who are going through a procurement phase its amazing to see this field spread across the globe via the blogosphere. Its the sort of field that tends to ignore companies like IBM or SAP because they just can't be encompassed within this idea that everything must come from the valley. So how do you get around that problem and make sure you make a smart decision?

Now its certainly true that the valley does have a disproportionate impact on IT, its a pretty small strip of land to have given birth to the likes of HP, Sun, Oracle, BEA, eBay and Google. That is damned impressive. The problem is that when you are looking for really good small companies to work with I'd argue that the bullshit to content ratio is never higher than in the valley.

Recently I've been looking at companies in a few spaces recently, which unfortunately I can't go into, and I've started to come up with a valley weighting system of how to score a company before you even go and see them, this is for the small guys not the established guys

1. Current Revenue
2. Current Customers

These two numbers give you the base line for the company, divide revenue by customers and this gives you an average spend, what you are looking for here is companies that appear reliant on a single customer. i.e. if they are talking to you about $40,000 spend and the average is $100,000 then either everyone loves it, or they've got a big marque client who they care the most about. Very common in finance this problem.

1. Projected Revenue
2. Projected Customers

This gives you where they are expecting to get. Again divide the two to see what the future spend per customer is, also look at current/projected for revenue to see the growth path.

Now we factor in the valley factor

1. In the valley - Bullshit factor = 5 year growth projection * 0.5 (i.e. if its 10x growth in 5 years, bullshit = 10)
2. West Cost - BF = 5 years *0.3
3. Mainland US - BF = 5 years * 0.25
4. Europe - BF = 5 years * 0.2
5. India - BF = 5 years * 0.15

This gives you a basic financial BF which should then be weighed against the hype. Basically for each post on Digg or Slashdot add another 0.1 to the BF. Then look at the length of time the company has been around and not cash positive, add 0.2 BF for each year, finally look at the length of time the company has been around and not grown at similar rates (i.e. they are predicting a hockey stick graph after ten years of solid 5% growth), add 0.3 for each year of growth that just doesn't fit the projection.

The final BF then gives you the amount of convincing you should take in order to believe anything they say. If they have a BF of 1 then they need 1 reference for every point they make. If they have a BF of 5 they need 5 references.

Part of the reason for doing this is that these new companies often look shiny and its important not to get caught up in the hype. As an example of hype v reality its quite funny now to look at transmeta and ARM now. Back then in 2000/2001/2002 they were the darlings of the Slashdot crowd and when I went to the valley the talk was about how they were going to completely dominate then chip market. Meanwhile a tiny company in the UK which had been doing chips for years and growing strongly continually had made a move into licensing IP and moving into the mobile phone market. Now in 2008 their results look a bit different, revenue for transmeta in the 2nd quarter failed to break $400k revenue while expenses nearly hit $2m, ARM meanwhile struggled by with $128.1m revenue and a healthy pot of cash.

What has this to do with SOA? Well really its to do with T-SOA, WOA and all the other things out there. When you are looking at companies as part of a long term strategy you need to know that they are going to be around in 10 years time and still helping you evolve, otherwise you are doing something as a point solution and will accept that support and maintenance is your own problem. You also need to figure out whether that wonder technology really is amazing or is just some empty hype, the more amazing the claim, and the growth predictions, then the more evidence you should be asking for.

The other point is that what you are saying is that if you think their business model doesn't stack up but the technology does that you will need access to the technology when they go bust. This is why lawyers invented escrow if you want the tech but don't trust the model then make sure you get the rights to access the code (or other tech) for your own purposes if (when?) they go bust.

This is part of that shift about moving IT away from technology and into a business frame of mind, it means not following the hype but following the numbers.

Technorati Tags: SOA, Service Architecture

Be clear - document

A number of years ago I had a period of time working at a smaller company where I found myself up against the massed ranks of the "big american consultancy" (BAC) on a number of projects. Now clearly they didn't like me as I was doing some high value delivery work and might have occasionally pointed out some minor flaws in the way that they were working. Now what this did teach me however was the following

1. Don't delete any emails
2. Always send a summary email after a meeting even if it isn't full minutes
3. Document decisions - if someone decides something then send them an email confirming the decision
4. Point out the obvious - if someone changes their mind. Point it out to them. If they are a senior stakeholder then do this one on one. Even if they do change their mind then at least they'll feel that they owe you one. If they are competing against your project then make it visible to everyone.
5. Don't rely on a conference call to get you the status. Build up a social network and trust to the water cooler conversations
6. Go to the raw data. If its about development then do code reviews, if its about data warehousing then go to the data quality and volumes, if its about user interfaces then go to the usability studies.

Now what I'm not advocating is lots of massively verbose documents, in those lie doom as the detail is where the weasel professors can live. The important piece here is making documentation clear and small. One notable experience I had with a BAC was where they refused to do Unicode as it was "too hard" for their mainframes (this is despite pointing out that UTF-8 is basically an extended ASCII set) so we went to the standard ASCII set. Testing began and the data had what looked like typos all over the place. Clearly this was an integration (my) problem. But thanks to the very brief documentation we quickly proved that they were sending an 8 bit character set through when ASCII is 7 bit. Oddly the decision was then to move to UTF-8.

The point on documentation is short, sharp, concise and irrefutable. Its there to make decisions visible and obvious and make non-adherence to those decisions an act of wilful stupidity or disobedience.

As a client said to a BAC on one of my more entertaining projects.

"Are you a complete idiot or an asshole?" (it was an American project)

Documentation isn't there to hide behind (CYA) its there to document facts and Just the Facts.

Technorati Tags: SOA, Service Architecture

Its about WHAT not HOW

A shout out to Todd Biske with a brief post on his concerns on the current REST/WS/Monkey debate. I completely agree.

Lets focus on the WHAT not on the HOW. We've tried focusing on HOW for decades and its one of the things that has got IT into the mess it is.

Technorati Tags: SOA, Service Architecture

You don't need an SUV - keeping the scope down

Okay so Gerald has been going a month now and we are into that dangerous stage where people begin to realise what the project is doing. Suddenly they want more, lots more. Rolling out to 30,000 people isn't enough, why not roll it out to 500,000? Why not have amazingly complex security requirements and some AI?

Pretty much all of these have now been suggested on the project and the mantra I respond with is

do one thing well

What I mean by this is that we don't want to boil the ocean at this stage, we want to prove that the solution works for a, pretty large, user group and then build on that success. If we start lobbing in more requirements and expanding the scope then the project will be delayed or fail and we won't achieve any of the aims. Once we have that first piece done then its open season on what is next, but right now lets keep it concise.

The most important phrase at this stage is "Phase 2" as in "we'll add that to the requirements for Phase 2". The reason is that 90% of Phase 2s never happen and the 10% that do look completely different to what was being asked at the start of Phase 1. Smile the California shop assistant smile, give them the feeling that you care, and then file the thought away in the bin of "future requirements". People will bleat and moan that its "required" but the reality is that its better to have something doing 80% than nothing doing 100% and many of the requirements you hear at this stage are "SUV" arguments.

An example of fake creep in the real world is the SUV. 99.999% of SUV owners have absolutely no reason for owning one, but they come up with "requirements" that end up with them buying the SUV.

• It snows around here sometimes
• I drive up hills
• The roads are a bit rough
• I might go off-road
• I want to feel safe

Now all of these are rubbish reasons to own an SUV. Unless you are a farmer or equivalent, and its amazing how many of those don't buy a Porsche Cayenne then these are all fake requirements. In the French Alps you will see people with a Renault Twingo doing fine in the snow and as for the rough bit and the hills... well I'm here in Bangalore today and the roads could be described as "patchy" at best and everyone has a sub-compact.

The point is that your project should be a sub-compact. It works, it gets from A-B and you can get 5 people in at a squeeze. Building an SUV for your project means adding in gadgets, weight and features that take you time and money and at the end of it you are just shifting those 5 people in slight more comfort.

The smart move is to build the basics and then look at what actually creates value. Say "no" to all of the scope creep and keep it simple. My goal is to have all of my user groups equally annoyed that they are only getting 80% of what they asked for, but for that 80% to be 100% useful.

Technorati Tags: SOA, Service Architecture