Asset Customization and Reuse – Balancing Flexility and Complexity
When we consider a reusable asset – the net can be cast quite wide. Almost anything could be a reusable asset. For instance, a reusable asset could be a:
- Best Practices document
- Design document
- Pattern specification such as Enterprise patterns, GoF patterns, IBM Patterns for e-
- Pattern Implementation
- Code Sample
With so many choices for creating a reusable asset – where should we make our investments? Should we invest in any and every opportunity for creating a reusable asset? No, of course not, the obvious answer is that we have to be selective. We have limited time, money and we need to focus on delivering software solutions – not just reusable assets.
So we need to be more selective – but how do we choose which assets to invest in? What criteria should we use? We can start with some general criteria:
- What is the impact for each reuse of the asset?
- How many times will the asset be reused?
- What is the cost to create the asset?
While this provides a good starting point – its rather simplistic – and assumes that all types of reusable assets are the same. We’ve already talked about different reuse styles – and as expected, this also has an impact on our investment decisions.
So let’s add some more criteria to our decision making list:
- How much customization is required per reuse of the asset?
- What is the cost to customize per reuse of the asset?
- How consumable is the asset?
This adds an interesting and often overlooked dimension to the asset creation discussion. When creating an asset we need to consider the consumability of the asset. Customization of the asset not only adds time and cost to the reuse scenario, but also introduces additional friction into the reuse effort. This friction, where the end user not only needs to understand the asset, but now also needs to customize the asset increases the risk that the asset will not be reused.
We end up needing to find the right balance between fit to purpose and the cost to reach that point. Some assets cost little to customize as they provide little support for customization. However, the user essentially has to use the asset as-is. Other assets can be highly customized – they can be made to fit a wide range of situations. We are provided with a great amount of flexibility in how we reuse the asset. But that increases the cost of reuse – and also often leaves the user confused about the “right” way to use the asset.
Written documentation – whether it is best practices, designs or pattern specifications – fall to the high end of the customization cost spectrum. These types of assets place a high burden on the asset consumer and cost the most to customize as they are applied.
Libraries fall on the other end of the spectrum, with almost no customization per reuse. Frameworks fall in the middle of the spectrum. Pattern implementations, such as those built using JET, fall in-between libraries and frameworks. They are provide points of variability – ways in which we can tweak the pattern as it is applied. This allows us to customize the reuse – yet as the asset support customization and guides the user in the customization effort cost is minimized and flexibility is optimized.
What kinds of assets do you use within your organization? What criteria do you use when creating reusable assets? Are you finding the right balance between customization and flexibility?