Design and Process Criteria for Investment in a Reusable Asset

October 29, 2009

Making the right decisions in the middle of an iteration or release cycle is risky and needs good judgment. Investing in a reusable asset is no exception.

What can help you take decisions on whether it is worth investing the time and effort for making a software capability reusable? The single most important factor is business relevance. Is the capability a priority for your business? Even if it is not a priority, is it one for the medium or long term? If the answer to these questions is no, you shouldn’t invest valuable resources into making your capability reusable. Yes, if it isn’t relevant, it needn’t be reusable. Assuming a capability is business relevant, there are several considerations you can think about:

Design Considerations:

  1. Do you have user stories that either directly or indirectly requires this capability? For instance, if you have a login customer user story, and you don’t have a customer component, this is an opportunity to create one. In the same vein, the login customer story itself might have variations. What are the different kinds of login that you need to support? Username/password, username/password/special verification text, email/password, username/random set of questions, username/defined set of questions etc.
  2. Do you understand the extent of variability that is required for the asset? Consider the ratio of the features that vary a lot vs. the overall functionality.  Even if you end up with a gross, high-level percentage it will help you during design.
  3. Consider specifically the aspects that vary and the number of variations you need to support. This is very critical to plan for the reusable asset. Remember, you are pursuing iteration not perfection! Draw a distinction between the variations that are an absolute must vs. ones that can be built over time. If you look back at the first point, maybe your business only needs the simple login using username and password. In that case don’t rush into building in variation support. On the other hand, if they come back and ask for multiple kinds of login you can always refactor to support variability.

Process Considerations

  1. Will the capability add significant schedule or technical risks? If so, you need to make this transparent and get clarity from your sponsors. You can explain the rationale for investing in a reusable capability if there is business relevance. Similarly, if schedule risk is unacceptable or you have other higher priority assets to build, refactor, etc. then add this asset to the refactoring list and revisit later.
  2. Will the capability introduce deployment changes? Does it need an additional resource such as a database, a configuration file, or is dependent on an external service provider? In that case you will want to run it by your production support and operations partners and get their buy-in.

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

tweet this add to del.icio.us post to facebook


Create interfaces from a product line context

October 20, 2009

If you ask developers about interfaces they typically build you will hear some form of create, read, update, and delete (CRUD). CRUD-type interfaces are simple to understand and are intuitive. They tend to be used heavily in the data access layer operating on your various data entities. At a high level these interfaces seem to meet your product line needs. This may not always be the case though! Why do I say this? The interfaces you create for a product line depends on the variations you need to support and manage. Variations will require interfaces that vary in granularity. Some operations might operate on a data entity while others might operate on an aggregate. Still others might operate at a subset of a data entity. For example, say you develop solutions for the banking product line where in you have an online portal, mobile bank, and branch services. All these products in your product line might support money transfer. Online portal might display a complete set of from and to accounts while mobile might display only a primary account. Branch might provide only accounts eligible when initiated by a branch. To address the variations you have to go beyond just getting the right set of accounts and have a reusable asset use a mechanism to access and execute business rules.

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

tweet this add to del.icio.us post to facebook


Software Reuse Quick Tip #20

October 18, 2009

Tip #20 – Minimize channel specific dependencies and behavior

If you want to build assets that are reusable across distribution channels you should encapsulate channel specific data attributes and behavior from the rest of the logic. Often times I have built assets without taking this into consideration and have gone back and refactored the channel logic out of the domain components. If you know that an asset is going to be offered via multiple channels you can certainly take it into account earlier. How will know this? The first place to look will be your systematic reuse roadmap. Is your business planning to offer a capability in a new distribution channel such as interactive voice response or for mobile/iPhone users? Even if it’s too late for the current iteration you always add it to the list of planned refactorings.

Below are examples of channel specific couplings and suggested design alternatives:

Channel Coupling Example Suggested design alternative
Online Portal (Self-Service) Your asset assumes that the caller will provide a certain input identifier always. E.g. login user name Define an enumeration to support login user name and other kinds of identifiers as input. E.g. your interactive voice response might use social security number as input while your call center might use a customer identifier instead.
Your asset assumes that the caller will only want a subset of data.
E.g. asset only provides name and address data for a customer
Offer multiple flavors of data objects. Based on channel’s preferences a particular flavor can be returned. E.g. Online portal could use a full customer profile while a call center could use a partial customer profile with certain data attributes masked for privacy.
Branch Your asset assumes that the caller will be invoking from a particular technology platform that is specific to the branch. E.g. the asset takes a workstation identifier as input. If you must capture workstation identifier put it as an optional parameter or a generic name/value pair type data structure.

This list is just an example and obviously your environment might contain additional channels and different types of channel couplings. As with everything else, you don’t need to rush into fixing them. If a user story requires an asset that has a certain coupling, you can refactor just in time.

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

tweet this add to del.icio.us post to facebook


Systematic Reuse Success Factor #4 – Domain Context

October 10, 2009

There isn’t one right way to build reusable software assets. Your business goals, technical environment, iteration and release plans all contribute to both the timing and nature of design decisions. Refactoring existing code to meet business goals is also context driven. Consider:

  1. What product features typically go together?building blocks
  2. Do certain features vary more than others across products?
  3. Is it possible to vary a product feature at runtime or design-time?

All these questions guide design. For instance, if the goal is to support variability at runtime you could support adding new parameters and changing existing ones without code changes or application restarts. As you work on design, keep your domain relevant variations at the back of mind!

Take an example of a widget shop that needs to market its widgets. The user story is to produce different marketing labels based on widget type. There could be several variations to support – frequency of changes to label information, number of words, language, data formatting, mixture of static and dynamic messages that make up a label etc.

Depending on the complexity of your domain, the features could vary simultaneously or in isolation. Consider some of these variations and their impact on design.

#1 Label contents are only static content – you could use a single LabelGenerator using a file configuration.

#2 Label contents are a mixture of static and dynamic content – LabelGenerator now needs two sub-components – a StaticContentGenerator and a DynamicContentGenerator.

#3 Label contents are a mixture of static and dynamic content. Static content is multi-lingual. – In addition to the content generators you need an internationalization component that can support multiple languages

#4 Label contents are a mixture of static and dynamic content. Static content is multi-lingual. Date and currency formatting varies based on country – All components of #3 plus a DateFormatter and CurrencyFormatter based on locale.

Next time you start a project, understand more about the drivers for change in your problem domain. Your domain and the associated context should drive reuse. The more you understand the drivers the easier it is to decide what and how your software assets need to be reusable.

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! : :


%d bloggers like this: