Thursday, July 9, 2009

Time travel, context and The Tube

In 1931 Harry Beck a temporary draughman with the London Underground created a topological map of the London Underground tube system. To this day Beck original design can be seen all over London and the map itself, along with becoming a cultural icon, is considered to be one of the best maps ever drawn. Despite the fact that the map itself is widely inaccurate, Beck genius was to understand that the only information that a London Underground traveler cared about was the topographical information of the network and he sacrificed all other detail for this simplicity.

In previous posts I have taked about the importance of mapping context to content to help enable asset consumability. We can think of context in terms of scope and it can scope can be thought of in terms of mathematical sets and by expressing context relevant information in terms of scope we can subset our content down to reflects our context. So for example I am a visitor to London, in this context I am a traveler and tourist in central London and I want to use the London Underground to get around. This scoped the London Underground map down the the map below.



Now I find myself in Victoria and I want to go shopping on Oxford street. The only London Underground Line that I am interested in is the Victoria Line and the map is scoped down to just show me that. This map (or content) is maps to the context of a traveler in central London, who wants to used the London Underground to get from Victoria station to Oxford Circus station.



Similarly if I found myself again in Victoria and wanted to go to Tottenham Court Road then the the Underground tube map would scope down to just showing me the Victoria Line and the Circle Line and showing me where their intersect so that I could change tubes at the appropriate station (in this case Oxford Circus).

Finally, if we had access to H. G. Wells time machine I could be a traveler in time as well as space. As we can see from Beck original map the London Underground had changed considerably, new stations and lines have been added over time. Now by temporally scoping our London Underground map to take this into account, I could accompany Mr. Wells and travel back to 1930 and my topic map will be undated accordingly.


Wednesday, July 8, 2009

Presentation best practices

Yesterday we kicked off the first meeting of the presentation best practices course (to be held monthly on the last Tuesday of ever month here at the IBM SWG Littleton Campus).

Presentation best practices course: This course would be a hands on where we would try and teach presentation (and in particular technical presentation) best practices. It would be different from the formal presentation course in that this course would be more of a discussion of current best practices and style along with some demonstrations and the chance for participants to present and try out different styles and techniques in a sandbox. In particular this would again hopefully target the more junior technical people starting out on their technical career to try and guide them in terms of presentation content and style.

The two books that will be referenced during the talking are:

Here is the presentation that I gave:




Further reading on some of the topics we covered yesterday can be found here


The following material are also relevant
Also links that came out of the presentations

Wednesday, January 7, 2009

I'll be back - the problem with asset reuse

A key tool in Engineering SOA solutions is the ability to leverage and enable existing assets. In the SOA world a broad categorization of these assets would be industry model assets, software patterns assets, legacy assets, etc. In a dW Rational Edge article last year, titled Enabling asset consumability, Celso Gonzalez and I discussed the problem of findability of assets, i.e. what are the right assets for the problem at hand?. We proposed that the problem of asset findability can be addressed by better understanding the context in which the assets are needed and then mapping that context to the relevant content or assets. Now that we have an asset that can assist in a certain context (e.g. a map when we are driving) how can we maximize the reuse of that asset (e.g. how do we make sure the map can be read). Better yet how can we automate consumption of an asset. To illustrate the complexity inherent in this goal, of automation of asset consumption, lets examine how Hollywood views this automation. Let us turn to the mother of all automators, The Terminator and discuss a scene from James Cameron Sci Fi film classic: Terminator 2: Judgment Day.



The Terminator 2 movie opens with two terminator machines arriving 'back' from the future to LA, California on June 8th, 1995. The T-101 terminator, played by Arnold Schwarzenegger, is sent back to protect a young John Connor (soon to be leader of the resistances in the upcoming war again the machines), where as the more advanced T-1000 is sent to 'terminate' him. The scene, of interest, happens shortly after Conner, the T-101 and the T-1000 clash for the first time, in an LA shopping mall. Connor narrowly escapes, on a dirt bike, and is hotly pursued by the T-1000 driving a big rig. The T-101 joins the chase, exiting the mall on a Harley Davidson (Fat Boy) motorbike, crossing multiple lanes of traffic, accelerates out of low speed turn and takes off at speed after the endangered Connor.

Let us now reexamine this scene from the perspective of a T-101. The table below shows us the current context from the T-101 perspective. This includes the T-101 (who) place in time and space (where/when) and also his overall mission which is to ensure John Conner survival at all cost (what/how). The T-101 also has an immediate requirement to now peruse the endangered Conner (what - immediate). To help him with this context and this immediate requirement the T-101 needs to search for some kind of asset to help him. But before we examine this further there is another 'how' here that we need to consider.


Context

Value
Where
North America, California, LA, mall
When
June 8th, 1995
Who
Terminator (reprogramed as a protector)
What
Ensure the survival of John Connor
What - immediatePersue John Connor
How
At all costs


There is also an additional unseen 'how", imposed by the movie executives, that T-101 looks 'cool' when he is executing on his day to day 'whats'. Given this set of context it clear that the T-101 requires some sort of conveyance. A conveyance is a good example of a reusable asset: It can be reused over and over to convey a person from point A to point B. Thus from all of the assets available to the T-101 in this particular context we have scoped the list of assets down to just a choices of conveyances that are available in a particular mall in LA in 1995. This brings the list of conveyances down to: cars, motorbikes and maybe push bikes. Finally the movie executive mandated 'cool' non-functional requirement kicks in and T-101 exits the mall, in truly spectacular Hollywood fashion, atop the 'Fat Boy' Harley.

Having addressed the issue of findability of a asset we now turn our focus to the problems of reusabilty of the asset. The T-101 needs to know how to use this asset. In essence the T-101 needs to know how to ride a motorbike. To execute the maneuver in the scene above requires intimate knowledge of how to handle a motorbike. Executing a low speed turn on a bike of that size and weight requires the rider to counter balance the bike and the speed is then a delicate trade off between clutch, accelerator and brake (with the caveat that is ill advised to attempt to brake while executing a turn). The point here is that without intimate knowledge of the inner working of the asset the T-101 would be unable to reuse this assets or worse would misuse the asset.

Exploring this a bit further, if the T-101 has only partial knowledge of how to use this particular asset the results would be disastrous and chances are he would have wrapped the Fat Boy around a lamp pole, probably taking a few innocent by-standers out in the process. The effects of this experience on the T-101 would be to make him weary of choosing this type of conveyance in the future under similar context conditions. Following this line of thought, the same argument can be made about the reuse of any 'complex' asset. This limits the T-101 choices in terms of the assets types he can choice from to satisfy the particular context. Sure he could choose a pony and trap or a push bike as possible conveyances. These assets are considerable less complex than the Fat Boy Harley but neither of these assets would have been sufficiently effective to help him achieve his objective.

Bring this full circle. It is not enough that we are able to automatic how we map particular assets to a relevant context, but those assets need to be engineered in much as way as to maximize their reuse potential. This T-101 thought experiment leaves us with a number of options for increasing asset reuse:
  1. Confine ourselves to simple assets e.g. use the pony and trap as against the Fat Boy

  2. Better educated the practioners in the use of complex asset

  3. Engineer or re-engineer complex assets with a view to achieving an acceptable balance between effectivity and complexity
We will explore this last point in more detail in a future blog entry.

Saturday, September 6, 2008

To iPhone or not to iPhone?

Last Sunday my lovely wife and I took our hogs for a spin (see picture). The ride brought us from our home in Littleton MA (home now to the new IBM Mass Campus), along the railway tracks until we climbed west across Oak Hill (the northern tip of a long ridge of hills called Shrewsbury Ridge by geologists) and onto the quaint town of Harvard MA.




From The hogs 8/9/...
What was different about this particular ride was I had my new 3G iPhone with me. Part of what attracted me to the new iPhone was the integrated GPS. So as our hogs wind out way through the pre-fall countryside to the sounds of the new Coldplay album, I was also able to track our route using a iPhone application called GPS Kit (which I purchased and installed on the phone using the App Store). This cool application then allows me to email the GPS data of our route and you can see the result below in Google map. Click on the picture of the map to bring up the actual map and data.




Now by the time we reached Harvard and its quaint general store I wanted to know a lot more about GPS so I plugged it into my nifty iPhone Wiki application called Wikipanion (it reformatted the wikipedia page to be more iPhone friendly). From this I learned two things:

  • Did you also know that the pix above of our hogs was taken outside that quaint Harvard general store and since I took it with my iPhone camera is it also geotagged and you can see it on the map here


Now I know all you Apple Inc haters out there are screaming for blood at this point, and to be honest I am a long time hater myself. But... and this is a big but, this is one beautiful piece of hardware. Apple have long understood the importance of the combining the artistic and the aesthetes of the right brainers with the technical know how of the left brainers and none of their product show this more clearly than the iPhone.

So in answer to the question posed by title of this blog, to quote Auden from his poem The Unknown Citizen ‘The question is absurd’ ... get up off you caboose, forget that you will need to sacrifice your children college fund just to cover the monthly AT&T bill, get inline with the rest of the great unwashed and get one :).

Enabling asset consumability: Is your wardrobe good, bad, or ugly?

Another colleague and friend of mine Celso Gonzalez and I have just published a paper on dW Rational Edge on some of our thoughts around enabling asset consumability. Here is the abstract


Enterprises are often good at producing or creating assets and artifacts but are typically very bad at reusing them. This article describes a way to facilitate asset and artifact consumption by better understanding the context in which they are used.


The full text can be found in the July issue:
Enabling asset consumability: Is your wardrobe good, bad, or ugly?



Thursday, May 29, 2008

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.

Thursday, May 8, 2008

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.