Software Reuse Quick Tip #11

May 28, 2009

Tip #11 Document Capabilities as well as limitations of reusable software assets

When documenting a reusable software asset donot only capture only capabilities. Be sure to document limitations as well. This is important because limitations directly influence refactoring work. When trying to match a user story with an existing asset the limitations will determine the extent to which you need to update the existing code in order to implement the story. Limitations are not a bad thing per se especially since you want to prioritize overcoming them within the context of a real user need. This exercise is made a lot easier when you capture the limitations ahead of time – this way you don’t have to review your code or ask several developers in order to come up with the refactorings needed.

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


Reuse services in multiple business processes

May 17, 2009

When you build services always do so with the intent of integrating them with more than one business process. Why is this important? Several reasons:

  • Services are the building blocks of automating business processes – if the services aren’t reusable they cannot be used across processessvc_across_biz_processes
  • Services need to provide abstraction to complex technical structures/implementations. You don’t want to solve the same abstraction twice across business processes.
  • Helps you build new business process automation solutions faster. If the service is devoid of process-specific couplings it can be used in multiple projects. Here are some examples of process-specific couplings: designing a service to work with a particular user population, placing workflow/routing logic within a data service, placing complex business rules within service logic, assuming a service will only get accessed via a particular sales channel etc.
  • Enterprise data services – also known as entity services – should be properly encapsulated, abstracted, and hosted in a scalable environment to facilitate reuse across multiple business processes.

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


Reusable asset design – pursue iteration, not perfection

May 14, 2009

You want to make sure that you don’t spend an enormous time trying to build the perfect reusable asset. Be it a component, library, or service. Regardless of what you are trying to do accept that you won’t be perfect from the get-go. Instead design for reuse iteratively. In earlier posts I blogged about delaying commitment and gave an example of an iterative way to build a reusable asset.

Iterative design is needed to not only deliver incremental functionality over time but it is also a handy technique to address a key risk with systematic reuse – schedule risk. In a typical enterprise project there are a lot of moving parts – there are multiple stakeholders to satisfy, several teams including infrastructure, operations, production support staff to co-ordinate with, and ensure legacy systems and processes will not be negatively impacted. Given that most projects are delayed you don’t want a reusable asset to make matters worse. Designing for reuse is often mistaken for making software that is too generic or abstract. It becomes easy to slip into philosophical arguments about levels of abstractions and layers of indirection.  It is tempting to lose sight of the business problem and pursue perfection for the sake of technical elegance.

Here are some warning signs that you need to watch out for:

  • Your developers are debating endlessly about a possible future use case that a component or service needs to support at the expense of what is currently known and required
  • More meetings are being setup to design the ‘right’ interface to make sure you are guarded against future changes to a service or componentconflict
  • You seem to be bogged down trying to figure out whether or not to support variation for a particular product feature.
  • Your developers are working on designing a business component that has no traceability with what your business user wants
  • There are endless discussions about whether or not a piece of functionality needs to be made reusable

When you smell this sort of behavior, you want to pause, look back, and refocus on the deliverable at hand. Pursue iteration, not perfection.

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


Being consistent is more important than following a standard

May 13, 2009

When building software components and services for reuse across applications it is more important to strive for consistency rather than to comply with a standard. Why do I say that? Because you can always switch your implementation to be standards compliant. If a bulk of your applications use a particular reusable component you can always treat the existing interface as an adapter that in turns invokes a industry standard API behind the scenes. Note however I am not advocating blindly creating wrappers for components for which mature standards already exist (e.g. If you are trying to use a logging API for java you should evaluate Log4j instead of building a new logging implementation).

This is specifically related to horizontal business capabilities that you want to reuse. For instance, say you need the ability to process credit card payments from several applications and there wasn’t an industry standard at the time you needed this functionality. It is important to have a payment API that your apps utilize rather than wait for a standard to magically appear. Day two, if and when a standard appears you can change the existing implementation without any impact to your existing applications. Okay I am oversimplifying – you might need minor code changes and regression testing. But the bottom line is that you will be in a significantly better position rather than having to change code across your codebase.

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


Have a plan for every reusable software asset

May 10, 2009

Have a plan for every reusable asset. At a minimum the plan needs to address:plan

  1. The scope of the asset’s functionality for your immediate deliverable
  2. The asset’s place in within your product line
  3. The impact to your existing design and overall architecture
  4. Tentative road-map for evolving the reusable asset over several iterations or releases

You don’t have to get answers for all these areas rightaway! The point is to think about them so you can make decisions on scope and effort. In the midst of an iteration there will be several questions about whether or not to invest time in refactoring or developing a feature. You can use this tiny list as a guide to help you make decisions on what to refactor or build and whether or not it is in line with your overall strategy.

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


Risks with software reuse

May 7, 2009

Why should you care about risks with reuse? Because, these risks are real not made up and can make the difference between success and failure for your development effort. Here are a few risks that spring to mind:

  • Needless complexity
  • Inflexible design/will cost too much to modify
  • Domain irrelevance
  • Inadequate documentation/training/awareness
  • Ability to meet deadlines/dates (schedule risk)
  • Increased development, testing, and maintenance costs
  • Pursuit of technical elegance/architectural purity

These are not all the risks with reuse but the major ones that I have come across.

Now, what do you with these? You do what leaders do and that is address them head on. Instead of sulking about these you should plan and execute mitigation steps for these. Refactoring is the fundamental technique for addressing these risks! Take another look at the above list. You can use refactoring to handle most of these if not all of them.

  • Needless complexity – build only what you absolutely need with just enough abstraction. Refactor needless layers and abstractions. Keep things as simple as possible.
  • Inflexible design/will cost too much to modify – refactor your design to focus flexibility on the variations inherent in your problem domain. Not everything needs to be flexible!
  • Domain irrelevance – Build only what is relevant to your domain. If you are not sure, don’t commit prematurely.
  • Ability to meet deadlines/dates (schedule risk) – cannot take a reusable asset to the planned design target? Plan to pursue refactoring these in your future iterations
  • Increased development, testing, and maintenance costs – don’t build domain irrelevant reusable assets. Every asset you build should be for a real business need. Refactor the rest so as to leverage existing solutions – watch your costs go way down.
  • Pursuit of technical elegance/architectural purity – again, refactor imperfections over time. Think incremental and iterative.

I am not saying this will solve all your problems and address all the risks. But, it will get you on the right path. If you step back and focus on what is essential and what you know is likely to vary you can adjust your efforts accordingly.

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


Software Reuse Quick Tip #9

April 30, 2009

Tip #9 Create reusable scripts to achieve continuous integration
You can create reusable scripts for compiling, executing, and reporting all your unit and regression tests. This is applicable whether you are building components or services or even business process flows within the context of a SOA architecture. The next logical thing to do would be to integrate these scripts with a continuous integration suite. Below is a presentation on achieving continuous integration using a reusable set of scripts. Although this presentation is for a Service Oriented Architecture (SOA) platform based on the Tibco suite the reusable scripts can be leveraged for many other projects.

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: