RESTs marketing problem and how Facebook solved it

Earlier in the year I commented on REST being still born in the enterprise and now Facebook have now deprecated the REST API in favour of a Graph API now I could choose to say this is 'proof' that REST doesn't work for the Web either. That would be silly for a couple of reasons

1. The new API appears to be RESTful anyway
2. REST clearly can work on the web

No, what this really shows is that you have an issue with naming conventions.   The folks at Facebook called the first API the 'REST API' which meant when they felt that there were problems with it they then had two options

1. Have a new API called REST API 2.0
2. Create a new name

Now the use of the term 'Graph' I think is actually a good move and one that is much more effective than the term 'REST' in describing what 'REST' is actually good at: the traversal of complex, inter-related, networks of information.  Now this is actually a concept that resonates and has much less of the religious fundamentalism that often comes with REST.

Pulling this into the Business Information space of enterprises could be an interesting way of starting to shift reporting and information management solutions away from structured SQL type approaches into more adhoc and user centric approaches.  'Graph based reporting' is something I could see catching on much better than 'REST'.  So have Facebook actually hit on a term that will help drive RESTs adoption?  Probably not in the system to system integration space, but possibly in the end-user information aggregation/reporting space.

Time will of course tell, but dropping the term 'REST' from the name is a good start.

Technorati Tags: SOA, Service Architecture

Wasting the time of a PPI scammer

