FIELD OF THE INVENTION
The present invention relates to a method to identify and create reusable assets by defining a context for identifying assets; formulating structure and organizing the assets within the defined context; identifying candidate assets from the potential candidate assets and thereby creating metadata in reuse repository; and harvesting the metadata by using context based method.
BACKGROUND OF THE INVENTION
Organizations preferably Software Delivery Organization (SDOs) earnestly looking at adopting software asset based development for operational excellence and competitiveness are faced with the challenges of identifying, locating, harvesting and managing software assets. The major challenges for SDOs looking to adopt software asset based development are:
A) Identification of assets from the triad of domain, technology, and processes and creating assets with right level of articulation and granularity.
B) Creating assets preferably software assets that have high usability and usefulness (ensuring quality of assets).
C) Ensuring effective usage of the created assets and tracking the Return on Investment (ROI) on such assets.
Some of the issues confronting the SDOs are fundamental in nature. Questions like, what is an asset? What is the process of identifying an asset? Can any artifact be treated as an asset? How to store an asset? How to motivate people to create and store assets? What is the ROI that an organization can accrue from assets? These challenges and questions and the subsequent lack of will and motivation to address these questions impede the creation of a sustainable reuse eco-system within SDOs.
The risk and cost of building a sustainable eco-system for reuse within organization pose a major challenge to build such systems.

OBJECTS OF THE INVENTION
The primary object of the present invention is to provide a methodology for Asset Management which provides a framework for organizations to implement reusable asset management practice by minimizing the risk of failure.
Yet another object of the present invention is an identification of assets from the triad of domain, technology, and processes and creating assets with right level of articulation and granularity.
Still another object of the present invention is to provide 4 stage risk based approach to enable the organizations to: Identify the assets. Create and qualify the assets. Manage the assets through the creation, usage, and change cycles. Search the assets using solution context, the taxonomy, or the keywords. And download for consumption in the favoured tools and in compliance with the processes.
STATEMENT OF THE INVENTION
Accordingly, the present invention provides for a method to identify and create reusable assets, said method comprising steps of defining a context for identifying assets; formulating structure and organizing the assets within the defined context; identifying candidate assets from the potential candidate assets and thereby creating metadata in reuse repository; and harvesting the metadata by using context based method to create reusable assets; and also for a system to identify and create reusable assets comprising a processor to formulate organization and structure of the assets within a defined context; identifying candidate assets from the formulated assets and thereby creating metadata in reuse repository; and optionally defining rules and methods for creation of each type of assets; and harvesting the metadata to create reusable assets a database to store the reusable software asset and data representative of the mapping, wherein database stores the data and the reusable software asset in a searchable form and provides access to the reusable software asset for retrieval of the software artifacts within the one or more repositories; a search engine for selecting reusable assets using solution context/keywords/taxonomy/asset type; and an user interface to download the assets for usage.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
Figure 1 shows an example of setting context based on feature model of a
solution/domain framework.
Figure 2 shows depiction of a mapping between the context created using the feature
model and the business process models that have been used to create and orchestrate an
event based business process flow of an RFID based application.
Figure 3 shows the result of a source code parser through an assembly file.
Figure 4 shows the way asset structure can be defined.
Figure 5 shows how the assets can be organized within a context.
Figure 6 shows a sample method by which assets can be evaluated based on two scales:
business and technology relevance.
Figure 7 depicts definition of asset identification as part of the project planning activity as
defined in a project management software.
Figure 8 shows search based on the context provides a list of candidate assets found
within Scorpus.
Figure 9 depicts how a context based search lists references of the context element within
source code repository.
Figure 10 depicts the governance model created as a workflow in the Scorpus Workflow
Manager.
Figure 11 shows a scenario wherein a mandatory usage of a framework element is
enforced while creating an asset.
DETAILED DESCRIPTION OF THE INVENTION
The primary embodiment of the present invention is a method to identify and create reusable assets, said method comprising steps of defining a context for identifying assets; formulating structure and organizing the assets within the defined context; identifying candidate assets from the potential candidate assets and thereby creating metadata in reuse repository; and harvesting the metadata by using context based method to create reusable assets.
Yet another embodiment of the present invention, the context enables to set up a definitive and predictive model for identifying and creating assets.

Still another embodiment of the present invention, the context provides a reference for
harvesting assets from existing sources and/or afresh.
Still another embodiment of the present invention, the defining context is based on
recurring problem, solution or an architecture of product or solution.
Still another embodiment of the present invention, the structure of asset comprises;
i. identifying the type of asset; and
ii. formulating the metadata to be captured for each type of asset. Still another embodiment of the present invention, the asset types determines the way an organization creates and consumes assets.
Still another embodiment of the present invention, the type of assets are created by using predefined structure and methods.
Still another embodiment of the present invention, the organizing assets involves logically grouping a related set of assets under a given context.
Still another embodiment of the present invention, the context is selected from a group comprising business unit, solution or domain frame work, asset types and technology. Still another embodiment of the present invention, the identification of candidate is carried out by either top down approach or middle out approach.
Still another embodiment of the present invention, the top down approach comprises well defined architecture and frame work to create assets.
Still another embodiment of the present invention, the architecture is decomposed into several layers of granularity.
Still another embodiment of the present invention, the top down approach enables for identifying assets at various levels of granularity within the boundaries of the context set; creating stubs of assets which is created at each granularity level; and optionally performing a return on Investment analysis on the identified assets; Still another embodiment of the present invention, the middle out approach is followed for identified assets having unrecognized assets.
Still another embodiment of the present invention, the metadata harvested from existing sources comprises;
• Artifact Name;
• Artifact type based on file extensions;

