Home > Architecture Tools, Methodology > Evaluating Existing Assets for Reuse

Evaluating Existing Assets for Reuse

Solution architects frequently have to analyze existing internal and external assets for reuse. While reuse can reduce delivery time, improve stability, and reduce delivery cost these benefits  should be not assumed to be automatic. Architects should take great care in determining what they are attempting achieve when suggesting reuse of any asset (patterns, open source, internal, SAAS, or COTS).  Key considerations in reuse decisions should include:

  • Where and how will assets be reused in the solution
  • The expected benefits of asset reuse e.g. functionality, quality, schedule impact or effort savings
  • Possible constraints for asset reuse
  • Cost and budget for the reuse of the asset

The diagram below illustrates the some of the decision making categories should be considered when determining if an asset is suitable for reuse. The key thing to note is that it is not sufficent to simply evaluate functional requirements and determine if a component is reusable. For example, an asset developed for a batch processing application may be fundamentally unsuitable for a real time application since the two solutions have very different architectural characteristics even if the functional requirements are the same.

Analyzing Existing Assets

While this process does not have to be formal a result in excessive documentation, I recommend that you always take the effort to perform it and capture it somehow. In Agile organizations we’ve done this one white boards and taken a snap shot so that six months later the rationale for the solution can be easily recalled or communicated to new team members that might not have been involved in the decision making process.

Evaluating Assets for Reuse  Use Case

The process below can be used as a guide for solution architects to evaluate assets for reuse. This should not be considered a perspective process, but rather a useful process flow that you can follow for ensuring that consistently holistically consider what you are reusing rather than making emotive or decisions based on biased information

  1. Review needs and risk for the current the solution.
  2. Define where and how in the solution, based on the proposed candidate architecture, there is an opportunity for reuse.
  3. Define the expected benefit of reuse. (e.g schedule, quality improvement, and/or reduced delivery effort.)
  4. Define testable/measurable reuse criteria.

4.1.   Define functional requirement criteria for reuse. The functional criteria identify the general features that the asset  provides for reuse. This list should be driven by the identified needs and risks for the solution.

4.2.   Define quality/non-functional requirements characteristic criteria for reuse.(e.g. defect rate, compliance to standards, availability of support resource or documentation)

4.3.   Define project and strategic criteria for reuse. These criteria must capture any long and short term effects of reusing the asset beyond the product release. (e.g. cost, effort saved, vendor/open source community stability)

4.4.   Define the architecture compatibility criteria for reuse. (e.g. service orientation, support for native .Net extensions)

  1. Identify candidate assets for reuse. Common sources of reusable assets are:

5.1.   PMO portfolio management portfolio. This may be an informal spreadsheet or something more formal like Clarity in your organization

5.2.   Review common assets in source control or dependency management systems (e.g. Ivy)

5.3.   Research open source, SAAS, and commercial products

  1. Analyze candidates against identified criteria. Leverage existing documentation and performance tests where available and considered reliable sources of information.
  2. Perform an architectural spike or prototyping exercise to confirm results if time permits. This is strongly encouraged.
  3. Select proposed candidates for reuse

Categories of Evaluation Criteria

Evaluation criteria can be categorized into four main areas:

  • functional requirements
  • quality/non-functional characteristics
  • strategic/project concerns
  • domain and architecture compatibility.

Functional Requirements

Functional requirements refer to identifiable functions, features or characteristics that must be supported. These criteria can be defined based on the solution vision, user stories, use cases, or needs statements. For example:

  • Must support creation of surveys with a configurable number of survey questions

Quality/Non-Functional Characteristics

Quality or non-functional characteristics are more generalized than functional requirements. They constraints for how the asset must perform or is operate. There is typically some commonality to these characteristics from project to project but the acceptable thresholds might change. For example:

  • Defect rate
  • Compliance with a legal guideline like SOX
  • Availability and completeness of documentation

Strategic/Project Concerns

These criteria address the effects of selecting the asset beyond the solution development lifecycle once it is operating in the environment. For example:

  • Cost of ownership
  • Vendor stability
  • Availability of support resources

Domain and Architecture Compatability

Domain compatibility refers to how well the reuse candidate and its features map in to the organizational domain terminology and concepts. For example in an ERP system there may be a concept called party that maps to one or more concepts in the business domain. This can be problematic in cases where there is a complete mis-match. Architecture compatibility refers how well the candidate supports the software, data, and technical architecture requirements defined by the candidate architecture.  For example:


  • Can the levels of the logistic hierarchy be modeled


  • Is a REST API supported

In conclusion, solution architects should always strive to develop models and frameworks for conducting their work. The technique discussed in this article is one such technique. It is not to be considered a replacement for actual experience, but, it can improve the quality of your product selections.



Architectural Layer Model {location}
Expected Benefits of Reuse
  1. Compliance with enterprise security standards
  2. Improved software quality
  3. Improved supportability
  4. Delivery Speed


Areas for Reuse Resource Access LayerDomain LayerUser InterfaceUser Interface Orchestration

Reuse Criteria

ID Criteria Category Supported Benefit
1 Less 5 defects discovered per 30 day period Quality 2,3
2 No more than 1 major release per quarter Quality
3 Supports performing all CRUD actions to a relational database Functional 4
4 Supports creation of surveys with a configurable number of questions Functional 4
5 Provides REST web service API Domain Compatibility 3
6 Component cost less than $1000.00 Strategic

Component Evaluation



Resource Access

Evaluation Matrix

Criteria  ID Satisfied Comments
1 Yes
2 Yes
3 Yes Testing for component only performed against SQL Server 2008
4 N/A
5 No API access via native .Net. Solution is component oriented.
6 Yes

Feedback Server


UI, UI Orchestration, Domain, Resource Access

In conclusion, solution architects should always strive to develop models and frameworks for conducting their work. The technique discussed in this article is one such technique. It is not to be considered a replacement for actual experience, but, it can improve the quality of your product selections.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: