Introduction

For several reasons, businesses naturally want to reuse code or software artifacts. Reuse can save development time and money, lower risks, and provide better quality control. It can be difficult, however, to know how to reuse code or software (such as design artifacts or delivery accelerators). In general, we define reusable software pieces as assets. Sometimes the cost of reuse is too high compared to the reuse benefits. In this article, learn about a layered model that helps you evaluate the effectiveness of reusing, or adopting, assets.

Back to top

Measuring asset and organization maturity

Before discussing the model, though, this section discusses asset and organization maturity. Asset and organization maturity is the ease with which an asset can be adopted into an organization. The model is for both adoption and reuse. An organization can prepare for future reuse if that mission is promoted and supported.

In this article, the asset/organization maturity is measured by the cost of an asset being adopted into an organization. This cost doesn't refer to building the asset, but to reusing the asset or preparing it for future reuse. If the cost (counted as Person Days, or PD) is low, then the asset has high maturity. If the cost is high, then the asset has relatively low maturity. The cost is correlated to the organization's efficiency, which will change over time. For example, an asset may have higher maturity in an organization if they are familiar with the asset context and technology, or they have a better process. It will be cheaper for this organization to adopt the asset. Initially the asset might have a low maturity, but after several adoptions the organization may enhance the asset materials, become familiar with the asset context and technology, finish the translation of the initial documents, and so on. An increase in the asset/organization maturity will cut the cost for future asset adoption.

Using the adoption cost to assess the asset maturity, the Asset Maturity Model is organized into three layers: the asset itself, the organization, and the asset vs. organization fitness. These three factors will determine costs related to the asset adoption.

An organization may have multiple cost centers. For example, you could have an asset development cost center, an asset adoption cost center, and individual project asset reuse cost centers. To simplify the problem, it is suggested that you separate the cost centers in your organization and consider them separately. This article mainly focuses on the asset adoption cost center.

For some existing maturity models, such as the CMMI from SEI, or the STARS Reuse Maturity Model from Boeing, the asset and organization maturities are assessed separately. (They usually just evaluate organization maturity for generic assets.) But, in real adoption cases, experience has shown that you need to assess the asset and the organization at the same time. Hence, the model in this article considers both the asset itself and the adoption organization.

The ease, or degree of difficulty, in finding or generating opportunities for asset adoption should also be considered in the Asset Maturity Model. This is difficult, though, for quantitative measurement, especially for organizations that are not the asset creators. Since this "ease" correlates to the asset adoption cost, the adoption cost is also used to justify "easiness" in the model.

Back to top

The model

In general, with asset development and adoption projects the common factors to consider are:

• Organization maturity (absolute maturity)
• Asset maturity (absolute maturity)
• Asset versus organization (projects) fitness (relative maturity)

Commonly, the asset reuse may happen in the following scenarios:

1. Asset creator produces the asset and reuses this asset in future projects.
2. Asset creator produces the asset, then asset adopters (second organization) reuse this asset.
3. Asset creator produces the asset, one asset adopter (second organization) adopts (or enhances) this asset and becomes the overall asset promoter and supporter, then asset re-users (third organization) reuse this asset.

Most of the previous models assume that the asset creators (producers) are in the same organization as the asset re-users (adopters). But, this assumption does not hold for the IBM Global Business Solution Center (GBSC), nor for some other software organizations with the mission to promote outside assets to outside teams. On this point our model, as shown in the figure below, is different; an asset vs. organization fitness factor will be very important to asset adoption.

The rest of this article discusses the three tiers of the model, starting at the bottom.

Back to top

Tier 1 - Asset maturity

Asses maturity is the absolute maturity for the asset. When you develop or harvest an asset, the asset itself has a maturity measurement. The measurement comes from:

• Asset documents (user documents).
• Asset nature (such as the technology, asset context, and granularity).
• Asset support materials, including asset promotion, asset adoption, and asset delivery materials.

Since all of these are contained within the asset, by checking the asset itself you can get the measurement of absolute maturity. Asset support is not considered here because support will be part of the organization's function (discussed in the Fitness section).

Asset documents

This is the fundamental layer to assess the asset maturity. Without the necessary documents, people can't understand the asset. Based on the asset nature, the document requirements will be different for adopters. For example, a delivery asset such as scripts, or a testing tool, should have an installation guide and user guide. Typical users should be able to adopt this asset by using those documents.

