Web services and asset reuse

Implications for developers

Asset reuse is a key component of web services-based software development and for creating a Services-Oriented Architecture. This article provides an introductory overview, as well as tips and examples, of how to make software assets reusable.


Kim Stephens (kimstephens@us.ibm.com), Communications advisor, EMC

Kim Stephens is a communications advisor for IBM in Austin, Texas. In addition to her experience as a writer, she has held several positions in her ten years with IBM including software engineer, marketing program manager, accessibility advocate, Web master, and technical writer. Kim has spent more than twelve years of experience in the IT industry.

04 April 2006

Also available in Chinese


Asset reuse is very important for developers and a key part of Service Oriented Architecture (SOA). By creating a reusable asset, you can strengthen the base of a company’s useable intellectual capital, which can be a tangible market differentiator. In addition, the reduced time and cost to develop successful proposals through reuse of previously proven market deliverables adds to a company’s gross revenue. And proven market deliverables are essential to customer wins.

This article will help the reader learn more about how and why to create reusable assets. It will present strategies and tips on how to create a reusable asset from the beginning of a project. The target audience is a developer with any level of application, integration, and/or management expertise. The tips and strategies for asset reuse will be generic enough that most readers will find them applicable to his/her development cycle.

What is an asset?

An asset can be defined as anything of material value or usefulness. There are several types of assets:

  • Best practices: Techniques or methodologies that, through experience and research, have proven to reliably lead to a desired result.
  • Designs: Written documents that describe a general solution to a design problem that recurs repeatedly in many projects.
  • Tools: Set of assets that aid in development or recreation of a project, application or task.
  • Components: Identifiable parts of a larger program or construction.

For the scope of this article, we'll focus on components used in software applications.

Why create a reusable asset?

The most fundamental reason for creating a reusable asset is because of the positive impact, both financially and strategically, to a company’s bottom line.

Reusable assets reduce costs by shortening development cycles. By taking advantage of previously created assets, developers can save themselves from recreating an asset from scratch. So redundancies across the organization decrease and developer time is saved and in turn, cost is reduced.

In addition, by taking advantage of a proven marketable asset, a developer is taking advantage of a tangible market differentiator. Customers want to do business with companies who are successful. And because the asset has been used before, the developer can demonstrate greater expertise through reference work products and past deliverables and proven engagement models. The risk for the asset was previously assumed, so the customer can expect a high degree of quality without the risk.

A company that reuses assets is not constrained by the number of developers on the team. As developers create assets for one project, the assets are catalogued for future use. These assets can then be reused, allowing developers to concentrate on creating new assets for current projects.

Reusing assets also saves the developer testing time and maintenance work. The time for testing and maintenance is invested when the developer first creates the asset and does not have to be redone with each new project utilizing the reusable assets.

The bottom line is that a project using existing assets will save a company time, money and resources.

Why is asset reuse important to SOA?

In a Service-Oriented Architecture, assets are represented as services. These services are like building blocks that can be reused and assembled into larger structures, applications or services. By creating a reusable asset, you are creating one of these building blocks that can be moved around the architecture to create flexibility in a business. By creating fixed assets you are binding assets to a particular project, and this is contrary to the purpose of SOA.

Challenges you will likely face

As in any development process, when you begin to create reusable assets, you will most likely encounter a few obstacles. In most organizations assets are scattered and siloed in disparate, heterogeneous systems. This makes it difficult for developers to find, access, manage and reuse assets because most companies do not have centrally managed system for controlling and monitoring them. However, as you go through the asset creation process, you can work to create this system and find others who have similar goals of creating a repository for reusable assets.

Of course, there is also the time factor. It could add time to the development cycle to make an existing asset reusable. But it’s easier to do it right the first time then to go back and retrofit the code to be reusable. So, many of the tips for creating a reusable assets are just good development skills and are part of the best practices of developing. And in the long run, you'll save time and money by reusing code rather than going through a whole development cycle for new code.

Tips for asset reuse

Use best practices for software development. Learn from what your colleagues have implemented before you. For example, use configuration management tools to keep track of versions of code, allowing you to track changes and keep metrics.

Avoid short cuts and quick fixes. Again, this is about doing things the right way the first time. For example, when you make a change in the code, make sure you do regression testing to be sure you did not break any other code in the program.