• Artifact category preferably business process models, software execution
workflows, requirements, design, source code, test cases;
• Artifact relationships and interrelationships with other artifacts;
• Artifact location preferably version control systems, windows file systems;
• Interfaces, Classes, methods, routines, sub-routines in case of source code;
• Database models ;
• Calls to other classes, methods, routines, sub-routines, database sources in case of source code; and
• Web services registered in UDDI registry.
Still another embodiment of the present invention, the harvesting of the metadata is carried out by either manually or by using automated harvester.
Another important embodiment of the present invention is a system shown in figure 12 to identify and create reusable assets comprising a processor to formulate organization and structure of the assets within a defined context; identifying candidate assets from the formulated assets and thereby creating metadata in reuse repository; and optionally defining rules and methods for creation of each type of assets; and harvesting the metadata to create reusable assets; a database to store the reusable software asset and data representative of the mapping, wherein database stores the data and the reusable software asset in a searchable form and provides access to the reusable software asset for retrieval of the software artifacts within the one or more repositories; a search engine for selecting reusable assets using solution context/keywords/taxonomy/asset type; and an user interface to download the assets for usage.
The expression "Software delivery organizations (SDO's)" used in this invention represents any organization which develops and/or uses multiple kinds of software's, not limiting to the service sector. The methodology employed in the instant invention to identify and create reusable assets are not limiting to software assets. Hence the present

invention is not limiting to particular organization or particular type of asset. Hereafter organization is referred as Software delivery organizations (SDO's).
Scorpus' 4 stage CRUX methodology for Asset Management provides a framework for organizations to implement software reuse and asset management practice by minimizing the risk of failure. It envisages a series of stages each comprising of activities and steps that enable an SDO to successfully implement and sustain the reuse and software asset management practice. This whitepaper is aimed at business managers, delivery heads, architects, senior managers who wish to implement the Enterprise Software Asset Management (ESAM ™) practice within their SDO.
The four stages in the software asset management are:
1. Provisioning and Identifying Assets
Setting the software asset context (based on recurring problem, solution or an architecture of product or solution)
• Formulate the organization & structure of assets. (Based on target usage and
related assets)
Identification of candidate assets and capturing of metadata in the RAS
repository.
Asset identification as part of project management activities
2. Harvest AS-IS software and Create TO-BE software assets
• Harvest interfaces, dependencies, & similar logical unit details from applications,
databases, middleware, requirements, design, and test artifacts.
Create the assets bringing them to the TO-BE reused form.
• Creation of assets in conformance to the governance model.
3. Manage software Assets
• Qualify reusable assets and govern changes to them through multiple cycles.
• Unify distributed software development and knowledge repositories through a master repository.
Track Metrics and usage of software assets.

• Maintain versions and changes of the assets.
• Integrate software development process lifecycle with asset based development methodology.
4. Download and consume
1. Gain visibility into enterprise systems and software applications
• Architectural or solution framework elements and the interface details Visibility into application logical units that carry out specific functionality and their cross-application integration points and dependencies Dependency mapping and change impact across the defined asset landscape.
2. Search using solution context / keywords / taxonomy / asset type and download the assets for usage.
3. Download to target design time environment for consumption
The scope of this invention is for organizations to start Enterprise Software Asset Management (ESAM™) practice. This invention covers the first two stages of 4-Stage CRUX methodology.
ASSET IDENTIFICATION (STAGE 1 OF 4 STAGE METHODOLOGY)
Assets typically constitute a part of the application developed or being developed. The identification and extraction of software assets is similar in nature to extraction of metals from its ore. The key underlining point is to understand that not everything is an asset. The process of identification and extraction of assets comprises of the following steps:
1. Asset context setting (Conceptual Asset Provisioning)
This step entails creation of a context for identifying the assets. The context is basically a container or placeholder to identify an asset. It is a formal description of where and for what purpose an asset could be produced and consumed.
Contexts are typically set based on a combination of one or more but not limited to business domain, feature model, business process model, and solution or technology

framework. The Goal-Question-Mctrics model provides a basis to arrive at the context for an organization.
The context enables organizations to set up a definitive and predictive model for creating assets. It provides a reference for harvesting (mining) assets fronrexisting sources or afresh. All assets thus created get bound to the context definition. The relevance of setting context is underlined by the fact that without a context, creation of assets will be open-ended, without link to organization goals and objectives and would be ad-hoc. The major risk in such scenarios would that several assets would be created that would not yield the desired Return on Investment (ROI) and more importantly result in business or financial loss for the organization.
Inset: Example of Asset Context Setting is shown in figure 1. The figure 1 describes an example of context setting based on an enterprise's need to create a solution framework for Radio Frequency Identification Devices (RFID) based tracking and identification applications. The diagram depicts a feature model that maps the set of all problems that the organization wishes to realize and solve in the chosen domain. The model provides a basis to attach assets created after harvesting from existing sources to a reference model.
The figure 2, shows depiction of a mapping between the context created using the feature model and the business process models that have been used to create and orchestrate an event based business process flow of an RFID based application.
Mapping assets created with the context clearly establishes means to track goals and metrics set for organization's reuse initiative. It provides a direct measure of which organization business area or domain area, solution area or technology is yielding maximum yield and where the focus needs to be given.
2. Identifying unrecognized assets
Several years of organization's software development practice would have created a huge set of potential wealth of untapped software assets. They do not fall under any of the formal context definitions set in the previous step but are running and undergo constant

changes. Normally these types of assets do not have formal documentations or relationship between design time artifacts and source code defined. There are two types of assets that fall under the unrecognized category:
• Physical Assets: These are assets that exist, running, and are already being consumed
by a large set of users. Typically the consumption of such assets is within a small area
of business or development teams. This kind of scenario breeds rework in
organization as relationship and their interrelationship with other sub-systems are not
available thus resulting in poor impact analysis during changes. Such assets are often
manifested at the source code levels. At a macro level the following properties
characterize such assets and can be used to identify such assets:
o Most commonly used source code routines and sub-routines.
o Most commonly changed source code or documents.
o Source code routines or sub-routines that get called most by other routines.
• Logical Assets: These are assets that can be formed by grouping together commonly
used features, functions, routines, sub-routines, artifacts, models. Although such
assets are physically different, they normally perform similar functions. This kind of
scenario results in redundancy creeping within organizations.
Scorpus CRUX addresses the above two scenarios by providing insight into metadata, relationships and interrelationships within source code and databases.
Inset: Example of Asset identification through harvesting is shown in figure 3. The figure 3 describes the result of a source code parser through an assembly file. It provides information on various routines and sub-routines present in the assembly and its dependency. It provides a measure of other sub-routines that call this routine.
3. Structuring and organizing the assets
Once the context has been established it is imperative for the organization to define the way an asset will be structured and organized within the context. The structure of an asset involves the following:
• Identifying the types of asset

o Assets could be of the type components, services, business process models, data models, software applications, requirements/design models, etc. o Asset types identified have a purpose and fit in the overall context. o Asset types determine the way an organization looks at creating and consuming assets. • Formulating the metadata to be captured for each type of asset Organizing the assets involves logically grouping a related set of assets under a given context. The context could be a business unit, solution or domain framework, asset types, or technology.
Inset: Example of Asset structuring and organization is shown in figure 4. The figure 4 describes the way asset structure can be defined. The structure determines the metadata that would be used to capture and consume asset. The figure 5 describes how the assets can be organized within a context. In the example below the assets are organized within the context of RFID solution framework.
4. Identifying candidate assets and creating metadata in reuse repository
Once the contexts have been defined, asset structure and organization formulated, further identification depends on 2 factors.
Top down approach: In this approach a well defined architecture and framework has been defined to create assets. The architecture has been decomposed into several layers of granularity. This approach calls for architects/business analysts to:
o Identify assets at various levels of granularity within the boundaries of the
context set. o Creating stubs of assets that would be created at each granularity level. o (Optional): Perform a Return on Investment (ROI) Analysis on the identified assets (Refer template for Asset Evaluation). The ROI analysis can be used as a go-no go decision support system.

o Provide basic metadata of the assets identified in the reuse repository. Basic metadata entails tagging the organization taxonomy (derived from the context), and usage. Middle out approach: This approach is suitable when the asset identification involves asset identified are unrecognized (refer Section 2.2.2). Since the assets that could spring up are unplanned and are not based on any of the context set, it is more important to understand their relevance and importance in the organization. It is recommended that the architects, and developers analyze on the suitability of assets by:
o Verify if the assets fit in any of the context set. If the there is a fit then the
asset is not only a potential candidate to be managed and tracked but also to
be modernized using legacy transformation approaches such as services,
components, etc.
o If the assets do not fit into any of the existing context, analyze the suitability
to create a new element in the context that fits the harvested asset. o If a new element is added, it indicates a gap in the context that was set earlier and could point to new potential areas in business or solution or technology framework. o Perform a Return on Investment (ROI) Analysis on the harvested assets (Refer template for Asset Evaluation). The ROI analysis can be used as a go-no go decision support system. o Provide basic metadata along with the location the existing asset and store in a reuse repository.
Inset: Example of Asset Evaluation Template
The figure5 provides a sample method by which assets can be evaluated based on two scales: business and technology relevance. Each parameter with a weightage factor determines the overall score of an asset. The higher the score in the two scales, higher is its relevance to the organization. The score also determines the investment level and focus that needs to be put on the asset.

5. Asset identification as part of project management activities
(Refer to section 2.3.2 for more details on defining governance models and enforcement) Identification and subsequent creation of assets is an activity that needs to be ingrained seamlessly into an SDO's software development lifecycle (SDLC) processes. Such integrations are effective if the asset management activities are part of the project activities and are typically defined in the SDOs project management software. The advantages of ingraining the stages of asset management into the project processes are that it becomes a part of the SDO's culture and does not become a "yet another" disparate system that works in a silo. The following best practices are recommended for SDOs to define and enforce asset governance policies:
Define Software Asset Management stages and their activities as part of the Software
development lifecycle activities.
Define assets identification stage as a set of activities (section 2.2) to be performed by
business/technical analysts during the project initiation phase. The resultant metrics
for the project can include cost benefit and cost savings due to consumption of such
assets.
Define governance rules for consumption of assets such that assets usage can be
tracked and monitored.
Inset: Example of Asset Identification stage incorporated as part of the project plan (defined in a project management tool)
The figure 6 depicts definition of asset identification as part of the project planning activity as defined in a project management software.
Scorpus CRUX plug-in allow integrations with project management software and enforce the activity defined. Following is the sequence:
1. Project task is defined in Project Management software
2. Project task is created as a workflow activity in Scorpus workflow manager.
3. In an integrated scenario Scorpus workflow engine keeps track of tasks being accomplished.
4. The task of asset identification is triggered by means of initiation either in the project management software or in Scorpus workflow manager.

5. The workflow manager has the option to throw up template for asset identification. (Refer fig. on left)
6. Once the asset identification task is completed, Scorpus workflow manager informs the project management software about the completion
7. The tracking module of the project management software depicts the task as "completed".
Please note: In the figure 7, a search based on the context provides a list of candidate assets found within Scorpus. Same search criteria could be used to search in other repositories such as file systems and version controllers.
ASSET CREATION
Once the assets have been identified and cataloged in the reuse repository, a strategy is adopted for creating the assets. Two approaches to the creation can be adopted for the creation. The key to both the approaches is the Asset identification stage as described in the previous sections. Without identification and context setting, the creation of assets has no significance in organization's context. It merely lies in the repository without technical and financial support.
An asset is deemed to be created if it fulfils the criteria of asset structure as described in previous sections.
1. Asset creation by harvesting from existing sources
Note: This step can be skipped if the creation of asset is afresh.
Creation of Asset by means of harvesting is a quick and surefire way to get started with
building the software asset bank. The pre-requisite to harvest is to identify the assets that
need to be created. As explained in the previous stage of CRUX, the assets could be
arrived based on the context or could be unrecognized. The candidate assets would have
been identified as per section 2.2.4 and basic metadata stored in the reuse repository. The
assets that need to be harvested could be available in file systems or in version
controllers.
The metadata that can be harvested from existing sources include:

• Artifact Name
• Artifact type (based on file extensions)
• Artifact category (requirements, design, source code, test cases, etc)
• Artifact relationships and interrelationships with other artifacts.
• Artifact location (version control systems, windows file systems)
• Interfaces, Classes, methods, routines, sub-routines (in case of source code)
• Database models (from the database)
• Calls to other classes, methods, routines, sub-routines, database sources (in case of source code)
• Web services registered in UDDI registry.
The method to harvest such asset metadata could be two folds.
1. Manual: This is a highly time consuming, labor intensive activity. It is almost humanly impossible to harvest asset metadata when the size of assets involves millions of lines of code, thousands of artifacts spread across various physical locations.
2. Scorpus Harvester: Scorpus Harvester is a software utility that scans the sources of assets, extract the metadata required and provide the results back to the users. Harvesters provide the artifact types, extract interfaces, classes, methods, routines, sub-routines, and database models, calls made between the source codes internally and to the databases, web services registered in UDDI registries.
Note: In future Scorpus harvester will provide capability to relate requirements, design, business processes stored in office documents like word, excel with the source code and database.
The effectiveness of harvesting capability is determined by how crisply and clearly the context is defined.
Subsequent to the harvesting the assets need to be brought into "TO-BE-REUSED" form. This form entails the asset metadata to be created as defined by the asset structure model. The details are available as product features and can be referenced through the Scorpus product datasheet.

Inset: Example of Asset Harvesting based on a context set
The figure 9 depicts how a context based search lists references of the context element within source code repository. A feature "Create Reader" is set as a context element and the system scans the source code repository and the database repository to list all direct and similar references of the context element. It also depicts the relationship of the source code with other source code. The output of the scan results can be used by the users to identify the right source code and database elements for the asset context. The scan results could also help identify newer assets hitherto unknown. The selected source code, database elements along with their properties like classes, methods, routines, subroutines, relationships are created as metadata for the asset.
2. Creation of Assets in conformance to the governance model
Governance model for the creation and consumption is laid out during the planning stage
(section 2.2) of the reuse and asset management initiative. Once the asset structure and
organization is defined it is important to define the rules and methods for creation of each
type of asset. The rules and methods are defined within the triad of process, people and
technology.
The process can describe:
Sequence of activities to be followed for creating assets.
Integration with software development lifecycle processes.
Work products to be created or consumed.
Architecture definition to be mandated. (Deriving artifacts, models, etc from a
framework)
The technology can describe: Development Tools to be used Location to scan and store assets Mandatory technology to be followed

People can describe:
Roles to perform an activity defined in the process Roles to consume an activity defined in the process
Adherence to such governance model ensures integrity and correctness of the assets being created. Also Gating points can be described in the governance model wherein quality checks can be performed on the assets at various stages.
Scorpus supports the definition and enforcement of the governance model through its
Workflow manager and Workflow engine.
Workflow manager is used to define the governance model and integrate with
organizations eco-system of tools, process and technology.
Workflow engine controls, tracks and monitors the workflow in real time.
Inset: Example of governance model defined and enforcement through Scorpus
The figure 10 depicts the governance model created as a workflow in the Scorpus Workflow Manager. The workflow contains the sequence of activities to be carried out while creating an asset, the conditions and rules for the activity. Once the governance model has been defined, Scorpus workflow engine ensure the compliance and adherence to the model. In this example a scenario is depicted in figure 11 wherein a mandatory usage of a framework element is enforced while creating an asset. In this instance, a business process model created by a business analyst needs to be used as a mandatory derivation while the asset creator creates an asset of a solution framework.
Conclusion
Enterprise software asset management (ESAM) adoption strategy is holistic in its approach covering the various risk factors in the adoption stage and through the adaptation cycle. The risk factors are organizational specific and based on the business focus areas & goals, operations, technology, process maturity, availability of knowledge, legal, motivation of the personnel, software asset realization strategy, etc to list a few.

Though not all of them can be addressed by Scorpus, we have a pragmatic approach covering a lot of them through risk alleviation approach. We understand that the value of software assets will increase, if the same is sought, found, and used repeatedly within or across the organizational units. Scorpus ESAM has worked towards this and brings forth the 4 stage risk based approach to enable the software delivery organizations (SDO's) to:
1. Identify the assets.
2. Create and qualify the assets.
3. Manage the assets through the creation, usage, and change cycles.
a. In complete compliance to the SDO's delivery processes and activities.
b. In unification with the tools and methods to create software.
4. Search the assets using solution context, the taxonomy, or the keywords.
a. And download for consumption in the favoured tools and in compliance with the processes.

FIELD OF THE INVENTION
The present invention relates to a method to identify and create reusable assets by defining a context for identifying assets; formulating structure and organizing the assets within the defined context; identifying candidate assets from the potential candidate assets and thereby creating metadata in reuse repository; and harvesting the metadata by using context based method.
BACKGROUND OF THE INVENTION
Organizations preferably Software Delivery Organization (SDOs) earnestly looking at adopting software asset based development for operational excellence and competitiveness are faced with the challenges of identifying, locating, harvesting and managing software assets. The major challenges for SDOs looking to adopt software asset based development are:
A) Identification of assets from the triad of domain, technology, and processes and creating assets with right level of articulation and granularity.
B) Creating assets preferably software assets that have high usability and usefulness (ensuring quality of assets).
C) Ensuring effective usage of the created assets and tracking the Return on Investment (ROI) on such assets.
Some of the issues confronting the SDOs are fundamental in nature. Questions like, what is an asset? What is the process of identifying an asset? Can any artifact be treated as an asset? How to store an asset? How to motivate people to create and store assets? What is the ROI that an organization can accrue from assets? These challenges and questions and the subsequent lack of will and motivation to address these questions impede the creation of a sustainable reuse eco-system within SDOs.
The risk and cost of building a sustainable eco-system for reuse within organization pose a major challenge to build such systems.

