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