Document the code and solution continuously. It’s much easier to document your code as you are writing it when it is fresh in your mind. It will be a lot harder and less likely to happen at the end of project. For example, document the interfaces to other components and dependencies on other components, etc. (for example, your Java program is dependent upon version 2.7.1 of the Xerces2 Java Parser for parsing documents written to XML 1.1).

Don't use the customer name or reference in code. By using the customer name or reference in the code, you are instantly dating your code and limiting its use. You don't want to include references in your code that are only applicable to one project. For example, don't use the customer name in database schema or class names.

Externalize strings and literals. By externalizing strings and literals you allow them to be more easily changed or translated. So, a developer can use your base code or asset and customize the external strings and literals for his/her purposes. For developing applications that can be run on international platforms, it is important to externalize the text that is displayed by the program. By externalizing strings, the text can be translated for different countries and languages without rebuilding the application.

Also, consider along with externalized strings and literals, using XML configuration or property files for implementation of specific configuration information such as a the URL, or datasource, such as:


Use standard protocols and methods to communicate between software modules. This allows others to easily update or modify your code when they are reusing your asset, if required. For example, instead of a custom messaging format, use XML. XML provides a standards-based, platform-independent way to represent structured data and allows you and others to use standard parsing routines.

Create generic code templates. Generic code templates allow you to reuse code. For example, consider using a function template that is type independent or an adapter class template to extend another type with special behavior.

Adhere to industry standards and specifications. Using standards ensures interoperability and portability. This becomes increasingly important when the asset must communicate with other services to produce the desired outcome. Standards bodies, such as w3c, have spent a considerable amount of time with input from the development community developing these standards.

Use standard templates from your company. If everyone from the company is using the same templates, it is much easier to switch assets among the group. And standard templates insure that every developer is capturing the same information about his/her project. Examples of documents to create:

  • Use-case documents
  • Documents that articulate the business scenario, software modules, interfaces, and hardware clearly
  • Design architectural documents
  • User guides for installation and configuration
  • Class diagrams and interaction diagrams
  • Documents that capture screenshots
Figure 1. A day in the life of an asset
A day in the life of an asset

In figure 1, we trace how an asset is created, catalogued, and then reused. First the customer requests a service or solution that requires the developer to create an asset. The developer creates the asset in a componentized form. After creating the asset, the developer places it in the asset repository. During a separate customer engagement, a solution or service is requested. The developer consults the asset repository to see if there is an applicable asset that can be reused in the requested solution or service. When such an asset is identified, it is incorporated into the customer solution.

An example of asset reuse

Now we know the how and the why, so let’s look at an example of an asset being reused. A customer, a women’s clothing store, needs you to develop a Web storefront solution integrated with a payment processing and product delivery center. You develop a complete solution that allows the store’s clients to shop online. During the creation of this solution you componentized it into parts such as: add to cart, process order, inventory management, shipping, or financial processing. You place each componentized asset in your company’s asset repository. The project is completed for the women’s clothing store, and you move on to your next project.

Two months later, another customer, a jewelry store, comes to your company looking for a solution. They are moving commerce to the Web, so they need an application that allows online transactions. You are involved in another project, but you point one of your colleagues to the asset repository. He searches the asset repository for relevant componentized assets and finds the "add to cart" code. He takes the "add to cart" asset and places it to the current architecture for the customer’s solution, saving 160 person hours in development time, design time and test time.

In this example, reusable assets help both the jewelry store customer and your company. You have provided the customer with a proven solution that has been tested, while saving your company money.


One of the most important concepts of asset reuse is that it must be a consideration during the asset creation process. A developer needs to think about how an asset can and will be used in the future from the moment he/she writes the first line of code until the last one is written.

As companies continue to move towards a service-oriented architecture (SOA), they will look for more ways to create assets as services. By developing assets as building blocks they can be reconfigured and reused, you give increased value to your code and your work. With each project, a developer must now think about how he/she can package his/her code to be of value to the company in the future. This type of thinking will allow the company, and ultimately the developer, to succeed through decreased asset delivery time and with proven deliverables.



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks

Zone=SOA and web services
ArticleTitle=Web services and asset reuse