New book on Patterns-Based Engineering

Two colleagues and friends of mine, Lee Ackerman and Celso Gonzalez have just announced the availability of their new book: “Patterns-Based Engineering: Successfully Delivering Solutions via Patterns”! Published by Addison-Wesley, the book is currently available in digital format with the hard cover edition shipping on July 2^nd.

With Patterns-Based Engineering (PBE), we’ve focused on detailing how to succeed in delivering software via a disciplined, systematic and quantifiable approach that uses pattern specifications and pattern implementations. In doing so, we’ve focused on how to identify, create, manage and consume patterns – and to do so in a way that is agile, repeatable and scalable across an organization. To support adoption and integration of this approach into an organization we’ve delivered a PBE Practice and a set of PBE Patterns and Guidelines. The PBE Practice has been authored using Eclipse Process Framework Composer and can also be used with Rational Method Composer. This practice along with artifacts related to an in-depth case study are available for download from the book’s website at http://patternsbasedengineering.net/.

For more information on the book:

• Visit the website: http://patternsbasedengineering.net/
• Review sample content – contains the foreword and the first chapter.

In the days and weeks ahead they will be publishing supporting articles, delivering webcasts and blogging on topics related to the book. Details will be posted on http://patternsbasedengineering.net/.

Henry Ford on Facebook

If Henry Ford were alive today in the internet era of Facebook, Google and Twitter, the last thing he would do is startup another internet company. Instead he look to provide an organizing principle that would leverage and streamline business to catapult them into the next age of business development. Ford would look to streamline and enable collaborative business development to allow businesses to mass produce, in the internet environment, in the same way as he did with the assembly line for the automotive business at the start of the 20th century.

In 1913 Henry Ford caused a paradigm shift in the automotive business by leveraging the assembly line to streamline car manufacture. While Ford did not invent the assembly line, his sponsorship of its development and his use of it as an organizing principle to streamline manufacture, was central to its explosive success in the 20th century. Ford major contribution was not in the invention of anything new in terms of automotive manufacturing it was about providing an organizing principle that effectively and efficiently leveraged existing technologies in a value added manner.

Today we stand at another tipping point in terms of business evolution. After 20 years of breathtaking internet development, the internet has evolved from simple client server to collaborative social interactions. We have Amazon and eBay to buy stuff, PayPal to pay for stuff, Google to search for stuff, Twitter to tell people about stuff and Facebook to show off our stuff. These are some of the internet giants that have become household names, in the internet landscape of today. Yet impressive as these advances have been, without an organizing principle to allow business to leverage them in a collaborative and added value manner, they will remain a hodgepodge of technologies much like the automotive industry prior to the introduction of the assembly line.

A business centric organizing principle that aligns businesses to allow them to leverage and flexibly combine existing technologies and services will jetism business development into the 21th century. A business framework that will enable businesses to easily collaborate together, with their producers and consumers in a value add fashion, to enabling new business opportunities and strengthening existing ones. This business centric organizing principle is what is needed in today business landscape and will provide the kind of acceleration and enablement that Ford introduced with the assembly line.

Ford’s legacy lives with us today in every assemble line, in every business process and has being the very foundation and building blocks for business for the last 100 years. Today in a rapidly evolving business paradigm not only do we need a new business framework to organize and align business, we also need to think beyond the static and linear business processes and think more in terms of business activities that are achieved by mixing and matching business capabilities in a self optimizing network ecosystem.

A self optimizing ecosystem were business capabilities can be mixed and matched to dynamically realize business activities will allow businesses to become much agile in terms their reactions to new market opportunities and allow for the rapid evolution and realization of new business models.

Asset Intelligence Part 1

Introduction

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.

Over the next couple of blog enteries I will continue to examine the barrier to entry around enabling the consumption of assets. I will also look at a proposed solution to some of these problems by leveraging the ISO standard of topic maps and show how they can be used to represent and unite assets in different domains. I will also look to understand the types of assets used in application development and to understand the context in which these assets are used. Using this context as guide, we will propose a novel approach for suggesting the best asset to be used in a particular context to the end user.

The importance of assets

Ireland is the last country in Western Europe that is still throwing roads at a traffic congestion problem was one statements I remember hearing from my childhood. Back then I could not understand why more roads would not solve a traffic problem however as I traveled the world and had the opportunity of living in cities like LA, NYC, Boston and London, it became painfully obvious that more roads was not the solution. The solution then becomes how do we better utilize the existing transportation infrastructure? Put more simply how do we do more with less?

Recently at a future of application development conference in NYC a lead architect from a world bank echoed these exact same sentiments but this time applied to application development. Now this is a major global bank and their lead architect was telling us that the last thing he wanted, to fix their problems with application development, was to throw more developers at it. Again on first hearing this statement it seems counter intuitive but just like the roads problem above on deeper reflection it makes more sense. The problem, with application development, is the steep learning curve needed to bring these developers up to the point of where they can be productive. Application development, in a radically changing IT landscape, irrespective of the programming model used in not easy. This quickly becomes a problem of managing complexity, a problem that will only get worse tomorrow as this complexity increases. However as with the road problem the solution is similar but first let us pose the proper question. How do we better utilize and empower the existing staff to be more productive?

To better utilize and empower the existing staff we need to move them to an asset based development model[1]. The maintenance of, reuse of, and enablement of these assets (in this case software development assets) is core to managing the complexity inherent in application development today. These assets need to introduced as early as possible in the life cycle to maximize their benefit and their impact and these assets need to constantly be maintained and updated to help maximize their reuse and impact.

The problem with assets

In our article on Enabling asset consumability we have already looked at the problem of findability of assets. Finability is one of the main problems associated with assets. This problem of findability is outlined in that article in the multi bucket problem. However findability of assets is just one of the many barrier to entry to enabling asset consumability andmoving to an asset based devevelopment model. Here are some of those issues:

• Findability - trying to find the correct asset for the problem at hand
  
• Reuablability - Once we have found the assets can it be reused easily to address the problem at hand
  
• Tracability - Once we find and reuse and asset to help us solve a particular problem how can repeat this discovery are reuse for similar problems
  
• Consistancy of assets Glossary and variants

In particular here we was to examine the problems around asset reuse. The point here is that finding an asset is only part of the problem. If you find the asset and the asset is too complex to use then it is useless. But to understand the problem reusablity let us go back to the movies. 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 - immediate	Persue 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

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.

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:

• Give Your Speech, Change the World: How to Move Your Audience to Action (Paperback)
• Made to Stick: Why Some Ideas Survive and Others Die

Here is the presentation that I gave:

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

• Asset findability and The good, bad and the ugly
• Asset findability and The multi bucket problem
• Asset resuse and Terminator 2
• Topic Maps and the London underground

The following material are also relevant

• http://www.madetostick.com/bookresources/

Also links that came out of the presentations

• TED (Technology, Entertainment, Design) presentations

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 - immediate	Persue 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.

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 know that President Ronald Reagan make the GPS system available for public use following the shooting down of Korean Air Lines Flight 007 in 1983,

• 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?

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.

More from Services-based enterprise integration patterns made easy

A third article from Dr. Waseem Roshen, in the series titled: Services-based enterprise integration patterns made easy, appeared today on dW SOA and Web services zone. Here is the abstract:

Part 1 and Part 2 of this series covered the basic concepts necessary to develop services-based integration patterns. This article, the third in the series, and the upcoming Part 4 further develop these ideas so the services-based integration patterns become full-blown services-based patterns. This article in particular deals with the components that are together commonly referred to as Web services, which were originally designed for services that can be accessed over the Internet. You'll also see that many of the Web services components can be used with services that don't use the Internet and that only require a network connection.

Create collaborative and dynamic method content using Web 2.0

developerWorks, SOA and Web services zone has just published the first in a series of papers that looks at addressing some of the ideas around context to content to enable asset consumability that I have been talking about on this blog, This paper titled: Create collaborative and dynamic method content using Web 2.0, talks about how to leverage Web 2.0 technologies to extend software development process content, which is typically published static as HTML. This article describes how you can develop the ability to collaboratively edit method content and have access to the latest dynamic content within a method context.

For this paper, and indeed many other papers, we have been fortune enough to work with developerWorks own, Patrick Flanders, and Ashleigh Brothers who do such a professional job in terms of reviewing, editing and laying out the content.

Among the school children

A couple of weeks ago I was giving a talk on enabling (pattern) asset consumability at an IBM hosted best practices conference down in Palisades, New York. The talk was scheduled to be at the end of the day so I knew my audience brains would be fried and overload by technical content by this time. Also, the title of my talk enabling (pattern) asset consumability would make the best of us yawn. So I decided on a different tack here, I am still not sure how successful it was, since only a handful of poor souls made it to my talk, but here it is anyway.

Recently I have read two excellent book on speech giving. The first is Give Your Speech, Change the World and the second on is Make to Stick. Now where there first book is excellent in detailing how to actually give presentation, the second book excels in detailing how to make your messages, in those presentations, stick to your audience. So for my talk I decided I would shake things up and open with a poem in a effort to exercise the right side of my their brains. The poem titled "Among the school children" from one my favorite poets W. B Yeats. Now this poem is long over 8 stanzas, so I just focused on one of the stanzas, here it is:

Plato thought nature but a spume that plays
Upon a ghostly paradigm of things;
Solider Aristotle played the taws
Upon the bottom of a king of kings;
World-famous golden-thighed Pythagoras
Fingered upon a fiddle-stick or strings
What a star sang and careless Muses heard:
Old clothes upon old sticks to scare a bird.

Here Yeats is examining the philosophies of some of the worlds famous philosophers from Plato to Pythagoras, yet with all their knowledge and insights, they all still withered and died away. In his later poetry, Yeats uses this recurring theme of a scarecrow to symbolize his own mortality. Here from the same poem:

Better to smile on all that smile, and show
There is a comfortable kind of old scarecrow.

As I said I am not sure how successful this technique was, my audience of five just was enough to swing it either way, but I would certainly be interested to know of other unconventional speech giving techniques that you have used in the past that have worked?

We will be publishing a paper on this talk soon and will post the link as soon as it becomes available.

A common message

Last month I did some service modeling work for a well known insurance company in the US. After five years of helping customers with SOA this particular company was very mature in terms of their cultural alignment between their business and IT stakeholders and was also adopting some of the best practices and patterns around SOA enablement.

A little background, this company is typical of so many other Fortune 500 companies in that the business struggles with it silo-ed nature, that has been built up over decades. Two simple silos within this organization are the personal and commercial insurances lines, both offering insurance products to different customer bases.

SOA is all about aligning the business with the IT and for this to happen they have to all speak a common language. To help understand this better lets take a simple analogy of the worlds favorite organization the United Nations. Now I am not privy to the internal working of the UN but I do know that it employs a lot of interpreters to interpret from one language to another. Take the example of an interpreter working for the French ambassador. This interpreter will need to be able to interpret from French to Chinese, from French to English, etc or to whatever the native language of the person the ambassador is talking with. This is clearly a very stressful job for the interpreter. Now lets pretend that I have been put in charge of the UN and have decreed that from now on the common international language will be Irish (this would be a complete disaster by the way, as Irish is notoriously a very difficult language with needlessly complicated grammar and syntax, I know this because I spent 14 painful years in school learning it). Now all the interpreters need to know is how to convert from their host language to Irish and back again.

Scaling this up to the enterprise, let us examine three best practices around a enterprise common message model:

1. The first best practice is simply to have one. The business and the IT need to agree upon an enterprise message format, or lingua franca across the organization. Thus what was traditionally a silo-ed organization in terms of personal and commercial insurance (each has a difference via of what a customer/party is) could now start to share service based on a common understanding about what what was a claim, a policy or indeed a customer/party. This really is not news to anyone starting to mature in the SOA space, however, the next best practice is a bit trickier.
2. The second best practice is not to build this enterprise common message model yourself. This can not be overstated. Building a enterprise strength common message model in a big job. To get a sense as to how big, consider IBM Insurance Application Architecture or IAA models. Now I am not here to plug these models, but they have been built up over ten years worth of experience, of practitioners, in the insurance industry. As a result these models are highly normalized and contain some of the best patterns and lessons learned and are what I would consider a mature enterprise model. There are many other enterprise strength message models out there such as ACORD, SID (telco), STAR (automotive) . One also needs to differentiate between industry standard models and priority models and here again I want to outline a best practices in terms of their usage. Industry standard model such as ACORD have been debated and agreed upon by concerned parties within an industry vertical, these models are there typically to level the playing field and provide a good, typically flat, model structure to enable B2B exchanges between companies in that particular business vertical. Priority models on the other hand such as IAA and IBM Information FrameWork Service Models (IFW), are highly normalized models, and are there to provide a company with core differentiation within the marketplace. The best practices then become to use a priority model internally within the organization, to define the internal services and as a lingua franca for the messaging infrastructure and then to use one or more industry standard models to define services that are exposed external to the organization and typically involved in B2B exchanges and delegate to the message infrastructure to convert between them.
3. Finally the enterprise message model must be managed and governed. New versions of these message model are being released all the time as new markets and opportunities arise and your company needs a coherent and consistent way of managing this change. Let us go back to our UN example and imaging that the Irish language was continuously changing (it is not, the Irish language in a considered a dead language), think of the nightmare for the interpreters having to continuously learn a new version of the common language.

For those you foolish enough to want to learn Irish, to champion the cause of having the UN adopt it as a common international language, if refer you to Des Bishop web site

Slán go fóill...

SOA information as a service pattern specifications

Guenter Sauter et al have three excellent SOA Information as a service pattern specification papers on data federation, data consolidation, and data cleansing. You can find these three papers on developerWorks:

• Data federation pattern: The data federation pattern virtualizes data from multiple disparate information sources. The pattern creates an integrated view into distributed information without creating data redundancy while federating both structured and unstructured information. This article describes the federation of structured information (data) with a focus on the SOA context. This pattern specification helps data and application architects make informed decisions on data architecture and document decision guidelines.
  


• Data consolidation pattern: The data consolidation pattern specification helps data and application architects make informed architectural decisions and improve decision guidelines. In this article you will see how you can apply the pattern in the SOA context. The primary business driver for the data consolidation pattern, also referred to as the data population pattern, is to gather and reconcile data from multiple data sources before this information is needed. To do so, it extracts data from one or more sources, transforms that data into the desired target format, and loads it into some persistent data target. The prepopulation of a persistent target is a key differentiator between this pattern and the data federation pattern.
  


• Data cleansing pattern: The data cleansing pattern specifies rules for data standardization, matching, and survivorship that enforce consistency and quality on the data it is applied against. The data cleansing pattern validates the data (whether persistent or transient) against the cleansing rules and then applies changes to enforce consistency and quality. In this article, you learn to apply the data cleansing pattern within a Service-Oriented Architecture (SOA) context. This pattern specification helps you, as a data or application architect, to make informed architectural decisions and to improve decision guidelines.
  

Services-based enterprise integration patterns made easy

A new article from Dr. Waseem Roshen, in the series titled: Services-based enterprise integration patterns made easy, appeared today on dW SOA and Web services zone. Here is the abstract:

This series of articles explains services-based enterprise integration patterns in an easy-to-understand, step-by-step way. In this installment, Part 1 of the series, you learn about the two earliest integration patterns—data sharing only and remote procedure call (RPC)—which help introduce the concepts of service provider and service consumer, platform independence, and connectivity. Exploring RPC helps you get familiar with the basic steps necessary for two applications to share functionality. This article also includes a general description of the concepts of loose coupling, code reuse, and layering and componentization. Part 2 of the series will continue the discussion of the early patterns, while Parts 3 and 4 cover the Service-Oriented Architecture (SOA)-based integration patterns, including examples.

The asset graveyard

One of my favorite movies of all time is Sergio Leone spaghetti western classic: The Good, The Bad and the Ugly. Part of the appeal of this movie is the simplicity of the plot; at its heart it is, a treasure hunt, with the three main characters, the good, the bad and the ugly hunting for confederate gold. Between them they know the location of the treasure, buried in a grave in a graveyard, yet only their combined knowledge will lead them to the prize. Towards the end of the film the Ugly a character called Tuco, played by Eli Wallach, comes upon the graveyard, called Sad Hill, and here in one of cinema truly great moment, backed by a unforgettable score, he begins his frantic and haphazard search for the grave of Arch Stanton.

What is impressive about this scene is the sheer scale and size of the graveyard itself, a conservative estimate would put it at over 2000 graves, arranged in a circular fashion. Tuco starts from the center of Sad Hill, where the graves are oldest, and works his way outward initially in concentric circles but soon his search becoming more haphazard as he despairs at the magnitude of the task. Finally, after a dizzy and Groundhog Day like scene of multiple graves passing by he come upon the grave of Arch Stanton, only to find it devoid of any gold, indeed all that remains is a rotting corpse.

Today, this story is echoed in ever IT projects I have ever been a part of, one of my favorites is from within my own group in IBM. It should be noted here that our team is geographically dispersed so although we talk on the phone regularly,we do not get the chance to chew the fat at lunch or around a water cooler. A good friend and colleague of mine on our team, lets call him Bob, was leading the engineering of one the first SOA service registry for an automotive customer in California. One requirement the customer had for the service registry that it performs within certain limits. Unknown to Bob, our group has tackled a very similar problem a couple of years earlier on another engagement. We realized the importance of this work and created a number of assets around it. These assets feel under the broad classification of the requester side caching pattern of which we created pattern specifications, pattern implementation, pattern documentation (including, dW articles, flash movies and a detailed case study). A full listing of these and other pattern asset related articles can be found on my home page.

