When customer who are new to managing their assets get started they often fall into 2 camps.  Those that don’t provide any guidance or strategic direction or those that provide too much strategic “direction”  The emphasis here is on the word direction.    To be successful with managing your assets you need both a top down and bottom up approach.  Neither one should overpower the other.  In this post, I describe some tips for ensuring the right meta data is provided for making assets useful and what the responsibilities are of both those that are leading the asset management initiative and those teams that are using it.

Tip –   Don’t over burden teams with too much governance initially.

Focus on what the key assets are within your organization that you want to manage and provide value.  For each of those assets define how you would like to:

  1. Organize them  –  What categories will be the ones that most teams will search for these assets.   What reports will teams likely want to run.  Often reports require that certain categories exist to make it possible to run the reports.
  2. Govern –  Select the appropriate level of governance for each type of asset you want to manage.   In some cases initially it may be appropriate to not require a lot of governance.  Governance can initially be requiring a category be set like what language the asset is for or technology it applies to.   It might be a required attribute like who the dev support contact is.    It might be a review process with a review board or an automated policy that checks the asset for compliance with corporate policies.    Don’t go overboard with requiring all of these on every asset.  Keep in mind the tradeoff’s in the amount of time it takes to submit an asset versus the added benefit of that governance.  Some users will instead say forget it, after they set the 20th required attribute to get their asset submitted.
  3. Provide automation guidance like the ability to batch load or maintain asset submissions or modifications.

Tip –   Establish an asset architecture  board to listen to the asset consumers and producers using the repository.

Asset architecture boards are in place to coalesce requirement for and achieve consensus for defining asset governance.   The asset governance needs to reflect the needs of the organization using the assets.   Without some kind of structure teams won’t know what assets to submit or won’t submit an asset because the asset types don’t exist or categories don’t exist.   Provide a way teams can suggest asset types, categories, attributes and asset governance suggestions right from the repository tool.  The opposite is also true.  Sometimes someone won’t submit an asset because it requires 30 minutes to get all the required meta data on the asset before it will even successfully submit to the repository.

Tip – Use the right meta data for the job!

I often see customers struggle with how and when to use  each of the following:

  • Categories
  • Asset relationships
  • Asset attributes
  • User tags
  • Asset version
  • Community definition

Here are some tips for when to use each of these.

When to Use Categories

Categories are useful for allowing people to find assets.  When defining categories think about how people will want to find an asset.  Examples could be, geography, organization, Language, Platform, Technology, Industry,  Asset lifecycle state (proposed, under development, beta, available, sunsetting) Plan Calendar (2008, 2009 etc)

Categories are useful for triggering review or defining who has access privelages to an asset.

Categories are useful for running reports.  In particular when you want to run planning reports to see which assets will be in compliance by what versions and or time line q1, q2, 2009 etc.   You therefore will not only want to have products and versions as asset types but you will also want to create categories out of those assets to so that you can run reports on them.

When to Use Asset Relationships

Asset relationships are useful for determining what other assets are related to an asset.  Asset relationships make it easier to find and download all the related assets a person needs to accomplish a task.  For example customers often have a recipe or enterprise technical or reference architecture that pulls in several other related assets via asset relationships.  In some cases when creating an asset relationship consider for example if that asset can be related to one specific asset version or a range of asset versions.  Encourage teams to specify a range when appropriate.  For example a “document of understanding agreement” may apply or be related to versions 1 to 4 of a product or component.

When to Use Asset Attributes

Asset attributes are useful for describing key asset capabilities or characteristics.  That are important for finding or using the asset.    Attributes can be searched on uniquely.  For example don’t just find me “john”  but instead find me all asset’s that have an attribute that are are “supported by” John.

When to Use Tags

User tags are useful for uniquely naming assets that you as an individual user want to uniquely identify so that you can quickly find them again or so that you can group together into a set that you can then share with someone else.    If you find people are creating the same tags on multiple assets it may indicate that your category schema is weak and needs to be improved to reflect that tag.

How to use Asset Version?

It often only becomes obvious why an asset version is important when you create your second version of a published asset.  Being able to keep track and quickly get to the previous, next and latest version of an asset become very important as you get more assets.   RAM provides the ability to version assets and leverage SCM systems to version artifacts.  By not specifying the version of the asset in an asset URL you are automatically shown the latest version of the asset.   Asset versions should reflect the actual published version of the asset.  For example when I create an asset representing the product RAM, I don’t set the version to version 1 because it is the first time the asset is put in RAM. I set the version to RAM v7.1 which reflects the actual version.    Also when I create a new version of this asset for example RAM v7.1.1, I don’t create it by submitting a new asset because the relationship to the previous asset version will lost.   I wouldn’t call this asset version 2.   I would instead go to the RAM v7.1 asset and select create new asset version and enter RAM v7.1.1 in the new asset version.  This has several advantages, it ensures linkages between previous and next asset versions are automatically maintained and navigable.  It also ensures that all the appropriate asset metadata and relationships are persisted making it easier to update the asset with fewer modifications.  Using this technique you will find yourself discovering assets much more quickly in your repository.

When to use Communities?

Communities allow you to specify an area where a set of users with specific, roles, accesses, permissions, categories and attributes for that specific community can collaborate and share assets.    Consider having a high value asset community in cases where assets must be carefully controlled.  Consider having the junk yard community in cases where there is no governance and teams can experiment.  Consider having a getting started community where teams can learn about using the Asset repository.   Communities are often created for a specific line of business or project,  common roles of teams that want to share similar assets for that role or other domain area.

RAM provides the tools necessary to implement all of the above tips and techniques.  You should ensure your asset management tools have these capabilities if you want to be successful in managing and reusing your assets for business benefit.


Check out this tutorial on developerWorks Exchange I put together for using BIRT to create a report for download and artifact browse activity for a specific community.

As always, please comment on the sample reports you would like to see, or share your reports on developerWorks Exchange.

Currently there are several steps and clicks to submit an asset, but we have received many requests to simplify the process so that a user will be able to submit an asset with a couple of clicks.  While we’re tossing around a few different ideas, one that has consistently come up is using templates.

Tentatively, the user would select something at the beginning of the Submit Wizard that would populate selections for Community, Asset Type, Categorizations, etc.  This would save users time since they would not have to go through and do all of those selections every single time.  There would also be a way to create these templates somewhere in the product.

Another idea is to have suggestions in the combo boxes for Community, Asset Type, Etc.  Here we would figure out which selections someone uses the most and move them to the top of list so that users do not have to scroll through the entire list to find his or her selection.

What are your thoughts about these ideas?  Would either save you time and simplify submitting assets?  Or is it just putting a bandage on the problem?  Please answer the poll below or leave thoughts in the comments.

As Cloud Computing takes off customers are struggling contain the proliferation of 100s of similar virtual images or appliances.   Here is an interesting article excerpt from  Reuters Report. It describes how application architectures need to consider virutalization and that there will be “virtualization Sprawl” from the proliferation of images.

“The flip side of the coin is that rapid application provisioning and delivery can create new costs and risks. Reducing the friction from application deployment will likely increase pressures on new application deployment and demand. The well-known real-world equivalent is known as “server sprawl.” The analog in the VM world will be known as “VM sprawl.” The consequence presents a plenitude of unknowns. Organizations must recognize that they not only may be exchanging one
cost and management style for another, but that as physical machines are turned into virtual machines, virtual sprawl is likely to outstrip physical sprawl. Moreover, how VM sprawl acts on the network, storage, I/O and compute power across a network of server nodes, and in an increasingly dynamic model of services, will be a complex multivariant problem.”

This RAM Webcast Demonstration shows how RAM was used to manage virtual appliances.  By making it easier for teams to find existing images that meet their needs therefore avoiding duplication.  Also by providing the necessary governance to ensure that virtual appliances are within compliance.   In this demonstration you can see how teams collaborate to find and share assets using Rational Asset Managers Web 2.0 capabilities.

RAM v7.1.1 is able to be customized to automatically capture metadata from standards based files like the OVF file format shown in this demonstration.  Which reduces the amount of time it takes to submit assets but also reduces errors in entering metadata by hand when submitting assets.   You can learn more about the OVF standard here.  You can learn more about Rational Asset Manager here.

RAM can also manage the business process assets, services and applications that are related to or installed on or used by these Virtual Appliances.