Enabling Agility through Asset Reuse
petereeles 120000BW4X Visits (1508)
I’ve been working with a few organizations recently that, as part of their agile transformation, have placed a renewed emphasis on asset reuse. After all, a reuse vision is nicely aligned with that of agile, in that it promises:
On that last point, I find it surprising that some organizations treat the number of “assets” in their library as a key measure of success, when many of these assets haven’t been reused (and some haven’t even been used!). This reminds me of one of my favorite quotes (that always comes out when I discuss reuse): No amount of tool support will help you find treasure in a junkyard
The point is that assets need to be high value and any measure of success needs to be carefully considered. I’m personally a fan of harvesting assets based on a concrete implementation, which is very much aligned with the philosophy of refactoring found in many agile approaches.
While reuse is a big topic, a cornerstone of any approach is the manner in which assets are classified. I touched on this in this paper where I considered different types of architecture asset, such as design patterns and reference architectures. Asset classification is fundamental because it’s the basis by which assets are stored and located. There’s no point in having an asset library if nobody can find anything! The reason for mentioning this topic further is that almost all of the organizations I’ve been working with recently have struggled, to a lesser or greater extent, with the attributes that they might use to store and locate an asset. To cut a long story short, assets need to be located in a variety of ways. Someone searching for a “payment service” asset might find this by looking for finance services, and another might find the same asset by looking for SOA assets. And both are equally valid.
While there may be some primary asset classification scheme, the obvious answer is to ensure that assets are tagged appropriately, where the tags themselves conform to an agreed-upon organizational standard and can be used to search for an asset. For example, the “payment service” may have tags of finance, soa, service and payment. I’m sure you get the point. And so the point of this blog entry is to share some ideas for attributes that you might consider when classifying assets.
A basic set of attributes that are relevant to any asset includes:
Attributes that result from the use of the asset include:
Attributes related to the context within which the asset is applied include:
In addition, there is a variety of non-functional properties that may be associated with the asset such as cost, performance, scalability and the like.
Reusable Asset SpecificationAs has been discussed, underpinning any reuse initiative is a means of describing reusable assets. This is where the Reusable Asset Specification (RAS) comes in. This is an OMG standard that fundamentally defines two aspects of a reuse strategy. The first is a standard for describing a reusable asset. The second is a standard that defines an interface to a RAS-compliant repository (referred to as a RAS Repository Service). Any organization wanting to be consistent in their handling of reusable assets would do well to look at the RAS and reuse repositories that implement this standard.