OBJECTS OF THE INVENTION
The primary object of the present invention is to provide a methodology for Asset Management which provides a framework for organizations to implement reusable asset management practice by minimizing the risk of failure.
Yet another object of the present invention is an identification of assets from the triad of domain, technology, and processes and creating assets with right level of articulation and granularity.
Still another object of the present invention is to provide 4 stage risk based approach to enable the organizations to: Identify the assets. Create and qualify the assets. Manage the assets through the creation, usage, and change cycles. Search the assets using solution context, the taxonomy, or the keywords. And download for consumption in the favoured tools and in compliance with the processes.
STATEMENT OF THE INVENTION
Accordingly, the present invention provides for a method to identify and create reusable assets, said method comprising steps of defining a context for identifying assets; formulating structure and organizing the assets within the defined context; identifying candidate assets from the potential candidate assets and thereby creating metadata in reuse repository; and harvesting the metadata by using context based method to create reusable assets; and also for a system to identify and create reusable assets comprising a processor to formulate organization and structure of the assets within a defined context; identifying candidate assets from the formulated assets and thereby creating metadata in reuse repository; and optionally defining rules and methods for creation of each type of assets; and harvesting the metadata to create reusable assets a database to store the reusable software asset and data representative of the mapping, wherein database stores the data and the reusable software asset in a searchable form and provides access to the reusable software asset for retrieval of the software artifacts within the one or more repositories; a search engine for selecting reusable assets using solution context/keywords/taxonomy/asset type; and an user interface to download the assets for usage.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
Figure 1 shows an example of setting context based on feature model of a
solution/domain framework.
Figure 2 shows depiction of a mapping between the context created using the feature
model and the business process models that have been used to create and orchestrate an
event based business process flow of an RFID based application.
Figure 3 shows the result of a source code parser through an assembly file.
Figure 4 shows the way asset structure can be defined.
Figure 5 shows how the assets can be organized within a context.
Figure 6 shows a sample method by which assets can be evaluated based on two scales:
business and technology relevance.
Figure 7 depicts definition of asset identification as part of the project planning activity as
defined in a project management software.
Figure 8 shows search based on the context provides a list of candidate assets found
within Scorpus.
Figure 9 depicts how a context based search lists references of the context element within
source code repository.
Figure 10 depicts the governance model created as a workflow in the Scorpus Workflow
Manager.
Figure 11 shows a scenario wherein a mandatory usage of a framework element is
enforced while creating an asset.
DETAILED DESCRIPTION OF THE INVENTION
The primary embodiment of the present invention is a method to identify and create reusable assets, said method comprising steps of defining a context for identifying assets; formulating structure and organizing the assets within the defined context; identifying candidate assets from the potential candidate assets and thereby creating metadata in reuse repository; and harvesting the metadata by using context based method to create reusable assets.
Yet another embodiment of the present invention, the context enables to set up a definitive and predictive model for identifying and creating assets.

Still another embodiment of the present invention, the context provides a reference for
harvesting assets from existing sources and/or afresh.
Still another embodiment of the present invention, the defining context is based on
recurring problem, solution or an architecture of product or solution.
Still another embodiment of the present invention, the structure of asset comprises;
i. identifying the type of asset; and
ii. formulating the metadata to be captured for each type of asset. Still another embodiment of the present invention, the asset types determines the way an organization creates and consumes assets.
Still another embodiment of the present invention, the type of assets are created by using predefined structure and methods.
Still another embodiment of the present invention, the organizing assets involves logically grouping a related set of assets under a given context.
Still another embodiment of the present invention, the context is selected from a group comprising business unit, solution or domain frame work, asset types and technology. Still another embodiment of the present invention, the identification of candidate is carried out by either top down approach or middle out approach.
Still another embodiment of the present invention, the top down approach comprises well defined architecture and frame work to create assets.
Still another embodiment of the present invention, the architecture is decomposed into several layers of granularity.
Still another embodiment of the present invention, the top down approach enables for identifying assets at various levels of granularity within the boundaries of the context set; creating stubs of assets which is created at each granularity level; and optionally performing a return on Investment analysis on the identified assets; Still another embodiment of the present invention, the middle out approach is followed for identified assets having unrecognized assets.
Still another embodiment of the present invention, the metadata harvested from existing sources comprises;
• Artifact Name;
• Artifact type based on file extensions;

• Artifact category preferably business process models, software execution
workflows, requirements, design, source code, test cases;
• Artifact relationships and interrelationships with other artifacts;
• Artifact location preferably version control systems, windows file systems;
• Interfaces, Classes, methods, routines, sub-routines in case of source code;
• Database models ;
• Calls to other classes, methods, routines, sub-routines, database sources in case of source code; and
• Web services registered in UDDI registry.
Still another embodiment of the present invention, the harvesting of the metadata is carried out by either manually or by using automated harvester.
Another important embodiment of the present invention is a system shown in figure 12 to identify and create reusable assets comprising a processor to formulate organization and structure of the assets within a defined context; identifying candidate assets from the formulated assets and thereby creating metadata in reuse repository; and optionally defining rules and methods for creation of each type of assets; and harvesting the metadata to create reusable assets; a database to store the reusable software asset and data representative of the mapping, wherein database stores the data and the reusable software asset in a searchable form and provides access to the reusable software asset for retrieval of the software artifacts within the one or more repositories; a search engine for selecting reusable assets using solution context/keywords/taxonomy/asset type; and an user interface to download the assets for usage.
The expression "Software delivery organizations (SDO's)" used in this invention represents any organization which develops and/or uses multiple kinds of software's, not limiting to the service sector. The methodology employed in the instant invention to identify and create reusable assets are not limiting to software assets. Hence the present

invention is not limiting to particular organization or particular type of asset. Hereafter organization is referred as Software delivery organizations (SDO's).
Scorpus' 4 stage CRUX methodology for Asset Management provides a framework for organizations to implement software reuse and asset management practice by minimizing the risk of failure. It envisages a series of stages each comprising of activities and steps that enable an SDO to successfully implement and sustain the reuse and software asset management practice. This whitepaper is aimed at business managers, delivery heads, architects, senior managers who wish to implement the Enterprise Software Asset Management (ESAM ™) practice within their SDO.
The four stages in the software asset management are:
1. Provisioning and Identifying Assets
Setting the software asset context (based on recurring problem, solution or an architecture of product or solution)
• Formulate the organization & structure of assets. (Based on target usage and
related assets)
Identification of candidate assets and capturing of metadata in the RAS
repository.
Asset identification as part of project management activities
2. Harvest AS-IS software and Create TO-BE software assets
• Harvest interfaces, dependencies, & similar logical unit details from applications,
databases, middleware, requirements, design, and test artifacts.
Create the assets bringing them to the TO-BE reused form.
• Creation of assets in conformance to the governance model.
3. Manage software Assets
• Qualify reusable assets and govern changes to them through multiple cycles.
• Unify distributed software development and knowledge repositories through a master repository.
Track Metrics and usage of software assets.

• Maintain versions and changes of the assets.
• Integrate software development process lifecycle with asset based development methodology.
4. Download and consume
1. Gain visibility into enterprise systems and software applications
• Architectural or solution framework elements and the interface details Visibility into application logical units that carry out specific functionality and their cross-application integration points and dependencies Dependency mapping and change impact across the defined asset landscape.
2. Search using solution context / keywords / taxonomy / asset type and download the assets for usage.
3. Download to target design time environment for consumption
The scope of this invention is for organizations to start Enterprise Software Asset Management (ESAM™) practice. This invention covers the first two stages of 4-Stage CRUX methodology.
ASSET IDENTIFICATION (STAGE 1 OF 4 STAGE METHODOLOGY)
Assets typically constitute a part of the application developed or being developed. The identification and extraction of software assets is similar in nature to extraction of metals from its ore. The key underlining point is to understand that not everything is an asset. The process of identification and extraction of assets comprises of the following steps:
1. Asset context setting (Conceptual Asset Provisioning)
This step entails creation of a context for identifying the assets. The context is basically a container or placeholder to identify an asset. It is a formal description of where and for what purpose an asset could be produced and consumed.
Contexts are typically set based on a combination of one or more but not limited to business domain, feature model, business process model, and solution or technology

framework. The Goal-Question-Mctrics model provides a basis to arrive at the context for an organization.
The context enables organizations to set up a definitive and predictive model for creating assets. It provides a reference for harvesting (mining) assets fronrexisting sources or afresh. All assets thus created get bound to the context definition. The relevance of setting context is underlined by the fact that without a context, creation of assets will be open-ended, without link to organization goals and objectives and would be ad-hoc. The major risk in such scenarios would that several assets would be created that would not yield the desired Return on Investment (ROI) and more importantly result in business or financial loss for the organization.
Inset: Example of Asset Context Setting is shown in figure 1. The figure 1 describes an example of context setting based on an enterprise's need to create a solution framework for Radio Frequency Identification Devices (RFID) based tracking and identification applications. The diagram depicts a feature model that maps the set of all problems that the organization wishes to realize and solve in the chosen domain. The model provides a basis to attach assets created after harvesting from existing sources to a reference model.
The figure 2, shows depiction of a mapping between the context created using the feature model and the business process models that have been used to create and orchestrate an event based business process flow of an RFID based application.
Mapping assets created with the context clearly establishes means to track goals and metrics set for organization's reuse initiative. It provides a direct measure of which organization business area or domain area, solution area or technology is yielding maximum yield and where the focus needs to be given.
2. Identifying unrecognized assets
Several years of organization's software development practice would have created a huge set of potential wealth of untapped software assets. They do not fall under any of the formal context definitions set in the previous step but are running and undergo constant

changes. Normally these types of assets do not have formal documentations or relationship between design time artifacts and source code defined. There are two types of assets that fall under the unrecognized category:
• Physical Assets: These are assets that exist, running, and are already being consumed
by a large set of users. Typically the consumption of such assets is within a small area
of business or development teams. This kind of scenario breeds rework in
organization as relationship and their interrelationship with other sub-systems are not
available thus resulting in poor impact analysis during changes. Such assets are often
manifested at the source code levels. At a macro level the following properties
characterize such assets and can be used to identify such assets:
o Most commonly used source code routines and sub-routines.
o Most commonly changed source code or documents.
o Source code routines or sub-routines that get called most by other routines.
• Logical Assets: These are assets that can be formed by grouping together commonly
used features, functions, routines, sub-routines, artifacts, models. Although such
assets are physically different, they normally perform similar functions. This kind of
scenario results in redundancy creeping within organizations.
Scorpus CRUX addresses the above two scenarios by providing insight into metadata, relationships and interrelationships within source code and databases.
Inset: Example of Asset identification through harvesting is shown in figure 3. The figure 3 describes the result of a source code parser through an assembly file. It provides information on various routines and sub-routines present in the assembly and its dependency. It provides a measure of other sub-routines that call this routine.
3. Structuring and organizing the assets
Once the context has been established it is imperative for the organization to define the way an asset will be structured and organized within the context. The structure of an asset involves the following:
• Identifying the types of asset

o Assets could be of the type components, services, business process models, data models, software applications, requirements/design models, etc. o Asset types identified have a purpose and fit in the overall context. o Asset types determine the way an organization looks at creating and consuming assets. • Formulating the metadata to be captured for each type of asset Organizing the assets involves logically grouping a related set of assets under a given context. The context could be a business unit, solution or domain framework, asset types, or technology.
Inset: Example of Asset structuring and organization is shown in figure 4. The figure 4 describes the way asset structure can be defined. The structure determines the metadata that would be used to capture and consume asset. The figure 5 describes how the assets can be organized within a context. In the example below the assets are organized within the context of RFID solution framework.
4. Identifying candidate assets and creating metadata in reuse repository
Once the contexts have been defined, asset structure and organization formulated, further identification depends on 2 factors.
Top down approach: In this approach a well defined architecture and framework has been defined to create assets. The architecture has been decomposed into several layers of granularity. This approach calls for architects/business analysts to:
o Identify assets at various levels of granularity within the boundaries of the
context set. o Creating stubs of assets that would be created at each granularity level. o (Optional): Perform a Return on Investment (ROI) Analysis on the identified assets (Refer template for Asset Evaluation). The ROI analysis can be used as a go-no go decision support system.

o Provide basic metadata of the assets identified in the reuse repository. Basic metadata entails tagging the organization taxonomy (derived from the context), and usage. Middle out approach: This approach is suitable when the asset identification involves asset identified are unrecognized (refer Section 2.2.2). Since the assets that could spring up are unplanned and are not based on any of the context set, it is more important to understand their relevance and importance in the organization. It is recommended that the architects, and developers analyze on the suitability of assets by:
o Verify if the assets fit in any of the context set. If the there is a fit then the
asset is not only a potential candidate to be managed and tracked but also to
be modernized using legacy transformation approaches such as services,
components, etc.
o If the assets do not fit into any of the existing context, analyze the suitability
to create a new element in the context that fits the harvested asset. o If a new element is added, it indicates a gap in the context that was set earlier and could point to new potential areas in business or solution or technology framework. o Perform a Return on Investment (ROI) Analysis on the harvested assets (Refer template for Asset Evaluation). The ROI analysis can be used as a go-no go decision support system. o Provide basic metadata along with the location the existing asset and store in a reuse repository.
Inset: Example of Asset Evaluation Template
The figure5 provides a sample method by which assets can be evaluated based on two scales: business and technology relevance. Each parameter with a weightage factor determines the overall score of an asset. The higher the score in the two scales, higher is its relevance to the organization. The score also determines the investment level and focus that needs to be put on the asset.

5. Asset identification as part of project management activities
(Refer to section 2.3.2 for more details on defining governance models and enforcement) Identification and subsequent creation of assets is an activity that needs to be ingrained seamlessly into an SDO's software development lifecycle (SDLC) processes. Such integrations are effective if the asset management activities are part of the project activities and are typically defined in the SDOs project management software. The advantages of ingraining the stages of asset management into the project processes are that it becomes a part of the SDO's culture and does not become a "yet another" disparate system that works in a silo. The following best practices are recommended for SDOs to define and enforce asset governance policies:
Define Software Asset Management stages and their activities as part of the Software
development lifecycle activities.
Define assets identification stage as a set of activities (section 2.2) to be performed by
business/technical analysts during the project initiation phase. The resultant metrics
for the project can include cost benefit and cost savings due to consumption of such
assets.
Define governance rules for consumption of assets such that assets usage can be
tracked and monitored.
Inset: Example of Asset Identification stage incorporated as part of the project plan (defined in a project management tool)
The figure 6 depicts definition of asset identification as part of the project planning activity as defined in a project management software.
Scorpus CRUX plug-in allow integrations with project management software and enforce the activity defined. Following is the sequence:
1. Project task is defined in Project Management software
2. Project task is created as a workflow activity in Scorpus workflow manager.
3. In an integrated scenario Scorpus workflow engine keeps track of tasks being accomplished.
4. The task of asset identification is triggered by means of initiation either in the project management software or in Scorpus workflow manager.

5. The workflow manager has the option to throw up template for asset identification. (Refer fig. on left)
6. Once the asset identification task is completed, Scorpus workflow manager informs the project management software about the completion
7. The tracking module of the project management software depicts the task as "completed".
Please note: In the figure 7, a search based on the context provides a list of candidate assets found within Scorpus. Same search criteria could be used to search in other repositories such as file systems and version controllers.
ASSET CREATION
Once the assets have been identified and cataloged in the reuse repository, a strategy is adopted for creating the assets. Two approaches to the creation can be adopted for the creation. The key to both the approaches is the Asset identification stage as described in the previous sections. Without identification and context setting, the creation of assets has no significance in organization's context. It merely lies in the repository without technical and financial support.
An asset is deemed to be created if it fulfils the criteria of asset structure as described in previous sections.
1. Asset creation by harvesting from existing sources
Note: This step can be skipped if the creation of asset is afresh.
Creation of Asset by means of harvesting is a quick and surefire way to get started with
building the software asset bank. The pre-requisite to harvest is to identify the assets that
need to be created. As explained in the previous stage of CRUX, the assets could be
arrived based on the context or could be unrecognized. The candidate assets would have
been identified as per section 2.2.4 and basic metadata stored in the reuse repository. The
assets that need to be harvested could be available in file systems or in version
controllers.
The metadata that can be harvested from existing sources include:

• Artifact Name
• Artifact type (based on file extensions)
• Artifact category (requirements, design, source code, test cases, etc)
• Artifact relationships and interrelationships with other artifacts.
• Artifact location (version control systems, windows file systems)
• Interfaces, Classes, methods, routines, sub-routines (in case of source code)
• Database models (from the database)
• Calls to other classes, methods, routines, sub-routines, database sources (in case of source code)
• Web services registered in UDDI registry.
The method to harvest such asset metadata could be two folds.
1. Manual: This is a highly time consuming, labor intensive activity. It is almost humanly impossible to harvest asset metadata when the size of assets involves millions of lines of code, thousands of artifacts spread across various physical locations.
2. Scorpus Harvester: Scorpus Harvester is a software utility that scans the sources of assets, extract the metadata required and provide the results back to the users. Harvesters provide the artifact types, extract interfaces, classes, methods, routines, sub-routines, and database models, calls made between the source codes internally and to the databases, web services registered in UDDI registries.
Note: In future Scorpus harvester will provide capability to relate requirements, design, business processes stored in office documents like word, excel with the source code and database.
The effectiveness of harvesting capability is determined by how crisply and clearly the context is defined.
Subsequent to the harvesting the assets need to be brought into "TO-BE-REUSED" form. This form entails the asset metadata to be created as defined by the asset structure model. The details are available as product features and can be referenced through the Scorpus product datasheet.

Inset: Example of Asset Harvesting based on a context set
The figure 9 depicts how a context based search lists references of the context element within source code repository. A feature "Create Reader" is set as a context element and the system scans the source code repository and the database repository to list all direct and similar references of the context element. It also depicts the relationship of the source code with other source code. The output of the scan results can be used by the users to identify the right source code and database elements for the asset context. The scan results could also help identify newer assets hitherto unknown. The selected source code, database elements along with their properties like classes, methods, routines, subroutines, relationships are created as metadata for the asset.
2. Creation of Assets in conformance to the governance model
Governance model for the creation and consumption is laid out during the planning stage
(section 2.2) of the reuse and asset management initiative. Once the asset structure and
organization is defined it is important to define the rules and methods for creation of each
type of asset. The rules and methods are defined within the triad of process, people and
technology.
The process can describe:
Sequence of activities to be followed for creating assets.
Integration with software development lifecycle processes.
Work products to be created or consumed.
Architecture definition to be mandated. (Deriving artifacts, models, etc from a
framework)
The technology can describe: Development Tools to be used Location to scan and store assets Mandatory technology to be followed

People can describe:
Roles to perform an activity defined in the process Roles to consume an activity defined in the process
Adherence to such governance model ensures integrity and correctness of the assets being created. Also Gating points can be described in the governance model wherein quality checks can be performed on the assets at various stages.
Scorpus supports the definition and enforcement of the governance model through its
Workflow manager and Workflow engine.
Workflow manager is used to define the governance model and integrate with
organizations eco-system of tools, process and technology.
Workflow engine controls, tracks and monitors the workflow in real time.
Inset: Example of governance model defined and enforcement through Scorpus
The figure 10 depicts the governance model created as a workflow in the Scorpus Workflow Manager. The workflow contains the sequence of activities to be carried out while creating an asset, the conditions and rules for the activity. Once the governance model has been defined, Scorpus workflow engine ensure the compliance and adherence to the model. In this example a scenario is depicted in figure 11 wherein a mandatory usage of a framework element is enforced while creating an asset. In this instance, a business process model created by a business analyst needs to be used as a mandatory derivation while the asset creator creates an asset of a solution framework.
Conclusion
Enterprise software asset management (ESAM) adoption strategy is holistic in its approach covering the various risk factors in the adoption stage and through the adaptation cycle. The risk factors are organizational specific and based on the business focus areas & goals, operations, technology, process maturity, availability of knowledge, legal, motivation of the personnel, software asset realization strategy, etc to list a few.

Though not all of them can be addressed by Scorpus, we have a pragmatic approach covering a lot of them through risk alleviation approach. We understand that the value of software assets will increase, if the same is sought, found, and used repeatedly within or across the organizational units. Scorpus ESAM has worked towards this and brings forth the 4 stage risk based approach to enable the software delivery organizations (SDO's) to:
1. Identify the assets.
2. Create and qualify the assets.
3. Manage the assets through the creation, usage, and change cycles.
a. In complete compliance to the SDO's delivery processes and activities.
b. In unification with the tools and methods to create software.
4. Search the assets using solution context, the taxonomy, or the keywords.
a. And download for consumption in the favoured tools and in compliance with the processes.

We claim:
1. A method to identify and create reusable assets, said method comprising steps of;
iii. defining a context for identifying assets;
iv. formulating structure and organizing the assets within the defined
context;
v. identifying candidate assets from the potential candidate assets and
thereby creating metadata in reuse repository; and vi. harvesting the metadata by using context based method to create
reusable assets.
2. The method as claimed in claim 1, wherein the context enables to set up a definitive and predictive model for identifying and creating assets.
3. The method as claimed in claim 1, wherein the context provides a reference for harvesting assets from existing sources and/or afresh.
4. The method as claimed in claim 1, wherein the defining context is based on recurring problem, solution or an architecture of product or solution.
5. The method as claimed in claim 1, wherein the structure of asset comprises;
i. identifying the type of asset; and
ii. formulating the metadata to be captured for each type of asset.
6. The method as claimed in claim 5, wherein the asset types determines the way an organization creates and consumes assets.
7. The method as claimed in claim 5, wherein the type of assets are created by using predefined structure and methods.
8. The method as claimed in claim 1, wherein organizing assets involves logically grouping a related set of assets under a given context.
9. The method as claimed in claim 1, wherein the context is selected from a group comprising business unit, solution or domain frame work, asset types and technology.
10. The method as claimed in claim 1, wherein the identification of candidate is carried out by either top down approach or middle out approach.
11. The method as claimed in claim 10, wherein the top down approach comprises well defined architecture and frame work to create assets.

12. The method as claimed in claim 11, wherein the architecture is decomposed into several layers of granularity.
13. The method as claimed in claims 1, 10 and 12, wherein the top down approach enables for
i. identifying assets at various levels of granularity within the boundaries
of the context set; ii. creating stubs of assets which is created at each granularity level; and iii. optionally performing a return on Investment analysis on the identified
assets;
14. The method as claimed in claim 10, wherein the middle out approach is followed for identified assets having unrecognized assets.
15. The method as claimed in claim 1, wherein the metadata harvested from existing sources comprises;

• Artifact Name;
• Artifact type based on file extensions;
• Artifact category preferably business process models, software execution workflows, requirements, design, source code, test cases;
• Artifact relationships and interrelationships with other artifacts;
• Artifact location preferably version control systems, windows file systems;
• Interfaces, Classes, methods, routines, sub-routines in case of source code;
• Database models ;
• Calls to other classes, methods, routines, sub-routines, database sources in case of source code; and
• Web services registered in UDDI registry.
16. The method as claimed in claim 1, wherein the harvesting of the metadata is carried
out by either manually or by using automated harvester.

17. A system to identify and create reusable assets comprising:
i. a processor to formulate organization and structure of the assets within
a defined context; identifying candidate assets from the formulated assets and thereby creating metadata in reuse repository; and optionally defining rules and methods for creation of each type of assets; and harvesting the metadata to create reusable assets;
ii. a database to store the reusable software asset and data representative of the mapping, wherein database stores the data and the reusable software asset in a searchable form and provides access to the reusable software asset for retrieval of the software artifacts within the one or more repositories
iii. a search engine for selecting reusable assets using solution context/keywords/taxonomy/asset type; and
iv. an user interface to download the assets for usage.
18. A method and system to identify and create reusable assets substantially as herein
above described with reference to the accompanying drawings.