The AssetMap – Useful Resource

September 12, 2009

Often times, developers and technical leads don’t know what reusable assets are already available. In the same vein, they may not be aware of what is already being planned – either refactorings on an existing asset or an entirely new one in keeping with your overall vision. Recognition is much easier than recall and one tool that I have successfully used in the past is the AssetMap. It is a concise artifact that is made up of two pages – one page with technical assets and another with business ones.

Where do you use this artifact? Fill it up and customize per your team’s needs and distribute it to your teams. Make sure every developer, technical lead, and designer has it. Print out and give it to your new hires as well! More importantly, ensure that they are aware the purpose behind the artifact and use it to implement user stories/business requirements. You can also place it as a document on the Intranet with links to individual asset details. The intent is to have the AssetMap as the summary artifact and not contain every bit of detail about every asset.

Here are the typical business assets that you can place in the AssetMap:assetmap

  • Data Assets (core data entities such as customer, account, product, etc. as well as reference data such as currencies/country codes/zip codes etc.)
  • Business Assets (business orchestration services, task services,
  • Decision Assets (including rulesets, eligibility criteria, policies)
  • Legacy Assets (capabilities in legacy systems that are reusable or have reuse potential)
  • Business Workflows (approval chains, human/system workflow that can be reused in more complex flows)

and some candidate technical assets:

  • authentication/authorization
  • localization
  • legacy integration (e.g. service adapters when invoking CICS modules)
  • reliable messaging
  • event processing
  • testing utilities
  • data transformation
  • routing
  • auditing
  • monitoring
  • notification (to send email messages for example)
  • logging
  • error handling
  • data binding

The above list isn’t exhaustive and is meant to be a starting point for your teams. Here is a candidate AssetMap template that I have used in the past – feel free to customize it to suit your needs. For instance, you could add notations to indicate asset type (whether it is a service, library, component, UML diagram etc.) and readiness (deployed, being developed, needs bug fixes, etc.).

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :


Decouple App Specific and App Agnostic Logic

August 1, 2009

Your application typically consists of a variety of functionality – user interface components, business logic components including domain assets, business rules, and services, backend assets such as legacy components, packaged systems etc. If you tie your assets too specific to an application it will severely inhibit reuse.  Application agnostic logic should be built as reusable assets. If they aren’t, plan to refactor so they are reusable.

Business tier assets could be a combination of objects and services. Your SOA efforts need to be brought into the picture here so you can leverage existing services for fulfilling application functionality. Enterprise data can be decoupled from your application either via a data access layer or a data services layer or a combination of both. Business rules can be encapsulated using Classes via the Strategy pattern or via a declarative rules engine. Either way you should ensure that most of your rules are standalone units of logic that taken a bunch of inputs and return a result. That way they are not specific to a single application. External system integrations should be encapsulated as well including connectivity, data transformations, target specific data values, and error handling. Equally important is handling exceptions in a consistent way across your application.

The idea is to reduce coupling between application specific logic and application agnostic ones. This will help you reuse technology assets in new and unexpected ways! This in fact is a foundational idea of Software Product Lines.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :