Enterprise Service Bus (ESB) - Guide to Cloud Computing for Business and Technology Managers - page 208

These three broad phases comprise a series of six steps briefly described
in the following:
1. Understanding existing applications : Before beginning the moderniza-
tion process, the first task is to understand the structure and archi-
tecture of the existing application's architecture. This task includes
gathering statistics about size, complexity, the amount of dead or
unused code, and the amount of bad programming for each applica-
tion. In addition, in selecting which programs to improve together,
selecting the ones that affect common data is a critical step when
planning to move through all of the modernization stages, including
reengineering for reuse and/or migration.
2. Rationalizing business logic : A typical legacy system is composed of
a large number of independent programs. These programs work
together in a hardwired net of business process flows. Once an appli-
cation's program code is clean, any programming anomalies have
been removed, and nonbusiness logic has been filtered, it is possible
to apply pattern-matching techniques across all of the application's
programs to identify and segregate candidate common business
logic.
3. Identifying business rules : When candidate reusable business logic has
been rationalized to a subset of distinct, single occurrences of each
service, it is then possible to determine whether each should become
part of a process or express a business rule. For a definition and
examples of use of business rules, refer to Section 9.2 “Event-Driven
Nature of ESB”. To achieve this, sophisticated algorithms are used to
extract business rules from monolithic legacy systems within which
business rules exist in many different guises. The extraction of busi-
ness rules from legacy code is generally termed business rule recov-
ery. The accuracy with which this task is performed is key to legacy
application modernization.
4. Extracting components : Extracted business rules can be grouped
together based on their contribution to achieve the intended business
functionality. A group of rules is normally processing some com-
mon set of data to achieve intended business functions. Candidate
business rules and associated business data are then extracted and
appropriately represented as a cohesive legacy component. The
number of rules that need to be grouped together is a matter of
choice, depending on the desired granularity of the legacy compo-
nent. A callable interface needs to be provided for these components.
5. Wrapping component implementations : Legacy systems were, for the
most part, not implemented in a fashion that lends itself to componen-
tization. Presentation logic is often intertwined with business logic,
which is intertwined with systems and data access logic. During