NFC - What Apple does next? Buy Amex?

Chatting around on the iPhone 5 I have to say its all rather dull, yes they'll fix the antenna, yes the camera might get better and the processor faster. But really is that a big deal? So what could Apple announce either now or next year that would really blow people away.

I travel a lot, and one thing I see around Europe is the rise of NFC, so the use of 'smart'cards on the Underground, Metro, Dutch rail and elsewhere. The technology is basically the same everytime, Chip with some form of RFID or NFC is swiped over a sensor and your trip is paid for. Around the globe we are seeing MasterCard and Visa both include NFC to their cards so you can just wave the card around and get charged for things.

Now MasterCard and Visa get a percentage of the transaction, there are normally companies providing the Smartcard services for public transport. But what stops Apple creating or leveraging a 'standard' for NFC to cover these cases. Think 'Airplay' over six inches. Now Apple have said NFC won't be in iPhone 5, which indicates... well not much. But the key question here isn't so much when NFC will be included but the impact this will have on the market.

Lets say in the UK my Oyster card can be replaced with my iPhone and my iPhone can be linked to my Credit Card. Suddenly Apple are taking a slice not just of my iTunes transactions but of pretty much everything I do, and they have clarity via GPS on where I'm doing it. I can also charge via this system on the French, Dutch, etc networks without having to buy a ticket or going to a ticket office, think of the staff savings....

Now for fraud reasons it would be good to track the GPS so if I do an iPhone transaction in Utrecht and then there is a card transaction in London 10 minutes later then the odds are that one is fraudulent. This fraud protection would give Apple the reason to store and analyse this information, and of course provide it to the credit-card provider. All very open, if more than a little big brother.

The point here is that integrating NFC into the iPhone and driving a standard due to the massive market volumes that the iPhone has, something no-one else can currently do unless Google dictates hardware standards a bit more, would mean that governments and companies could massively reduce the timescales for adopting NFC and start decreasing their operating costs by relying on iPhone users to self-serve. This would have a knock-on effect of driving iPhone sales because with iPhone being the 'preferred' mechanism it becomes simpler to own one rather than not. Thus Apple provide to the credit card companies and other organisations a platform for NFC which gives Apple revenue and companies the leverage that a standardised market brings (think 802.11x against proprietary approaches).

That then got me thinking. Apple quite like being in control and have $76bn in cash, what could you buy for that which would really kick this up a level? How about VISA($63bn), Mastercard($44bn) or American Express($60bn) themselves? Apple could buy, for cash, anyone of these. So instead of having an open system for all of the providers it suddenly would become a closed system where you are best off having a specific card provider if you get an iPhone. Given the demographic target of Apple, and their larger charges over the competition, AMEX would seem to be a good fit.

Sometimes its scary when you join the dots.

Technorati Tags: SOA, Service Architecture

Java 7 SE approved... Meh

Hey Java SE 7 has been approved... now that is spectacularly quickly. You'd almost think that the normal Java Community Process had been ignored and instead the spec lead had taken an externally created spec straight to approval...

What is most depressing in reading the various Oracle (mainly ex-Sun employee) releases on this is that not a single one actually commented on the fact that of the people doing the approvals six of them expressed reservations about the licensing terms and the transparency of the process. All stated that they were approving it to get Java moving again and that there are issues they want to see addressed. I've said before that Java SE 7 is a nothing release for Java but its the approach and process that concerns me most. While I don't think the Java SE 6 approach taken by the Sun leads at the time was at all positive or constructive and the end result was not what was required at least there was a decent representation and debate. 18 companies spent 18 months and while the dumbest decisions remained (JAX-WS in JavaSE 6... how stupid does that look now?) at least there was a measure of debate.

The expert group for Java SE 7 was a sham, Five companies, five months and the first draft published days after the expert group was finally formed. The comments on the 'six companies who approved (+ Google who voted against) clearly indicate that there are significant changes required for Java to regain its position as the go-to platform for developers, enterprises and vendors.

I really hope that Java SE 8 actually does the radical things that the platform needs given the big shifts in the last 5 years since a decent release which didn't just dump cruft into the platform. Unfortunately I'm still concerned that the mentality is more to continue outside with a closed community which pretends to be open while actually pushing an already proven to fail line.

Java SE 7... I give it a 'Meh'.

Technorati Tags: SOA, Service Architecture

Dumb IT: We've already got some licenses for this

There are certain phrases that fill me with dread. 'We are using Agile so we don't need to have a vision, we'll just iterate', 'there are no data quality issues', 'We're the first people to use this' and 'The vendors roadmap says they'll do X in 2 years so it will be fine by the time we need that'. One however is completely variable in the fear it introduces because it comes in three clear flavours, one good and two bad.

'We've already got some licenses for this'

What this means is one of three things

1. We need to do something and a technology we know well is ideally suited where we fortunately don't have to buy anymore licenses
2. We bought an enterprise agreement when we bought product X and the vendor allows us to have a few licenses for Y and Z as well
3. I've spent a load of money on licenses for this and we are damned well going to use them

Now clear the first one is fine, this is for example where new functionality is being delivered for a website and the number of CPUs has to be increased.  The later is of course clearly dumb and often is the driver behind IT centric projects that burn money.

The middle-one though however is the most dangerous.  I've seen this over, and over and over again.  A company buys the flagship product from a market leader in a specific segment.  That market leader also has some other products which are either early to market, non-strategic or just plain a bit rubbish and to 'sweeten' the deal they include a bunch of licenses for them and offer this up as value.

A few weeks, months or even years later a project comes along which needs to do a specific thing.  Suddenly someone remembers, or most often pushes, that there are some licenses on the shelf that do that sort of thing so brilliantly money can be saved.

Let me recount a story of just such a decision....

In 2001 I was working with a company who had bought a enterprise package solution from one of the market leaders in the CRM space.  As part of this 'deal' the company was allowed to use up to 4 CPUs of any other product from that vendor.  We had to produce a website to enable consumer to interact directly with the package and this was well before .com front-ends were normal practice.

'Fortunately' the vendor had a new product to do just this, it was new, it was shiny and it was covered by the 4 CPUs.  The alternative was to spend about 6 months developing something custom with about 5 people and despite some heavy cautioning from me on adopting a brand new, unproven technology that looked rather rubbish when I investigated it the company decided that it would be cheaper because of those 4 CPU licenses....

18 months later and with an average team of around 15 people and much hacking, cursing and challenge the site went live with a fraction of the envisioned functionality.

So that 4 CPU 'saving' had in fact delivered a 20 man year cost increase and less functionality.

Want another?  How about the company who used some old EAI licenses and found out half-way through the project that the vendor was discontinuing the product?  How about the company who used the limited number of Web content management licenses and found that 10 years later it was a drain down which millions had been poured... seriously I could go on and on.

The point here is that lots of IT seem to account for license costs in a completely different way to people costs.  Something that saves [£€$]10 of license cost is good even if it delivers 10x that in additional people costs.

The solution is simple, when you look at a programme evaluate the total cost of ownership of the solution not just the immediate cost of buying licenses.  Cheap today is liable to be expensive tomorrow and potentially extortionate the week after that.  TCO is all that should count in these decisions but normally the lure of 'free licenses' outweighs the rationale of 'that isn't the right tool for the job'.

Now that really is Dumb IT

Technorati Tags: SOA, Service Architecture

Hackgate and what it teaches us about responsibility

The ongoing Hackgate scandal, we can call it that as people in the US are now interested rather than just the dull old 'phone hacking scandal', teaches us some very interesting lessons about corporate politics and the meaning of the term responsibility.

I see quite a few projects where the issue is that someone somewhere hasn't taken control or responsibility and therefore things have gone off the rails. A lot of the time this is about the personality types involved and those personalities massively impact how any recovery can be achieved.

In this scandal we've seen so far five completely different views of responsibility and each of these teaches us a lesson we can learn from

Responsibility without Action but with blame - David Cameron
First up is the Prime Minister David Cameron who has taken 'full responsibility' for hiring Andy Coulson.  What full responsibility means here is that he has stated that he takes that responsibility, but in reality actually nothing has changed or is in danger of actually being done.  I often see this on projects where a senior business sponsor has a pet project that they actually don't care that much about but just want to see it continue for power reasons.  As with this occasion this responsibility normally actually means shooting the project manager or some other individual so in reality what is being said is that the senior individual actually bears no real responsibility and that the failure is further down the chain of command.

This is very common in IT projects, often you will see a programme director being promoted during a project and then taking 'full responsibility' by firing the person who had to clean up their mess after they were promoted.  Its a very good career strategy as it implies that you are the sort of person who takes decisive action and has person integrity but in reality is classic blame farming.  This is one of the hardest situations to deal with when recovering a project as you often need the sponsor to change some of their behaviours and what you get instead is a continual statement that they have 'taken responsibility' but actually in reality done nothing to change the behaviours that led to them having to take responsibility for the failure. These people can be very useful when you recover a program as they are keen to be seen to be doing things and if you can leverage that into action it can be a positive thing.

Responsibility without responsibility - Rebecca Brooks
Rebecca Brooks (nee Wade) typifies another form of rogue sponsor when issues occur.  In this case the sponsor is often actively involved with the project and seen as more than simply a sponsor but actually a leader of the initiative.  Trouble occurs and the sponsor throws up their hands and claims that they had no idea at all what was going on and are appalled at how they were kept in the dark.  This is a very tricky act to play but if played well normally means that the entire project is about to get a huge kicking as literally nobody is going to protect the individuals and indeed the previous sponsor will often be the most vicious in terms of lashing out in order to protect their own reputation.

In IT programmes I regularly see this where a project within an IT Director's remit is failing and they see that their best chance of coming out well is to be seen as a 'strong' leader who has so many things to do that they can't be faulted for 'trusting' lieutenants who then turned out to be rubbish.  When trying to clean up a project these people are toxic as normally their only interest is ensuring that no blame ever attaches itself to themselves, Brooks' initial leading of the 'investigation' is a classic case of this where someone closely associated with the issues tries to ensure the 'correct' outcome by either directly or indirectly leading the investigation.  Sometimes in IT the phrase 'lets draw a line under it and move on' is used which can help if its meant as it means everyone can get on with fixing the problem rather than with worrying about the political issues.

Responsibility with personal accountability and exit - Sir Paul Stephenson 
Then we have the Met Police chief who has resigned for the faults within his organisation which pretty much no-one feels touch him personally.  His extremely barbed comment pointing out that his mistake was to employ someone who hadn't resigned in the original scandal, as opposed to David Cameron, clearly highlights what he feels is a double standard in how people talk about responsibility.  Now from one perspective having the overall sponsor take responsibility and leaving because of it demonstrates strong personal integrity and leadership, but in another it also means that the folks below are left without a clear leader and therefore there is uncertainty on who will clean things up.

In IT this often unfortunately occurs when the sponsor feels they can leap into another job somewhere else if they go before they are pushed.  The challenge to the project team remains who will clean up the mess and drive it forwards.

No responsibility but lots of finger pointing
What has been most common in this scandal is lots of people from the outside pointing fingers and suggesting how things should be cleaned up, with in the most part very little actual personal commitment in helping to clean things up.  MPs have condemned and moaned, but not promised to stop religiously courting the media.  Other scandal sheets have condemned and moaned about its impact on the reputation of 'good journalism', but certainly not offered up themselves to be investigated to clean their names.

This is really common in IT recovery programmes, lots of people standing on the sidelines with 'helpful' advice on how to improve or how to 'learn' from the mistakes but zero actual time commitment in cleaning things up.  Managing these people is central to recovering an IT programme.

No concept of responsibility
Paul McMullen has been the comedy turn of this scandal, a man so divorced from reality that he continues not just to excuse but positively to champion the sorts of behaviour that everyone is condemning around him.  Here is a man who both Hugh Grant and Steve Coogan have show up to be a total and utter muppet of the highest order.  At some stages I've really wondered if he isn't really a journalist but in fact a very hammy actor who is over playing the part.

In IT these are the folks who just don't get that there is an issue.  I once interviewed an architect shortly after Boo.com had failed.  He had been responsibly for lots of their key architectural decisions, several of which were behind the inability of people generally to use the site.  During a curtailed interview he continued to champion the approaches they had taken, which had failed, and even managed to support and promote the business model for Boo.com which had managed to burn through lottery winning cash in an amazingly short period of time (one founder entertainingly stated that they were 'too visionary', nope it was a bad idea, badly implemented).  People like this must be quickly exited from the programme as if they can't see any issues then they will be unable to fix them.


Responsibility with Action
What we haven't really seen so far is someone take responsibility with action in this crisis.  Sure the News of the World has been closed down but allegations by Jude Law against the Sun have been met with abuse rather than a culture of 'we are pretty sure we didn't, we take these allegations seriously, will will investigate and we are confident we will prove our innocence'.  The closure itself was simply an acceleration of a previously announced policy so there really hasn't been that active leadership yet in cleaning things up.

Responsibility with action in an IT failure is the person who stands up and says 'mistakes have been made, right lets fix them' and sets about driving change and leading the cultural shift that is normally required to recover a failed or failing project.  Responsibility with action is normally a quiet thing rather than a shouty thing,  its something that is done rather than talked about.  It isn't a committee to investigate  its an active approach to finding what went wrong and fixing it as quickly as possible.

Critically its not about blame in the sense of finding people to blame, its about finding problems and when these problems turn out to be people then those people are given the simple choice: change or leave.  It is about finding people who should have taken personal responsibility and ensuring that next time they do.

Recovering projects is normally one of the most thankless tasks that I do.  You enter into a scenario where someone else has screwed up and your end result is getting the project to a place where it should have been ages ago.  There is however something personally rewarding in changing the culture of individuals so that they are able to recognised the mistakes that were made and in exiting the toxic people from the process.  Crucially however there is one lesson that I've learnt doing this and that is that the first stage has to be recognise that there are systemic problems that need to be fixed.  If it turns out that actually its a localised issue then this is great, but the assumption must be that the rot is much broader and more general than the currently surfaced failure.  Normally there is a culture of poor sponsorship, leadership, management and clarity that leads to a general case of fail in which only the scale of the project fail stands out.

If you do see a project failing the first thing your should identify is not what went wrong in the weeds but how the sponsors and leaders will react.  Will they behave like a Brooks and deny everything?  Like a Cameron and take 'full responsibility' but actually blame farm?  Will they deny that there actually is an issue like McMullen? Will they fall on their sword and leave a vacuum or do you have someone with whom you can actually work to drive through the recovery?  Clarifying this 'top-cover' challenge is the first step in recovery,

Remember: Don't just people on whether they say they take or have responsibility but on what they do
 

Technorati Tags: SOA, Service Architecture

Preaching to the Choir: the bane of IT

Sometimes I get asked why I bother debating with people who clearly have a different opinion with me and are unlikely to change their mind. The reason is that sometimes, rarely I'll admit, that sometimes I will change my mind and occasionally I will change theirs.

The other reason is what is the point of debating with someone who agrees with you? Unfortunately in a lot of IT we have two types of discussion

1. Religious discussions based around IT fundamentalism
2. Preaching to the Choir to re-enforce the message

These two are very closely related.  Effectively a group of people talk to each other about how great something is and how fantastically brilliant that approach is and how the whole world should bow down before their joint vision of the future.  These folks then head out to 'spread the word' and are just plain shocked when people fail to accept what they say as the gospel truth and normally either result to insults, making up facts or just plain ignore any comments or questions.  Quite typically this later bit includes doing farcical comparisons like

Q: Where are your references?

A: Same as yours, personal experience

Q: Err but mine are published on the web, here are a bunch of links...

A:

This is a conversation I've had many times.  The reason for this post however is that on Google+ someone replied to a post by Jean-Jaques Dubray (which referred to this post) and after a short discussion where the individual started with a personal insult and moved on to ignoring questions and instead posting their own PoV finished with the brilliant line

Wrong audience and tone

Which of course just means that the person feels that they want to go and speak with people who agree with them unquestioningly.  This mentality is a massive problem in IT and, I feel, more prevalent in IT than almost any other discipline.  Whether its the 'leadership' of the Java group ignoring huge amounts of external input that disagrees with them or the various little pieces of fundamentalism around its a significant issue that folks tend to switch from one fanaticism to another without often pausing between them.  The number of times I've bumped into someone a couple of years down the road who is now a fanatic for another approach is just stunning.

I remember once saying at JavaOne that UIs are best created with tools and was told in no uncertain terms that you couldn't build a single complex UI with tools, it had to be hand coded.  I pointed out that I'd built an Air Traffic Control system where everyone was using visual tools for the UI side building, this was a system that was already in production, the reply was 'good luck with that, it won't work'.  Much back-slapping from his friends for 'putting me in my place' while I wandered away sadly wondering if people really could be in IT and want to learn so little from previous experience and instead just create a small clique that backs them up.

I've come to realise that this is sadly exactly what lots of folks in IT prefer to do, they prefer to create an 'us v them' mentality and form small groups of 'evangelists' who preach to each other on the brilliance of their ideas and the stupidity of others for not understanding them.

Its this fractured nature that leads to groups denying any benefits from 'competiting' approaches or even from historical ways that have been proven to work.  Often things come from first principles and sometimes (and this is the one I find most scary) is tied to a single published work which becomes 'the good book' of that clique.  The choir preaches to themselves and sees success when none exists or defines success purely based on their own internal definitions.  The debate that is engaged in works on a very poor level as no challenge is allowed to the basic assumption that they have found the 'holy grail' of IT which will work for every sort of approach.

Preaching to the Choir is at the heart of this issue.  Talking and debating only with those who agree with you is a bad way to test ideas.  The Oxford Union is what debate is about, two sides trying to convince the other and the audience deciding who won.  Argumental has built a programme around people being made to debate on a topic they might not even agree with (although in the linked video Rufus Hound doesn't make a very good job of that).

If all you hear is 'that is great, brilliant, anyone who disagrees is an idiot' then I'm afraid that you are an idiot as you are in danger of wearing the Emperors new Clothes and are clearly taking the easy way out. If you can't convince other people of the power of your argument this is most likely to be because there are flaws in your argument that you don't understand or know, not that the person you are debating with is an idiot (sometimes this will be true of course).

The basic rules should be

1. Facts count - if you can reduce things to quantative assessments then you are doing better
2. Ladder of Inference - you need to build from the first point of the debate, not start at the end
3. Answer questions - if someone asks a question, answer it
4. Think about where the other person is coming from
5. Read opposing views, learn from them
6. Accept when you don't agree - sometimes people will differ and that is okay, accept it

I find it quite depressing when people say 'I'm not talking to X as he can't be taught about Y' when I know that the reality is that X has a very good point of view that the person saying this really should listen to as they'd learn something even if it challenges their current IT religion.

So please can we stop preaching to the choir and start having actual debates, it doesn't matter if the tone is a bit disrespectful or sarcastic as long as you are challenging and responding to challenge.  It should be a fierce debate on occasions and that is fine, but what it shouldn't be is just preaching to the choir and denouncing all those who disagree as heretics.


Technorati Tags: SOA, Service Architecture

SaaS integration - making the ERP mistakes on a bigger scale

One of the most frustrating things in IT is the totally amazing ability of people not to learn from past experiences. The following are all the sorts of things I've recently heard at conferences, vendor presentations, business presentations and in company architecture practices.

"We don't need an MDM solution as Salesforce is going to be our only customer repository"
"Integration is simple, its all just REST or Web Services, we don't need to worry about that"
"We are moving to SaaS because it doesn't require integration and dealing with IT"
"The business are on their own if they do SaaS, we just deal with the internal IT"

And a whole litany of others over the last few years. The general theme is that business folks are commissioning SaaS solutions and in collusion with the technically naive are setting up entire new estates beyond the firewall. Meanwhile the internal IT groups are often washing their hands of this deliberately and fighting against the change.

Lets start with the first statement, as its the one I've heard several times.

I don't need MDM, my SaaS CRM is my master


This probably wins it in my book for the least ability to learn from IT and business history.  This is exactly what folks did in the first CRM rush in the 90s and have spent the last 15+ years trying to recover from.  Fragmentation of customer information is a fact, even more so in these days of social media, so starting a strategy with the idea that an externally provided solution in which you have little or no say and which is set up to be good as a SaaS solution not as an enterprise source for customer matching, merging and dissemination is like doing a CRM project in the 90s by lobbing money at consultants and saying "build whatever you like lads".... really not a good idea.

If you are going to look externally for SaaS, and there are good business reasons to do so, then the first question should be how to create the unified information landscape that modern businesses require.  That is an MDM problem, which only gets bigger as you include suppliers, products, materials and all of the other core entities that exist.

Integration is simple, its just REST/Web Services
While the CRM one is a joint IT/biz error then its this one where IT really excels itself in ignoring the past.  Integration is a hard problem in IT, its made much harder if you don't have MDM style solutions, when looking at SaaS the fact that you have published interfaces helps slightly but you still have the challenges of integrating between multiple different solutions, mapping the information, mapping the structure and of course updating all this when it changes.  That however is of course just the technical plumbing.  Then you have to look at your business processes that span across SaaS solutions and the enterprise as well as where to add new services into that environment.

The spaghetti mass of ERP and enterprise in the 90s which EAI aimed, and mainly failed, to solve will be nothing compared to this coming morass of externally competing companies who have a real commercial reason to keep you locked to their platforms and approaches and have the actual ability to make things tough as they can change their platforms as they want without asking for permission.

We are moving to SaaS so we don't have to deal with IT
This is a common refrain that I hear, but its very short sighted, what it really means is that the current IT department is broken and not meeting the demands of the business and not even properly explaining to the business what is going on.  This really is just storing up problems for the future, or just delegating the problem externally to another group who will end up being your IT department in future, but probably harder to shift and change that your current group.

If the business do SaaS that is their problem, we just do internal IT
I like to think of this as the IT redundancy programme, its a wilful attempt to ignore the real world and it really is only going to end badly.

Summary
The point here is that moving to SaaS is actually a bigger challenge for integration and information management than the old ERP challenge, but most companies are entering it with the same wild-eyed wonder that companies entered the ERP/CRM decade of the 90s.  Leaping in and just assuming that historical problems of integration will disappear.  The reality is that companies need to be more structured and controlled when it comes to SaaS and the IT departments must be more proactive in setting up the information and integration infrastructure to enable this switch.



Technorati Tags: SOA, Service Architecture