Bob unaware of the previous asset work we had done in this space and having I am sure ran in circles around his own repository graveyard a number of times, he did what any other good architect would do, he started from scratch and reengineered the exact same asset as we had two years earlier.

Just like Tuco desperately searching Sad Hill for the confederate gold, Bob too faced the same dilemma, in fact I have witnessed that same dilemma on every IT engagement and software project I are involved in. I dare say that this dilemma is not exclusive to IT but that you will find the exact same problem is almost every human endeavor whether it be an engineer building a rocket to put a man on mars to a lawyer drafting claims for a patent application, How do we provide the right assets,the content, to help solve the problem at hand, the context. In other words, how do we automate a context to content mapping to suggest the best assets to our architects, engineers, lawyers to help them?

IBM Redbook on Strategic Reuse with Asset-Based Development

A good friend of mine Lee Ackerman let me know last week that a IBM have just publicly released a draft of a new IBM Redbook, titled: Strategic Reuse with Asset-Based Development.

The Redbook is structured as follows:

Part 1. Introduction

• Chapter 1. Introduction to Asset-Based Development


• Chapter 2. ZYX Electronics case study


• Chapter 3. Tools in support of Asset-Based Development


• Chapter 4. Introduction to the IBM Rational Unified Process


• Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins


• Chapter 6. Value, impact and return on investment

Part 2. Reusable Assets

• Chapter 7. Adopting Asset-Based Development


• Chapter 8. Configure your asset repository


• Chapter 9. Produce reusable assets


• Chapter 10. Consume reusable assets


• Chapter 11. Manage reusable assets

Part 3. Service Assets in an SOA

• Chapter 12. Introduction to service assets


• Chapter 13. Producing service assets


• Chapter 14. Consuming service assets


• Chapter 15. Managing service assets

Part 4. Patterns

• Chapter 16. Introduction to patterns


• Chapter 17. Produce: model-to-text pattern implementations


• Chapter 18. Produce: model to model


• Chapter 19. Produce: packaging for deployment


• Chapter 20. Consuming pattern implementations


• Chapter 21. Managing pattern implementation assets

Part 5. Appendixes

• Appendix A. Rational Asset Manager: installation and administration


• Appendix B. Integrating Asset-Based Development into a process


• Appendix C. Additional material

The value and use of Rational Data Architect in SOA

The IBM Information management yesterday announced that the paper "The value and use of Rational Data Architect in SOA" was published today as part of the series "The Information perspective of SOA design"

Here is the abstract from that paper:

Discover how you can use the IBM® Rational® Data Architect, IBM Industry Models and the unified metadata management of IBM Information Server to align process, service, and data models. Use these tools to accelerate your SOA project. The fifth part of "The information perspective of SOA design" series describes the key features of the products that support the data modeling pattern in SOA.

Pattern (reusable) assets classification

Reusable software assets represent significant IP in terms of lessons learned from previous engagements and can to address both functional and non-functional requirement (e.g. a performance non-functional requirement could be addressed using the requester side caching pattern asset). However, because assets are not currently cataloged against meaningful criteria, such as functional and or non-functional requirement, they are often not leveraged or reused effectively by architects to help make more consistent architectural decisions.

The importance of Architecture in an SOA can not be overstated. Yet when it comes to making architectural decisions in our software labs or on engagements there is often no consistency, tractability or accountability in terms of the decisions made. These architectural decisions are driven by non-functional requirements (e.g. performance, transactionality, tractability, scalability, etc).

Assets such as software patterns assets are often represented by many assets such as a pattern specification and/or pattern implementations and these assets are often hard to locate because of this lack of consistent and meaningful cataloging. Also the knowledge and use of a asset, such as an industry model asset is often local to a particular practitioner or architect. This leads us to a situation both in software development labs and more importantly on field engagement where is no consistency way of consuming assets and leveraging lessons learned to achieving architectural consistency traceability and accountability.

Below is a meta model that shows how reusable assets can be used to create a solution and goes into more detail and classification around a particular type of reusable asset: the software pattern reusable asset.