For a solution building block asset, you would need the architecture related documents, and certain design artifacts, to help the adopters understand the asset context, and to determine how it should be positioned in the overall solution. Only with these types of documents will adopters be able to reuse this asset successfully.

Though different assets have different document requirements, a standardized set of documents should be used as the base for adopters to make the selection. To measure the asset document maturity, one approach is to:

• Define a standardized set of documents (or BOM lists, which include other things such as binary, source, Javadoc and so on).
• Select a subset of the standardized BOM list based on the asset nature (category).
• Score the maturity based on the asset current status.

The IBM GBSC CTE team is using this approach to assess the asset document maturity.

To evaluate maturity, the ultimate measurement is how many PDs it takes for someone to learn and understand the asset by using the documents. Prior to that, another measurement is knowing the percentage of documents that are ready, and how many PDs are needed to prepare the missing documents. In this model, the maturity measurement for adoption is ultimately about the PDs the asset can save. (This is designed to serve the quantitative control purpose described in CMMI phase 4.)

Asset context and granularity

In this second layer of asset maturity, the asset's context information and the granularity are retrieved. If you can’t do this task, then you're in big trouble! The asset is not mature enough for any adoptions.

In general, the more asset context information you have, the better the asset maturity. The higher the granularity, the better the asset maturity. Both context information and granularity can be measured by the PDs required to learn the asset and adopt it from an architecture point of view. (High maturity means low PDs needed for adoption.)

High maturity in this layer is not necessarily good. High granularity with a limited context means this is a very specialized asset, and it may have few chances for reuse. It might also require certain technology skills, and governance in the organization, to perform the adoption. (Kepp reading for more on this in layers five and six.) However, high maturity does mean high feasibility to adopt the asset, if the opportunity is given.

Asset support materials

Many assets don't have this layer at creation time; they just provide the general user documents with some overview introductory materials. The materials do not serve specific purposes. You would have to develop specific materials on top of existing documents to promote, adopt, and deliver the assets.

The IBM GBSC CTE approach currently categorizes three types of materials:

The measurement for this layer is similar to the measurement for the first layer. You want to know the total PDs required for adopters to learn and understand the asset.

Back to top

Tier 2 - Asset versus organization fitness

This tier represents the relative maturity, which depends largely on whether the asset and the organization are a good match. You need to review both sides to assess the adoption effort. The cost measurement comes from:

• Language and locale
• Technology and asset features
• Support and governance

Before starting this evaluation, you need to know the boundaries, or organization, of the organization. This is a difficult task. Usually, you want to separate a big organization into different cells based on the layered model to ensure that each cell has a simple attribute in one layer. For example, if an organization has Japan and US branches, you would want to separate them because the asset adoption cost in the Language/Locale layer will be different in these two branches.

If the organization has multiple cost centers, or has different support models for assets in different divisions, you should separate them when calculating adoption cost. If you want to evaluate the whole organization, you can evaluate each cell and then consider the whole distribution of the maturity. This approach will also be used in the evaluation for Tier 3.

Language/Locale

This is the fourth layer in the model, and is the first thing you should consider in the asset vs. organization fitness. To assess language/locale, you need to examine the language used in the asset documents, the translation effort, the screen/menu globalization (localization) effort, and so on.

If the asset language is Spanish and the adoption organization speaks Italian, the translation effort may be low. If the asset language is Japanese and the adoption organization speaks English, the translation effort will be huge. For this layer, the maturity will also be measured by the translation or globalization cost.

Technology and asset features

This fifth layer in the model explores whether an organization is familiar with certain technology, products, and subject knowledge. If one asset has those technologies, products, and subject knowledge, it will be a smaller effort for the organization to adopt this asset. Otherwise, the organization may need to add training into the adoption cost. Training is generic for those technologies, products, and subject knowledge, which is different from the asset training in layer 3.

For example, the IBM GBSC team has a technical standard for asset development or harvest. In general, the architects and developers are familiar with those technologies listed in the standard (such as SOA related technology, JSF, JPA, and so on). If assets have those technologies, the skills match will save some adoption cost. This also applies to the business know-how, such as banking solution assets for banking project teams. In general, if an organization has the skilled resources, you can consider the organization and the asset a fit. If the organization experiences resource limitations, then the adoption cost should be adjusted to reflect the limitation and the asset versus organization maturity should be lowered.