There are a number of scams going around today which really demonstrate how mainstream outsourcing has become.  There is the current one around the 'unique' number that proves the scammer is from Microsoft and today I got a new one.  This time it was someone claiming to be from 'iClaims' (another Steve Jobs legacy, 'i' is the new 'e') telling me that I was entitled to a PPI or bank charges refund.  They had my address and phone number but nothing else so after saying that Lloyds TSB was my bank (it isn't) I flicked on the recording on my iPhone and away we went.  The game here is to waste as much of their time as possible while giving them as much incorrect information as possible. The total waste of time was about 20 minutes, but I only managed to record 18 minutes....

What surprised me about this scam was that they get all your Visa/Mastercard details but then want to set up a second call at which they will do advanced fee fraud part of the scam.  Almost 'honest' of them to do it at a second call rather than just ripping your bank account then and there (although as its all fake number I have no evidence that they wouldn't do that as well).  What I find most depressing about this however is that, as with the Microsoft virus scams, the drones in the call centre are just like drones in a call centre providing service support, they genuinely think they are doing a good and valuable job, they are just keeping to the script they've been trained to do.  They don't realise that actually they are part of a criminal act, I've even had one guy beg me not to report me to his supervisor as he'd get fired if they realised I'd played him.

Behind these folks lies true scum, total and utter scum.  People who appear to have access to credit card validation software and have a list of 'valid' numbers for UK accounts.  Its a depressing evolution of the outsourcing model that these days people are outsourcing and industrialising crime via India, and its not as if India doesn't have enough corruption of its own.

Now clearly people reading this blog are smart folks and wouldn't fall for this, and I dare say like me also entertain themselves in moments of boredom by playing along with these scams, but its worth mentioning (probably again) to relatives that this stuff is bollocks and they should hang up.

Cloud in a box: Life on Mars in Hardware or an empty glass of water?

There are some phrases that are just plain funny and for me 'Cloud in a Box' which is available from multiple vendors is probably just about the best. The idea here is that you can buy a box - a box that looks and acts like a 1970s Mainframe: virtualisation, big power consumption, vendor lock in - and joy of joys you've now got a 'cloud'.
 So:

• Do you pay for this cloud on demand? 
• Nope
• Do you pay for this cloud based on usage?
• Nope
• Are you able to just turn off this cloud and then turn it on later and not pay anything for when its off
• Nope you still need to pay maintenance
• Can I license software for it based on usage
• Errr probably not, you'll have to negotiate that
• Is this cloud multi-tenant?
• Errr it can be... if you buy another cloud in a box
• Is this cloud actually pretty much a mainframe virtualisation offer from 1980?
• Err yes

At first I was thinking that this was in fact the sort of thing created by folks who watch Life on Mars and want to see their data centre populated with flashing lights. But then I realised actually there is a better reason that you don't get cloud in a box.

Clouds are vapour, they float, they dynamically resize... if you put a cloud in a box then the vapour will stick to the sides and turn into water... taking up about 1% of the volume of the cloud.  For me this sums up the reason why it doesn't come in a box.  Clouds need to have capacity well beyond your own normal needs so that if you 'spike' then you can spike in that cloud but not need the capacity the rest of the year.  So a 1% ratio is probably the minimum you should be looking at in terms of what you cloud provider has against what your normal capacity is.  This is the reason that provider clouds like Amazon, or those from other large scale data centre providers, aren't 'in a box' but instead are mutualised capacity environments.   Even if one of these providers gives you a 'private' area of VLANs and tin they've still got the physical capacity to extend it without much of a problem.  That is what a cloud is, dynamic capacity paid for when you use it.

Cloud in a box?  I'm a glass 1% full sort of guy.

Technorati Tags: SOA, Service Architecture

Why thinking counts and development doesn't

I'm having one of those interviewing streaks at the moment.  The sort of interviews where after 2 minutes the only question is how to politely wrap the interview up but where secretly you want to scream 'DO YOU SERIOUSLY THINK YOU ARE ANY GOOD?'.  You know the sort, where you ask a simple question like

'Explain the difference between EJB and SCA' and you get an explanation of the different Eclipse UI pieces the person has used on their current project.  You then push for a more structural detail and onwards and downwards the explanation goes.

The point here is that these people are 'developers' but I'm after 'solution architects' or 'software engineers'.  What I want is people who understand the principles and structures behind what they do and not simply the series of UI elements or API calls that fulfil their current task.  I don't ask people about 'design' as I don't really care what they use for design whether its Agile, XP, SCRUM, Waterfall or just doing it in their heads.  What I care about is how they think about solving a problem and then apply that thought to the platform they are working on.  This applies to folks who are package functional pieces, Java developers or Perl guys.  I want to know that you actually understand what is behind the scenes otherwise I'm better off just doing it myself and that is normally a waste of my time.

Software Engineer is a phrase that isn't used much these days, and I feel that is a shame.  Software Engineers know about how things work and what makes them, they care about the structure and the mental model and then its application and not about the basics of what is infront of them.

Talking just about the surface is ruddy pointless.  Its the sort of thing that causes issues, for instance asking a Siebel person 'how do you handle organisational email addresses' and them not knowing about the issues that has because 'I've never had to do that'.  That means you are sheeple, you follow what is there and don't try and think about what is behind and the mental models, this means you will make bad decisions.

Thinking counts, design counts because its that sort of thing that means you see the roadblock and avoid it rather than just ploughing straight into the wall.
 

Technorati Tags: SOA, Service Architecture

Five reasons why Facebook is dying and Email is king

Mark Zuckerberg tried to pull a Steve Jobs the other day by announcing that a new product of his was going to kill off a competitor. Now there have been articles on the fact that email use is still rising and I'll give five reasons why Facebook is dying and five reasons why email will remain king

Why Facebook is dying

1. Facebook is at near saturation point, this makes it valuable through the Metcalf law on the value of networks but is a concern in an area where displacement can be exceptionally rapid (anyone remember MySpace?). In China and other places Facebook has practically nothing
2. Facebook is a one trick pony and its trick isn't as good as Google's. Google's trick is to provide to OTHERS, Facebook's is to control within the garden. The moment the garden is under threat then the value disappears
3. Facebook is struggling to innovate, the aborted 'places' approach is an example and the new messaging piece (hardly ground breaking) is part of that. Great first act, but where is the follow up?
4. Facebook's value is on selling its user data, as data privacy rules tighten this avenue will become harder
5. Facebook haven't shown how they transition from glorious start-up to proper heavy-weight. Yahoo had more and still failed, why are FB's leadership different?

Why email will win

1. Email is open - standard protocols, standard formats and available to anyone. This means its ability to connect is significantly higher
2. Email is ubiquitous - we don't need the same client, server or anything. Whether its mobile, desktop, web or anything else people can communicate and it has massively more engaged users than Facebook.
3. Email can be private - Encryption, local storage and other elements mean email can genuinely be private
4. Email isn't owned - there isn't one big company trying to fleece or sell its value is in connectivity
5. Email is federated to the individual - I choose what I want to see and what is important.

Zuckerberg wants to kill email BECAUSE its open and because it allows people to be social. And ultimately this is what I think dooms Facebook. In a federated world the winner in social communication is going to be a federated approach, right now that means email but it doesn't mean that in 5 years we won't have some clever software that enables people to 'carry' their status on their mobile device and have it federated in the manner they wish independent of the provider.

Email isn't dying. Facebook is dying and Zuckergerg is not the next Steve Jobs.

Technorati Tags: SOA, Service Architecture