How Skype treat me as a transaction not an individual

I blogged at work on how the challenge of Omnichannel engagement means you need to treat the customer as an individual not as a transaction.

Well here is an example of a company doing the exact opposite.

First some background.  At work I tend to use a VPN that takes me out through the Netherlands but regularly I'm in different countries and I tend to use Skype.  Now Skype know a lot of information about me:

1. My credit card number
2. My home address (which includes the country)
3. email address
4. All of the locations from which I've connected before

So what happens when I access, as a logged in user, from http://www.skype.co.uk (notice I'm forcing it to use the UK site at this stage, surely another hint....)

Brilliant eh?  Its all in Dutch.  So Skype take all the information that they know about me and then totally ignore it in favour of an IP lookup to get a country and therefore a language.  This page is truly special as the top of the page has not a single thing to enable me to shift the language into English.  Certainly makes it more 'fun' in adding credit to my account... did it succeed?  Is that an error message?  How on earth would I know its in Dutch.

Now on my mobile there is a screen for profile that includes language... a useful thing... but something that isn't on the profile on the website, which also declares that anything you put on the profile is going to be shared with the world (not what I want).

So Skype is falling down on several cases.  Firstly its not using the internal information that it has to offer me a personalised service, I'm in the UK, I live in the UK I don't want to change my language based on the country I currently sit in.

Secondly its profile configuration is inconsistent between its mobile platform and its web platform.  I have miles more things on the mobile platform but I'm unlikely to set them as they will be shared with the world.  But I decided to set the country and the language as much as I love the Netherlands my Dutch is non-existant.

So I set up the profile (left) and look what I got on the web (right)

So see the issue?  The country hasn't been picked up and the language isn't even an option, the website certainly didn't use the preferences from my mobile device to give me the language I wanted on the web.

Skype is multi-channel not Omnichannel.  Clearly Skype don't have a real-time customer information mastering process that keeps their channels in sync and equally clearly their website doesn't use the customer profile to customise the web experience to the individual instead it uses the IP address to customise it to the network connection.

Omnichannel is about treating the individual like an individual independent of channel.  And its that which requires good real-time operation centric MDM.

How politicians could kill SaaS with stupidity

Back when I was doing SaaS a few years ago I raised the issue of the Patriot act as being a reason why cloud providers would be setting up in Europe.  The rule however appears even worse than I knew so now the Patriot Act impact US cloud sales directly as the hosting location doesn't matter its the rules.

With the US Congress seeming to view China and the rest of the world with concern and talk of trade barriers being raised it isn't hard to see that the next four years could see a real shift in cloud and SaaS adoption, if for instance any European or Asian companies suffer publicly as a result of US policy with regards to their own information or non-US legislation (EU data privacy for instance) makes it impossible to be both Patriot Act and client complaint.

This challenge to US based vendors could lead to a flight from US shores for many of them or arms-length 'collaboration' agreements with European and Asian providers.  At worst it will lead to a collapse of these cloud providers as their markets are restricted to just the US borders while truly global players will be able to address emerging high volume markets.

If congress does start making more draconian legislation which means US companies are able to offer even less assurances to non-US organisations and non-US governments 'retaliate' by strengthening their own data privacy and retention legislation then we could very quickly find ourselves in a 'Cloud' based trade war, one governed not by tariffs but by policies because the adherence to those policies acts as a tax on the cloud provider, and if the provider is not able to obey both the US legislation and local laws then in effect that provider will have been barred from the country.

Trade wars in SaaS and Cloud will be fundamentally different, less about tariffs and taxes and more about policies and laws.  Right now Congress has firmly put itself on a trade war path.

Unfortunately I don't think they realise that.

42 - Or do you understand your Big Data question?

What is the ultimate Big Data question?  Well it is of course the Biggest Question... the question... of Life, the Universe and Everything.... but that poses a problem: in an analytical world do you really understand the question?

(or in short form if you are in a rush)

The point here is that one of the major challenges with Big Data is that we are moving away from simple SQL driven questions 'who are my top ten customers' or 'how much did I sell last week' into much more analytical and predictive questions such as 'if I reduce the price of goats cheese how much more red wine will I sell'

This presents a new set of challenges because analytics can give you simple answers '15% more' which then lead you to drop the price of goats cheese.  The network effect of that change however means less beer is sold and less hard cheese is sold so now you are over stocked in beer and hard cheese, both of which have a use-by date.  The point is that the question was badly formed but correctly answered.  Greater degrees of abstraction also introduce greater degrees of assumption in those creating the models.  So while the business has asked a small and concise question 'where to put the next store' the model has made certain assumptions that may or may not be the case. How are these assumptions shown to the business and if they are can the business even understand them?

Today there exists a problem of chained spreadsheets, in the future the issue of chained analytical models is going to make the connection between the business 'question' and the 'answer' more complex and harder to understand and put more power into the hands of mathematicians who prove good at converting abstract questions into good models.  This also means that there will be ever more importance placed on getting control of the definition of information into that model (what is a customer, what is a product, how do you identify them... MDM stuff) these are the bits that the business can control.  The core information, the sources and the quality control around them.

Big Data answers - only as good as your understanding of the question.

How Apple will beat Facebook

Looking at the extension of iMessage to the desktop made me think about how Apple can take on Facebook and win.  Lets see what Facebook have over Apple technically...

1. Multiple people in one conversation
2. Broadcast conversations with 'followers'

Now Apple have already integrated Twitter into the iPhone but lets assume that long term the folks from Cupertino want total control.  What do they need to do?

1. Add a 'message thread' function to iMessage so its not just a stream between two people
2. Add the ability to talk in groups
3. Add the ability to broadcast status updates

Applications can compete easily by having some form of multiplayer iCloud sync, or in the same way they already do via 3rd party servers.  What more could Apple do however than Facebook?

1. Integrate the status update piece into Contacts so before you call you see the status and can see the recent messages
2. Integrate the group chat dimension by having 'groups' in Contacts (umm almost Circle like)
3. Provide multi-participant Facetime to switch from iMessage to group comms

The point here is that technically Facebook don't have much that Apple couldn't make standard Mac OS X and more importantly iOS functionality.  Indeed much of this would be a welcomed integrated upgrade to those things (rather than a clear market grab like Google+) so people would 'naturally' start using these facilities as they are on their phone/desktop.  This would increase the link to Apple products in those communities (much as Blackberry used to see).

An added advantage of Apple's approach is that it can remove the view of a 'big central server' and instead create a more federated view of inclusion than Facebook.  This is liable to help increase people's engagement levels and unlike Facebook Apple doesn't need to drive revenue via advertising or selling people, it wants to drive that via more people on its platform as those people hand over real hard cash.

Facebook's big risk is that its network ceases to be the cool and only place to network and that other social based approaches take off.  Apple are ideally placed in the consumer space and have the platform control mentality to drive this.  iMessage is only the start of the evolution, the question is just how much engagement does Apple want to have?

Why Broadband, Apps and Moore's law will beat Server based HTML 5

The browser is about to have its day... Apps are going to win.  Now these Apps could be like the Chrome store pieces and developed in HTML5 but with local storage and offline access added but they will fundamentally be local things.  Why?

1. Moore's Law isn't going away any time soon. 
1.  In a couple of years we will have Smartphones with quad or even octo cores, 8GB of main RAM and 256 GB of storage... and you are seriously just using that as a browser?
2. Your TV will have that as well
3. Your Fridge will be a bit dumber, say dual core, 8GB storage, 100MB RAM... its a ruddy Fridge
2. Connections to the home will be a normal thing
1. Mobile phone companies will start offering 'VPN to the home' as a standard offering so you can unify your control of internet access
2. This doesn't require a 'home server' just a VPN link
3. Your home devices will then be accessible directly or via the cloud
4. Current 'TV via 3G' offers will be linked back to your home connection
3. Rich Clients beat thin clients when there is a choice
1. Look at the App Stores, look at games...
4. The network is never something to bet on being 'always' there
1. Do you want a Sat Nav that fails due to network connections?
2. Do you want a Fridge that turns off because it can't download the right temperature for fish?
5. The speed of light isn't just a good idea... its the law.
1. Ping lag is an issue of immediacy.  Even if processing takes zero time there is still 100ms+ of ping-lag to contend with and server lag, etc, etc. 

This isn't a retro-grade step its actually a great challenge as what it means is that federation is going to increase.  Social centralisers like Twitter and Facebook are liable to start facing competition from Social aggregators which work on federated information served from your devices via your home network.  Cloud providers will remain focused on functionality and capacity and the blurring of the cloud between the physical and the virtual will be complete, you won't even know if your TV is running locally or via the cloud... except when it borks... which is why in reality it will run locally.

HTML5 a great technology but for it to win it needs everyone to sign up for 'open' on all devices, this includes TVs, Mobiles, tablets and motor cars.  Applications are so much the 'thing' that Google are even promoting applications that can be downloaded and run from Chrome, thus meaning that Chrome isn't really a browser anymore but instead is a hosting platform for applications.

Server-side HTML has had its day, the only question now is whether the industry will unite behind a single 'open' client-side approach for applications or whether every platform will have its own approach.  Apple's current success and the Android marketplace seem to indicate the later.

Server-side HTML - 1991 to 2015.

Why I rewrite rather than re-factor

Refactoring is one of those terms in IT that gets bandied about as a good thing.  Refactoring is meant to be the small incremental cleaning up of code to restructure it while leaving it functionally the same(1).  Some folks say that re-writing is different as it changes this functional contract.  What happens in the field however is different...

Refactoring tends to be done in small chunks and done incrementally around a specific area, for instance a single function or class.  The refactoring tries to 'evolve' the code to make it better and does have some good theory behind it, but regrettably in the field I tend to see refactoring creating an incrementally more complex mess as parts are 'optimised' while the whole collapses.  Refactoring in the field is also mostly done when you've got new functionality, so the idea of functional equivalence goes out the window its now just about refactoring as you develop a new requirement which means that the new requirement skews the refactoring.

This reality of refactoring in the field means that I often come across code that has gone through several refactors and each was tinged by the mentality of the developer undertaking a specific new piece of functionality, the refactors therefore are not making the code better but instead making it better to develop that one specific requirement.

For this reason I'm actually a big fan of re-writing and, whisper it quietly, I tend to find its quicker and produces better code, especially from a maintenance perspective.  Now I could argue what I do is refactoring as I'm always rather anal around getting interface designs right and they tend to be rather stable as I put quite a bit of time into them.  The reality though is that the body is completely changed behind the facade.

Re-writing works because I now know what I didn't when I first planned the internals.  I know the additional requirements that I've received and the new information classes that I now must operate on.  Recently I had a piece of code where I had spent a couple of 'refactors' making it 'better' and the code was a bit cleaner and more manageable.   I then came across a bug which was proving rather hard to track (Objective C how I loathe you) and some new functionality I wanted to develop was adding complexity into the code... so it was re-write time.

About 60  minutes later there were 120 lines of code (SLOC) where previously there had been 300+, this clean down had removed the bug (which was to do, as ever, with memory allocation) and added in the new functionality.  The new code had been quick to write as I now understood much better what the end-goal was thanks to new requirements through a few iterations and I'd a much better grasp on how all of the different classes needed to engage.

Functionally my class interface hadn't changed and the calling classes didn't need to change but its hard to claim what I did was a simple refactor as I trashed every single line of code and re-wrote from scratch based on the requirements & design.

Refactoring has become a short cut for 'don't do it well first time' and the reality of the field does not match the theory in the books.  Too often the phrase is used to hide bad code, badly re-structured (and I'll admit that my first pass was in retrospect just that as I didn't know quite how Objective C and iOS worked).

Its time to come clean:

Sometimes its better and quicker to re-write than keep up the facade of 'refactoring'.

Technorati Tags: SOA, Service Architecture