DRAFT PAPER: THE SMART METHOD
Vermeer, Floor, 3849821, Group 2, University of Utrecht, Princetonplein 5, Buys Ballot
Laboratorium, 3508 TB Utrecht, The Netherlands, f.e.vermeer@students.uu.nl
1 Introduction
The Service–oriented Migration and Reuse Technique (SMART) is used for determining which legacy
systems can be used as services in a Service Oriented Architecture (SOA) (Lewis, Morris, O'Brien,
Smith, & Wrage, 2005). The goal of this method is for organizations to reuse or migrate the existing
legacy system to a SOA environment. Reusing a legacy system can be defined as integrating the
existing system into a SOA environment using a wrapper or enterprise service bus, while migrating
legacy systems is the process of moving a legacy system to a new system and restructuring it where
needed (Umar & Zordan, 2008). The method provides tasks and suggests documents in order to
identify the context, identify the current system capabilities, describe the target SOA system state,
analyze gaps between the current and target state and describes the steps needed in order to create a
migration strategy (Lewis G. , Morris, Smith, & Simanta, 2008). The SMART process is as follows:
Figure 1: the SMART method elements. Adapted from: (Lewis et al. , 2008).
As can be seen in the above figure, the method consists of six main activities and one decision point.
The first activity, Establish context, is executed in order to establish what the goal for the migration is
and who the stakeholders are. A preliminary identification of candidate services is also done. In the
following decision point, the Project team determines if the migration is feasible, has potential or is
not feasible. If the migration is not feasible the project is cancelled. When the migration has potential,
the previous step is repeated in order to gather more information. If the migration is feasible the
activities Candidate services, Describe existing capabilities and Describe the target SOA state are
executed. The goal of the Candidate service activity is to determine which services are part of the
migration or reuse project. The activity Describe existing capability is executed in order to identify the
legacy components that are part of the migration project. Furthermore, during the Describe target SOA
state activity information is gathered about the target SOA environment, such as the major
components and technologies. In the next step the gap between the current system state and target
SOA state is analyzed. Based on this analysis the options for migrating or reusing legacy components
to the target SOA environment are created. In the final step the strategy for transferring to a SOA
environment is created. The strategy includes among others the migration path, guidelines, feasibility
and risk of the migration or reuse project.
The method originates from the Option Analysis for Reengineering method, which was used to
support the analysis for the possible reuse of software components (Bergey, O'Brien, & Smith, 2002).
The method is developed by the Software Engineering Institute at the Carnegie Mellon University.
The main activities of the Software Engineering Institute is to perform applied research in
collaboration with their research partners The research of the Software Engineering Institute varies
from Intelligence and Forensics to Ultra-Large Scale Systems. Furthermore, it is funded by the U.S.
Department of Defense (DoD), who decided to adopt this method for their systems (Bergey et al.,
2002).
The next chapter provides an example of the SMART method. The third chapter describes the origin
of the method and related work. The fourth chapter provides the Process Deliverable diagram(PDD) of
this method. The fifth chapter contains an activity table, describing all activities in the PDD and the
sixth chapter provides the concept table, which contains a description of all concepts in the PDD. The
seventh chapter provides the references of the literature used in this document. In Appendix A a
template for the service table concept is provided.
2 Example
This chapter describes an example of how the SMART method can be applied. The example describes
a Dutch municipality that wants to analyze the potential reuse of their legacy systems to a SOA
environment. While the method describes that the method fragments do not have to be performed sub
sequentially and can be performed simultaneously, this example will describe the method fragments in
a logical order for clarity reasons. Furthermore, the actions in this example are performed by the
SMART project team, further referred to as ‘The project team’.
2.1
Establish context
The system administrators are identified as stakeholders in the role of owner, a senior user is
appointed to represent the current and future users of the system and an external consulting firm is
identified as a stakeholder in the role of developer of the legacy systems. The stakeholders are
interviewed using the system migration interview guide (SMIG) (Lewiset al., 2008). The system
administrators explain that the goal of the migration is to provide more interoperability within the
system handling permit requests and the application that handles the basic registration database of the
municipality. The system administrator explains that the current systems do not support the reuse of
data. One of the business processes that is affected by this constraint is the Permit Request process,
because it is not possible to extract data that is already available in other systems. The legacy
components related to this business process are identified and put into the business process-service
mapping document.
Furthermore, during this method fragment the project team makes a characteristics list to identify for
which system components information needs to be gathered. A preliminary list containing migration
issues is also created. This list contains possible issues that can arise during the migration process,
such as privacy issues. These two lists are updated throughout the SMART process when needed.
2.2
Migration feasibility decision and candidate Services
After the context was described, it was immediately determined there is a very clear goal for the
project and the reuse of legacy components is feasible.
During the interviews with the senior user, it became clear that in order to file a permit, the personal
information of the citizen or organization has to be registered again, instead of using the already
available data in the basic registration database. Therefore, the candidate services in this example are
related to extracting data from the Basic Registration database. The candidate services are put into a
service table. At this point a service table can look as follows:
Name
Description
Associated
Inputs
Outputs
legacy
QoS
requirements
component
Load_data_citizen
Loads the citizen data
Citizen_
Citizen_N
Has to be
BSN
ame,
available
Registration database
Citizen_Bi
Monday to
to a connected desktop
rthdate,
Friday from
application
Citizen_ad
9:00 to 17:00
ress, …
and 9:00 to
from the Basic
BGA
21:00 on
Thursday
Load_data_Organi
Loads the data of an
zation
BAG
Chamber
Building_
Has to be
organization from the
ofComme
Address,
available
Basic Registration
rceNumb
Building_
Monday to
database to a
er
Owner, …
Friday from
connected desktop
9:00 to 17:00
application
and 9:00 to
21:00 on
Thursday
Search_Citizen
Provides a search
BGA
Citizen_
Citizen_na
Has to be
service to look for
Name,
me,
available
citizens in the Basic
Citizen_
Citizen_A
Monday to
registration database
Birthday,
ddress,
Friday from
Citizen_P
Citizen_bi
9:00 to 17:00
ostcalcod
rthday
and 9:00 to
e
21:00 on
Thursday
…
….
…
…
…
…
Table 1: A Service table
2.3
Describe existing capabilities
The main goal of this method fragment is to gather descriptive data about existing systems, such as
age, capacity and operating platform. This information is extracted from the system administrators.
The external consulting firm is interviewed about the architecture of the systems, design paradigms,
code complexity, level of documentation, module coupling, interfaces for systems and users and
dependencies on other components or commercial products (Lewis, Morris, O'Brien, Smith, & Wrage,
2005).
The systems at the municipality are hosted on a Windows server platform. The applications are made
using a .NET programming language with around 200.000 lines of code. The architecture of the
systems is not formally documented, but the consultants of the external firm are able to distinguish
components in the system if needed. The systems use an Oracle database to save data in. The current
system configuration is depicted in the following picture:
Figure 2: The current system configuration
As can be seen in Figure 2, the users of the system can access the permit application data and basic
data through a desktop application. The databases are not connected in any way and therefore data
from the Basic Registration server cannot be reused in the permit application. The project team creates
a component table that includes information about the components considered for migration and the
characteristics (from the characteristics list). The migration issue list is updated with an entry about the
missing architecture documentation.
2.4
Describe the target SOA state
In order to implement the selected services, the configuration of the current system has to be changed.
The goal of this step is to create the notational service oriented architecture based on the candidate
services and legacy components. The notational service oriented architecture depicts the target SOA
environment. The new system configuration of the example is depicted in Figure 3.
Figure 3: New system configuration
As can be seen in the picture, the services (CS) have replaced the physical systems in the depiction.
CS 1 provides an example of how services can reuse and support interoperability of services. In this
example CS 1 is a standard interface that can extract data from the Basic Registration database and
load it into any desktop application that is linked to the service. All services that need to be included in
the SOA architecture are put in the service table.
2.5
Analyze gap
In collaboration with the external consulting firm, the project team reconstructed the architecture by
analyzing the existing system (Kazman, O'Brien & Verhoef, 2003; O'Brien, Stoermer & Verhoef,
2002). The project team is then able to estimate the cost, effort and risk for migrating the components
to services or to build the services from scratch. These estimates are put in the service-component
alternative concept.
2.6
Develop migration strategy
The project team decides to construct a wrapper around their legacy systems in order to reach a quick
solution (Sneed, 2006). The services that are created by the wrapper include the loading and saving of
data. The results of the method are put in a service migration strategy document and presented to the
relevant stakeholders.
3 Related literature
The SMART method originates from the Option Analysis for Reengineering Method (Bergeyet al.,
2002). The option analysis method is developed in order to identify reusable software components in
older systems. The first version of the SMART method described the method fragments and
deliverables of the method (Lewis et al, 2005). Since then the method has been elaborated on by
adding a detailed process for the method and providing tools for using the method, such as the SMIG
and an automated tool to support the method (Lewis et al, 2008).
Much research is done on the subject of SOA migration, e.g. (Umar & Zordan, 2008; Razavian &
Lago, 2010; Sneed, 2006; Canfora, Fasolino, Frattollilo, & Tramontana, 2008). For instance, Sneed
(2006) and Canfora, Fasolino, Frattollilo and Tramontana (2008) describe a wrapping approach for
reusing legacy systems in a SOA architecture. The wrapping approach is based on building a ‘shell’
around a legacy systems that provides a service interface and interacts with the legacy system. Another
research developed a decision model for determining if a legacy component should be integrated or
migrated (Umar & Zordan, 2008). Razavian and Lago (2010) provide a conceptual framework for
understanding what needs to be included in a SOA migration project. Comparing the SMART method
to other research, it provides an overall process to determine what services to implement and with
which method (e.g. reuse or migration) and is limited in how to actually transform a legacy component
into a SOA environment (Razavian & Lago, 2010).
There are several cases where this method is applied. The creators of the method provide an example
at the Department of Defense for a migrating a mission status system (Lewis et al., 2008). In their
example, the method is executed according to the steps described earlier in this document. As a result
of the project a migration strategy was documented which describes the possibilities for migrating the
legacy system. Another example is provided in the research of Razavian and Lago (2010), who briefly
describe the method in a migration for a flight booking system. Furthermore, Lewis and Smith (2008)
provide a description for the usage of the SMART tool that has been developed to support the SMART
process.
4 Process Deliverable Diagram
Figure 4 is the Product Deliverable Diagram (PDD) for the Service migration and Reuse technique
(SMART) method (Lewis et al., 2008). The PDD illustrates which activities are performed and which
concepts are created during a method (van de Weerd & Brinkkemper, 2008). The left side of the
method shows the activities that are performed. Six main activities and three decision point can be
identified. On the right side of the PDD the concepts created during this method are shown. The work
of Weerd and Brinkkemper (2008) explains the notations used in this diagram. In the sections
following the PDD additional rules, activities and concepts are explained.
TARGET SOA
ENVIRONMENT
STAKEHOLDER LIST
Status
Technology
Main
components
History
1..*
Establish migration context
Understand business and technical context
LEGACY
SYSTEM
Identify stakeholders
1
CHARACTERISTICS
LIST
Gather basic information
Identify candidate services
1..*
1..*
Create migration issue list
Main
functionality
Size
Technology
Age
History
Users
Is elaborated in
[Migration has potential]
1
MIGRATION ISSUE LIST
1..*
[Migration not feasible]
BUSINESS-PROCESS
SERVICE MAPPING
[Migration feasible]
1
Is addressed in
Is elaborated in
Define candidate services
Is associated with
1..*
Select candidate services
SERVICE TABLE
Specify candidate services
Candidate service
Service input
Service output
Quality of service
requirements
1..*
1..*
DESCRIPTIVE
DATA
Name
Function
Size
Language
Operating
platform
Age
1..*
1
Describe existing capability
Interview technical personnel
COMPONENT
TABLE
1..*
ARCHITECTURE
VIEW
1..*
DESIGN
PARADIGM
1
1..*
1..*
SYSTEM QUALITY
1..*
CHANGE
HISTORY
1..*
USER
STATISFACTION
1..*
EXISTING
PROBLEM
1
Describe target SOA environment
NOTIONAL SERVICE
ORIENTED
ARCHITECTURE
Gather information
1
1..*
1..*
SERVICE
CONSUMER
INFRASTRUCTURE
COMPONENT
Analyze gap
1..*
Estimate risk
INTERACTION
Estimate effort
Estimate cost
Create service-component
alternatives
Develop migration strategy
Develop migration strategy
SERVICE-COMPONENT
ALTERNATIVE
0..*
GUIDELINE
1
MIGRATION
STRATEGY
Feasibility
Risk
Order
1
0..*
0..*
Figure 4: Process deliverable diagram of the SMART method
0..*
MIGRATION ISSUE
GUIDELINE
0..*
SERVICE REFERENCE
ARCHITECTURE
1..*
MECHANISM
GUIDELINE
1..*
OPTION FOR
SOURCE CODE
NEED FOR ADDITIONAL
INFORMATION
MIGRATION
PATH
1
1..*
OPTION
1..*
4.1 Rules and issues
This section describes additional rules that are not modelled in the PDD.

All the activities are performed by a SMART project team (Lewiset al., 2005).

The activities Define candidate services, Describe Existing Capabilities and Describe Target
Environment are supported by the Service Migration Interview Guide (SMIG). The SMIG
contains questions that can help to gather information and interview relevant personnel (Lewis
et al., 2008).

The STAKEHOLDER LIST, CHARACTERISTICS LIST, MIGRATION ISSUE LIST,
BUSINESS PROCESS-SERVICE MAPPING, SERVICE TABLE, COMPONENT TABLE,
NOTIONAL SERVICE ORIENTED ARCHITECTURE and SERVICE-COMPONENT
ALTERNATIVE concepts are created in the related (sub)activity and are updated throughout
the method when needed.

The main activities of this method are described as iterative. This means that based on the
output of one activity, a previous activity might have to be reexecuted.
5 Activity table
Table 2 gives an explanation of the activities and sub-activities that are depicted in the PDD. The
explanation that is given is based on the description of the method by Lewis et al. (2008).
Activity
Sub-activity
Description
Establish migration context
Understand business and
The rationale, goals and expectations are identified for the
Technical context
migration project. Furthermore, earlier SOA projects and constraints
are investigated.
Identify stakeholders
The stakeholders that are responsible for funding and driving the
project, have knowledge about legacy systems and the target SOA
environment, and stakeholders who create a demand for a SOA
environment are identified. The identified stakeholders are put in a
STAKEHOLDER LIST.
Gather basic information
Basic information about the legacy systems and target soa
enviroment is gathered and is put in a CHARACTERISTICS LIST.
Identify candidate services
Candidate services are identified based on business goals,
processess and the supporting legacy systems for these aspects. The
candidate services are put in a BUSINESS-PROCESS SERVICE
MAPPING together with the current businness processess.
Create migration issue list
During this activity a list with possible migration issues is created.
This list is further updated throughout the method when needed.
Define candidate services
Select candidate services
Several candidate services are selected from the previously
identifies candidate services for the migration project.
Specify candidate services
The selected candidate services are specified with service in- and
outputs and quality of service requirements. The specified services
are put into a SERVICE TABLE.
Describe existing capabilities
Interview technical personnel
Technical personnel is interviewed about the technical environment
and the legacy systems that provide the functionality that is needed
for the candidate services. Information from the technical personnel
is retreived regarding descriptive data (e.g. name and function ),
Architecture views, Design paradigms, System quality, Change
history, User statisfaction and existing problems. Based on the
gathered information, a COMPONENT TABLE is created (Lewis et al.,
2008).
Describe target SOA
Gather information
environment
Information is gathered about the target SOA environment, which
includes the major components, guidelines for implementation,
interaction patterns and quality of service requirements. Based on
this information the NOTIONAL SERVICE ORIENTED ARCHITECTURE
is created.
Analyze gap
Estimate Risk
During this sub-activity, the risk is estimated for converting the
legacy components into services.
Estimate effort
During this sub-activity, the effort is estimated for converting the
legacy components into services.
Estimate cost
During this sub-activity, the cost is estimated for converting the
legacy components into services.
Develop migration strategy
Create service component
During this step it is determined which functionality of legacy
Alternatives
components is needed to create the services.
Develop migration strategy
Based on the information gathered in the previous steps a
MIGRATION STRATEGY is developed.
Table 2: Activity table of the smart method
6 Concept table
Table 3 explains the concepts used in the PDD.
Concept
Description
STAKEHOLDER LIST
The STAKEHOLDER LIST contains information about the stakeholders of the migration project.
The stakeholders list includes managers, user representatives, system developers , system
architects and sponsors of the project (Lewis et al., 2008).
CHARACTERISTICS LIST
The CHARACTERISTICS LIST is composed of information about LEGACY SYSTEMs and the TARGET
SOA ENVIRONMENT. It contains information regarding all basic characteristics of these systems,
such as main functionality, size and age (Lewis et al., 2008).
LEGACY SYSTEM
This concept contains basic information about the existing legacy systems. A legacy system is a
system that has been developed in the past for substantial costs (Bergey, Smith, & Weiderman,
1999). The information regarding main functionality, size, technology, age, history and users is
stored. This information is used later in the method as a possible determinant for deciding if the
migration is feasible.
TARGET SOA ENVIRONMENT
In this concept basic information about the target soa environment, including status,
technologies, main components and history, is stored (Lewis et al., 2008).
BUSINESS-PROCESS SERVICE
The BUSINESS-PROCESS SERVICE MAPPING depicts the linkage between the current business
MAPPING
processess and the candidate services (Lewis et al., 2008). The candidate services that are
selected for migration are elaborated in the SERVICE TABLE.
MIGRATION ISSUE LIST
This list containts all possbile issues that can arise during the migration. Possible issues can be
related to e.g. limited functionality of legacy systems or contradictory business goals (Lewis et
al., 2008).
SERVICE TABLE
The service table describes the candidate services and provides information about service input
and outputs and requirements for the quality of the service. Services are defined as: ”Reusable
components that represent business or mission tasks” (Lewis et al., 2008, p. 2). The services in
this table are input for the NOTATIONAL SERVICE ORIENTED ARCHITECTURE.
COMPONENT TABLE
The COMPONENT TABLE contains detailed information about the legacy systems that are
included in the migration project (Lewis et al., 2008). The components are input for the
NOTATIONAL SERVICE ORIENTED ARCHITECTURE.
NOTIONAL SERVICE ORIENTED
The NOTIONAL SERVICE ORIENTED ARCHITECTURE is an illustration of how the target SOA
ARCHITECTURE
environment will be configured.It consists of SERVICE CONSUMER(s), INFRASTRUCTURE
COMPONENT(s), SERVICE(s), COMPONENT(s) and INTERACTION(s) between these components
(Lewis et al., 2008).
SERVICE CONSUMER
The SERVICE CONSUMER concept represents the entities that use a service.A service consumer
is defined as: ”Clients for the functionality provided by the services” (Lewis et al., 2008, p. 2).
INFRASTRUCTURE COMPONENT
The INFRASTRUCTURE COMPONENT(s) make up the infrastructure of the target SOA
environment. The INFRASTRUCTURE COMPONENT(s) connects the SERVICE CONSUMER(s) to
the actual SERVICE(s). Microsoft IIS and ASP.NET are examples of infrastructure components
(Lewis et al., 2008).
INTERACTION
The INTERACTION concept illustrates the interactions between the LEGACY COMPONENT(s),
SERVICE(s), INFRASTRUCTURE COMPONENT(s) and SERVICE CONSUMER(s) (Lewis et al., 2008).
SERVICE COMPONENTS
The SERVICE COMPONENTS ALTERNATIVE concept provides information about which technique
ALTERNATIVE
to use in order to realize the candidate services. Examples of SERVICE COMPONENT
ALTERNATIVEs are a wrapper approach, replace or renew legacy component, (partially) rewrite
the code of the legacy system (Lewis et al., 2008).
MIGRATION STRATEGY
The MIGRATION STRATEGY describes the strategy for adjusting the legacy components to the
target SOA environment. The MIGRATION STRATEGY describes the feasibility, risk and options
for executing the migration strategy. The MIGRATION STRATEGY may include GUIDELINEs, the
MIGRATION PATH and NEED FOR ADDITIONAL INFORMATION (Lewis et al., 2008).
MIGRATION PATH
The MIGRATION STRATEGY desrcibes in which path the migration will be executed. The
MIGRATION PATH may consist of one or more OPTIONs. For example, a MIGRATION PATH
describes that a wrapper will be developed around a legacy system initially, followed by the
creation of a whole new system (Lewis et al., 2008).
OPTION
An OPTION represents a solution for transferring the legacy system to the target SOA
environment. Such an solution might be a wrapping approach or rewriting (pieces) of code
(Lewis et al., 2008).
NEED FOR ADDITIONAL
Any need for additional information or training is represented by this concept. Market
INFORMATION
information or the need for a workshop or training are examples of this concept (Lewis et al.,
2008).
GUIDELINE
The GUIDELINE is used to help with creating and identifying services. The concept is an
aggregation of the MIGRATION ISSUE, SERVICER REFERENCE ARCHITECURE, MECHANISMs and
OPTION FOR SOURCE CODE concepts (Lewis et al., 2008).
MIGRATION ISSUE GUIDELINE
An MIGRATION ISSUE GUIDELINE might be needed if there is a specific migration issue (from the
MIGRATION ISSUE LIST) that needs to be supported by a guideline (Lewis et al., 2008).
SERVICE REFERENCE
The SERVICE REFFERENCE ARCHITECTURE is used to separate service components into layers.
ARCHITECTURE
This concept is used when constant change or unstablity of certain components is expected.
Examples of SERVICE REFERENCE ARCHITECTURE layers are Service interface layer and service
code layer. (Lewis et al., 2008).
MECHANISM GUIDELINE
The MECHANISM GUIDELINE concept supports the creation of specific techniques used to
transfer the legacy systems to the target SOA environment, such as a wrapping approach or
rerwiting (pieces) of code (Lewis et al., 2008).
OPTION FOR SOURCE CODE
The OPTION FOR SOURCE CODE concept describes which code from other systems can be
reused to create the selected services, such as the legacy system or commercial products (Lewis
et al., 2008).
Table 3: Concept table of the SMART method
7 References
Bergey, J., O'Brien, L., & Smith, D. (2002). Using the Options Analysis for Reengineering (OAR)
method for Mining Components for a Product Line. Proceedings of the Second Software Product Line
Conference (SPLC2). San Diego: Springer. 316-327.
Bergey, J., Smith, D., & Weiderman, N. (1999). DoD Legacy System Migration Guidelines. Pittsburg:
Software Engineering Institute, Carnegie Mellon.
Canfora, G., Fasolino, A. R., Frattollilo, G., & Tramontana, P. (2008). A wrapping approach for
migrating legacy system interactive functionalities to Service Oriented Architectures. The Journal of
Systems and Software , 81 (4), 463-480.
Clarkson, M. (1995). A Stakeholder Framework for Analyzing and Evaluating Corporate Social
Performance. The Academy of Management Review , 20 (1), 92-117.
Kazman, R., O'Brien, L., & Verhoef, C. (2003). Architecture reconstruction guidelines, 2nd edition.
Pittsburgh: Software Engineering Institute, Carnegie Mellon University.
Lewis, G., & Smith, D. (2008). SMART Tool Demonstration. 12th European Conference on Software
Maintenance and Reengineering. Athens: IEEE. 332-334
Lewis, G., Morris, E., O'Brien, L., Smith, D., & Wrage, L. (2005). SMART: The Service-Oriented
Migration and Reuse Technique. Pittsburg: Software Engineering Institute, Carnegie Mellon
University.
Lewis, G., Morris, E., Smith, D., & Simanta, S. (2008). SMART: Analyzing the reuse potential of legacy
components in a service-oriented architecture environment. Pittsburgh: Software Engineering
Institute, Carnegie Mellon University.
O'Brien, L., Stoermer, C., & Verhoef, C. (2002). Software architecture reconstruction: Practice Needs
and Current Approaches. Pittsburgh: Software Engineering Institute, Carnegie Mellon University.
Razavian, M., & Lago, P. (2010). Understanding SOA migration using a conceptual framework. Journal
of Systems Integration , 1 (3), 33-44.
Sneed, H. (2006). Wrapping legacy software for reuse in a SOA. Proceedings of the 10th European
Conference Bari: IEEE. 3-14.
Umar, A., & Zordan, A. (2008). Reengineering for Service Oriented Architecure: A strategic decision
model for integration versus migration. The Journal of Systems and Software , 82 (3), 448-462.
van de Weerd, I., & Brinkkemper, S. (2008). Meta-modeling for situational analysis and design
methods. Handbook of research on modern systems analysis and design technologies and
applications , 38–58.
8
Name
Appendix A: Service table template
Description
Associated
legacy
component
Inputs
Outputs
QoS
requirements