Just Enough Metadata to Make an Asset Useful

February 24, 2009

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.


Advertisements

6 Responses to “Just Enough Metadata to Make an Asset Useful”

  1. Matt Vestal Says:

    In the repositories I have helped organize and maintain, it has also been a point of contention for when to use asset types versus category schemas. Do you have any tips for that?

  2. Carlos Says:

    It likely depends on the abilities within the tools you are using as a definitive software library. You want to be sure you can still trigger reviews with either approach. You also should consider usability. I have seen the use categories in order to reduce the number of asset types available to improve usability when submitting an asset. The trade-off is you might force or require that categories be assigned on asset submission so that you can trigger the right review process for the asset being submitted.

    The other trade-off to consider is will end users know which is the right asset type to select because the asset type has been abstracted too much. For example imagine you had assets like Redbooks, whitepapers, user guides, proposals. You could abstract an asset type called “document” and force a category be set called “document type” The question is do you think your users will know how their assets map to this abstract asset type called “document”

  3. Thomas Wood Says:

    carlos
    It would be useful to have Asset Attributes be options or radio button selected. That way the descriptions becomes more consistent than the current free field. This will also help with the overuse of categories for keeping statistics, like outages for a Application asset type:

    for example we have:

    Outages/
    January/
    1
    2
    ….
    >10
    February/
    1
    2
    ….
    >10
    Thomas

  4. Carlos Says:

    Hi Thomas, In RAM v7.1.1 we have added new attributes that help with this. Number 2 I this is what you are asking for.

    1. Date attribute you can set constraints on min and max allowable dates and it includes a date picker.
    2. Text attribute now allows you to specify multiple values to be selected from.
    3. Boolean
    4. Number with min and max allowable values
    5. XML which I will shortly be doing a posting on.
    6. URL.

  5. Thomas Wood Says:

    Carlos
    Another question I am being asked a lot about is around the Governance of the Category Schema. So if a Business Line creates a Category Schema around the function of their business, can a review process be created around additions and deletions to this category schema.

    Same would apply to a Vendor Category, when new vendors are accepted by a company, can there be governance around the addition.

    thanks
    thomas wood

    • Carlos Says:

      Hi Thomas, This is something we have had others ask about. It is possible to govern all aspects of the governance model like categories, asset types, policies etc. You can imagine someone definitely wanting to version and review each of these. In the short term here is what you can do. Export an asset library with your entire governance model or just portions of it like categories. Assume you export just categories for now. You create an asset type called category schema and submit these asset libraries as an asset. Version it the same version as the asset library version exported from the repository. You could apply policies or review process to the asset type called category schema. Hope this helps. The next release is looking great we just made M3 available. We made some great usability improvements to submitting assets. I think your teams will like it.

      Best regards,
      Carlos


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: