In a hurry to decide if something is reusable?

August 15, 2010

I have heard some variation of the following line from developers, technical leads, and architects – “we want to make things more reusable, but we don’t have the time.”

There is always a deadline (or many deadlines) to meet and technical debt to accumulate. Since we are always in a hurry, it helps to be aware of what should be reusable – even if we won’t get to it in this iteration . So here are some ideas that can help you decide whether or not a capability should be developed for reuse:

  • is the capability unique to your enterprise? i.e. it captures logic and/or process variations that provide competitive differentiation.
  • is the capability making something incredibly hard/defect prone simpler and/or easier?
  • is there a desire for customers to have a capability across business channels? i.e. from the web, from a mobile device etc.
  • is it specific to your domain and potentially relevant to multiple applications in the domain? this may or may not be obvious – if it isn’t, delay commitment.
  • is the capability only available in a particular technical platform but is solving  an often needed problem?
  • is it automating boiler plate code generation or preventing defects?
  • is there an in-house/external alternative that achieves your functional requirements? if so, seriously consider stopping investment in the asset.

This is a starter list – the idea that we keep coming back to is this – treat a reusable asset like a real investment. Every iteration and release is an opportunity to review and update the investment. When you make a decision, continuously refactor to make the capabilities less app specific and reusable.

Co-evolve Data and Data Management Assets

November 12, 2009

When you get a business need to expose a piece of data, build the necessary asset that will assist in data integration and consumption. Data integration can be accomplished in many ways – by exposing a web service interface, via an object library, message publications, ETL, or by sending file extracts. What would be an option that will be a prudent investment for your firm? Do you envision multiple applications and/or processes to consume this piece of data in real-time?

Data management interfaces typically consist of create/read/update/delete operations and additional functionality (e.g. transformation, search, enrichment, encryption, etc.). If you get a requirement to expose customer data for a project, you can provide a Customer interface that supports a getCustomer() function. If applications/processes need to get access to this data from varying platforms, you can expose this as a web service. If it is required within a single platform, you can expose it as a library (JAR or DLL for instance). The important thing is to resist placing data management logic alongside consuming application code. Every consumer would have to implement the similar code and you will add operational complexity every time you need to modify data structures or upgrade versions.  The library or web service can encapsulate most of the data logic and leave the consumer with what they really want – an easy way to get and update business data.

The data management interface could also support additional operations but you don’t have to build them immediately. Over time, you can enhance this interface to offer additional functionality.

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

tweet this add to post to facebook

Every Asset Isn’t Reusable

July 28, 2009

Every software asset in your application, product line, or codebase isn’t going to be reusable. In fact if you are trying to make everything reusable there is a good chance that you are introducing needless complexity into the design. Recognize that there are areas where reusable assets are going to be a natural fit and areas where they won’t be. You might be uniquetempted to make things reusable just in case you need them in another project or application. Pause and reflect at such points because hindsight is 20-20 and you might get better at discerning what is and isn’t reusable over several iterations of a system. There are always going to be assets that don’t fit well together or have neatly packaged interfaces and that is okay!

There are areas where it makes sense to build, adapt/refactor, and maintain reusable assets. For instance – connectivity components, domain specific data and business logic such as data services, business services, model classes/repositories, infrastructural components and utilities are all classic areas for reuse.

Ask hard questions if you are unable to make up your mind. If nothing else always ask if there is business relevance to the asset and if the asset’s functionality varies based on sales channel/user/time/business policies/rules etc. If the answer is no, you probably don’t need to invest efforts in making the asset reusable. At least not right away.

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

add to Digg it : post to facebook: Stumble It! : :

%d bloggers like this: