The power of ideas

My wife and I take our two basset hounds for a walk almost every day. We are very lucky to live close to the forested area that is owned and maintained by the New England Forestry Association. The path we usually take leads along a wooded trail that climbed to the top of a hill where there is a breathtaking view down into the town of Littleton MA and all the way to Maine on a clear day (see the pix below). Now my wife works in patent law and of an evening last Memorial Day weekend on one of our walks I started to tell her a story I had been told previously by a colleague about the power of ideas. The story is close to my own heart as it talks about the importance of ideas as against their implementation.

My colleague story was about how Thomas Edison did not actually invent the light bulb he invented an improved filament for the light bulb. Edison filed his first patent application for "Improvement In Electric Lights" on October 14, 1878 (this and other very interest facts can we found on Wikipedia page on the Incandescent light bulb. The light bulb had been invented and patented a few years previous but the implementation in that patent was almost unusable. Nonetheless the idea of the light bulb had been patented and Edison knew that without the patent to the crappy light bulb he would need to pay licensing fees for every light bulb he made. He resolved this by buying the patent from the original inventor which allowed him free rein in the light bulb business.

To understand how truly rare and insightful these ideas can be, consider the idea of the computer. It had been 72 years now since Alan Turing gave us the idea of the Turing machine which is the basis of today's computers. But with all of our technological advances with the silicon chip etc, and all our laughing at the idea at punch hole cards, the fact is that today fastest super computer is fundamentally the same machine as that built by Turing during the second world war,The machine that would become the heart of Bletchley Park, during operation ULTRA, to help decipher the German enigma machine. A machine so key to the outcome of that conflict, it was according to Winston Churchill "... thanks to Ultra that we won the war."

My wife told me that in legalese, this notion of the idea as against its implementation is one of the differences between ‘Freedom to operate’ and patentability. (Now a word of caution here, I am not a patent legal expert, and getting your patent legal advice from a blog is ... well lets just say not wise). Where as patentability checks an invention for novelty, non obviousness, and that is has a utility, ‘freedom to operate’ on the other hand is the legal right to use and sell your invention without stepping on anyone else patent, In my light bulb story above because the idea of light bulb had already been patented, abiet with a terrible implementation, Edison still needed to buy the 'freedom to operate'.

My long winded point here is that anyone can come with ideas so put aside some time to think and the next time you do let your mind loose a while and think in terms of freedom to operate, think in terms of the light bulb, or the computer, or renewable energy.

Requiem for a developer

The more I think about SOA the more I believe there is only one real logical conclusion and that is less jobs for us IT folks. Now before I descend into the doom and gloom as to why we are all unwittingly developing ourselves out of a job here I was to go back to school. One of the poems I studied in high school (we called it secondary school where I came from) was T.S. Eliot - Macavity: The Mystery Cat

You'll be sure to find him resting, or a-licking of his thumbs,
Or engaged in doing complicated long division sums.

I always loved the idea of an alley cat capable of doing complicated long division sums. We will come back to Mccavity again later but for now I want to share an experience I had recently while helping a customer with SOA.

I have been involved with helping an insurance company migrate to a business driven SOA. Late last year I helped their personal lines business identify and specify their reusable services. More recently I was back doing some service modeling for their commercial lines.

This gave me a better view of their overall service portfolio and allowed the customer to see the value of standardizing on a common message model and also to see which services are being reused the most. One of the services we identified was a customer relationship management (CRM) kind of service. As the name suggests this service was typically used for recording customer information and preferences. This is a good example of a service is reused by many business process and services and is also reused across the two silos of the personal and commercial lines.

It is not usual or uncommon for a company like this to have one or more CRM like applications in each of the information silos i.e. personal lines would have and CRM application, commercial lines would have another one, etc. Depending on the organization this application could be home grown i.e. written and maintained by the company own IT department, or there could be some third party application that is maintained by the IT department.

As the company now begins to agree and standardize on a common service definition for the CRM application, the question becomes, who will implement this interface. There are at least a couple of answers to this question.

1. The first is that there will be a common interface but the existing backend application in each of the silos will be responsible for provisioning this service and it is up to the message infrastructure to do the necessary ‘content based’ routing to make sure the correct application is invoked.
   
2. The second answer however is where things get a bit hairy. Now let us consider this from the company CIO perspective, he very proud of all the work that went into agreeing on and specifying a CRM service interface that is now used by everywhere across the company. However, he still has a number of CRM applications, being used to provision this service, that need to maintained, upgraded, debugged etc. What will really hit him, at this stage, is the fact that this is an insurance company and yes of course their customers and their relationship with their customers are their top priority but managing and maintaining this information is not, nor will every be core to their business. Indeed there are a lot of other companies out there whose core business is managing and maintaining customer information. Once he realizes this, it is only a matter of time before he decides to sun set all their siloed CRM application that have been consuming so much of his time and recourses and either bring in one third party CRM application or even more realistically out source the implementation of their CRM service to a third party like Saleforce.com.

It does not take a rocket scientist to do the math here. If we start to consider all of the CRM application in all the silos of this insurance company, of every insurance company, indeed of ever company which does not have managing and maintain customer relationship information at it core business (because every other CIO will come to the same conclusion) now being out sourced to a third party. That equates to a lot of IT staff with a lot more time on their hands. Of course I have just focused on CRM here; the same could be said about claim management. I do not want to talk for the insurance industry here but it is not unreasonable to assume that underwriting is the core competency of insurance and that in theory once the service specifications had been specified then all of the non underwriting services could be out sourced.

The second option taken to its extreme scenario could even lead to the CIO putting himself out of a job and where insurance companies of future would be staffed by small number of very smart number cruncher, who just like my old pal Mccavity are capable of doing some very complication long division sums.