Support and governance

This is probably the most complex layer in the whole model. You assess the support mechanism and governance for this asset in the organization. Support mechanisms include the cost model, support resources allocation, and support infrastructure. Governance is the organization-defined life cycle for the assets, which may include asset commercialization (IP-protection), asset sunset, SOA governance model for CBS, and so forth.

If the organization has a clearly defined support model and governance (which have close relationships with layers 7 and 8), you use the predefined models to estimate the adoption cost of an asset. The average estimate is based on multiple full life cycle projects. If the organization does not have a predefined support model and governance, then the cost to create those models should be added to the average adoption cost (as the measurement of support and governance maturity). The effort and time you lose in the confusion caused by the missing support model/governance should also be added to the adoption cost.

This layer has a very close relationship with tier 3 because the score card for this layer is actually determined by layers 7 and 8. If the organization has generic predefined support models and governance for all assets, layers 6,7, and 8 will all have a better score.

This layer is in tier 2, and not tier 3, because it also needs to consider the whole asset situation. For example, the GBSC CTE team has a generic predefined support model and asset life cycle. Yet, if one asset hasn't passed the CoO process (a step in IP protection) or the asset commercialization, the adoption cost will be very high. Or, you might not even allow the adoptions. You need to go through the IP protection steps, or the asset commercialization steps, and add that cost to the adoption cost.

Back to top

Tier 3 - Organization maturity

This tier represents the absolute maturity; it assesses the organization’s readiness for asset reuse. The adoption cost measurement comes from:

• Organization setup
• Process definition
• Asset reuse culture and community

Organizational boundaries will be a major concern for this tier. Qualitative measurement is more important than quantitative measurement. The maturity in this tier correlates to the adoption cost addressed in layer 6 of Figure 1.

Organization setup

This seventh layer of the model deals with the different work units of the organization, and each unit’s specified missions, related to asset adoption. Generally, a mature organization should have separate teams for:

• Dedicated asset adoption
• Asset promotion
• Creating or finding project opportunities for the assets
• Asset support

and clearly defined mission statements ready for those work units. A benefit, or incentive, program should be in place to connect all these work units. All of these things will save on the asset adoption cost.

The organization setup also includes the infrastructure setup, such as an asset repository, an asset searching mechanism, an asset code base infrastructure, and so on. If an organization does not have suitable infrastructure, the asset adoption cost will be higher.

If an organization does not have this setup, confusion in the organization may decrease the asset adoption efficiency. However, it is difficult to have a quantitative measure.

Process definition

The process definition layer examines the asset adoption-related processes in the organization. Asset promotion and asset support are in the scope of this layer.

CMMI maturity levels are a good measurement for this layer. For all the measurement details, refer to SEI's CMMI V1R2 document.

Asset reuse culture and community

The last layer in the model. If the formalized setup and well-designed processes for asset adoption are the veins, then the asset reuse culture/community is the capillary. The culture, or community, can provide subject matter knowledge to prepare for future asset adoptions in the organization. It can also improve the skill level of resources, and improve adoption efficiency by pre-testing ideas and processes in the organization.

When designing the community, you don't necessarily have to be within the organization. If employees have connections with outside assets or organizations, they can help the organization receive and distribute the information more efficiently. The organization can also learn about different setups and processes from other organizations.

Back to top

Conclusion

This article introduced an asset/organization maturity model for assessing adoption of assets. Unlike the traditional capability maturity models, this model is used to evaluate the adoption effectiveness (or cost) for a specified asset in an organization. You can use the model as a structured decision framework in general asset adoption cases.

Resources

Learn

• Learn all about Capability Maturity Model® Integration CMMI V1.2 from the Software Engineering Institute.
  
  
• Learn more about the STARS Reuse Maturity Model: Guidelines for Reuse Strategy Formulation.
  
  
• Visit the developerWorks Open source zone for extensive how-to information, tools, and project updates to help you develop with open source technologies and use them with IBM's products.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  

Get products and technologies

• Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
  
  

Discuss

• Check out developerWorks blogs and get involved in the developerWorks community.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Measuring asset and organization maturity
• The model
• Tier 1 - Asset maturity
• Tier 2 - Asset versus organization fitness
• Tier 3 - Organization maturity
• Conclusion
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Rational on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers