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 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 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 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 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 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 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 Digg it : post to facebook: Stumble It! : :

Aligning systematic reuse activities with day to day development

April 25, 2009

Instead of looking at systematic reuse a separate analysis, design, and implementation effort that requires lots of time and resources view it as being part of what you do. Practice a few techniques practicewith every project, every single day. When your development activities are aligned with a systematic reuse roadmap your activities are aligned towards delivering today’s needs and positioning you for the future. Think of this as your team’s practice routine before the game. You won’t win if you don’t practice, would you?

Here are some ideas for aligning reuse efforts as part of your everyday development:

  1. When you review user stories look for patterns and similarities with stories from the past. Or stories from other applications in your team or within your shop
  2. When doing design always look to existing legacy assets for ideas and refactoring. I wrote earlier about wrapping legacy assets – you will be surprised how much code you already have that is worth reusing when you change the assumptions and decouple it from the existing code
  3. Be on the look out for opportunities to help other teams with what you own. Got a great algorithm, user interface widget, data service, process flow, content fragment that is reusable? spread the word – establish partnerships with your peers, colleagues, and keep sharing. The good karma is bound to help your team and your organization as a whole by increasing consistency and reducing development time.
  4. Keep overlapping requirements, functionality, and feature variations in mind while you design, implement, and refactor code. If you get ideas for a reusable component add it to your list of refactorings or to-dos. Come back and finish it when there is a real need.
  5. Get your team to review existing code. All the code all the time. Code reviews are just about the most effective way to get the most out of reuse – your codebase will continually get leaner and better. Prepare code review check lists for targeted assets (services, features, user interface widgets, classes, etc.) and make sure you use them over and over.

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

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

Software Reuse Quick Tip #8

April 20, 2009

Tip #8 Get requirements from production support for your reusable asset

There is one thing you should do before placing your reusable asset into production and that is talk to your production support staff. Get their input, share your design, and get their feedback early and often. This will not only make your asset supportable (imagine a reusable asset without logging or instrumentation or ability to report on key metrics) it will also get you a valuable partner. Production support will soon learn to trust your assets, your services, and will demand that multiple projects leverage the capability. It is one thing for you to sell reuse but another thing for your partners to voice support.

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

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

Offer reusable assets with multiple interfaces

April 19, 2009

In order to maximize the reuse potential of your assets offer multiple interfaces to the same functionality aimed at targeted audiences. For example, may be you need to expose a service that finds products based on some input criteria. Typically, you might create a findProduct capability that will be generic and reusable and this capability might take input parameters such as product name, identifier,  and product family etc. In addition to this basic capability expose additional interface based on line of business  РfindProduct (name, line of business), findAllProducts (name, line of business) or one based on the relevance criteria РfindProduct (name, full-text-match or starts-with-match or fuzzy match) or a combination of these.

This doesn’t mean you run out and build interfaces! More interfaces mean more maintenance so there is a careful balance between flexibility and the number variations that you can effectively manage. On the flip side, if there are multiple interfaces offered your consumers will find it easier to integrate and invoke your reusable assets. To realize this idea, map the variations into a standard set of parameters and the rest of your processing can proceed oblivious of the consumer input. Defaults and standard values can be provided for missing inputs when doing this.


how do you identify these additional interfaces? As with everything else, these interfaces need to be identified based on demand and priority. If your business sponsor needs to offer a capability for a particular geographical region (e.g. offer for the Americas first, followed by Europe, and Asia-Pacific) or for a particular product family then that is what you should consider for development.

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: