software modernization and legacy migration primer

Software Modernization. It’s all we do!!! PAGE 1 OF 42

SOFTWARE MODERNIZATION - POWERED BY MODELING

M E M B E R

www.adasoftusa.com

379 THORNALL STREET, WEST TOWER - 7TH FL, METROPARK, NJ 08837

Call

888.453.0014

Software Modernization

— Using Model Driven

Architecture

Informational Primer

Call

888.453.0014 ADA SOFTWARE

The automated software modernization company

Special Section on

CLOUD

COMPUTING



TABLE OF CONTENTSTABLE OF CONTENTSTABLE OF CONTENTS

Special Section on

CLOUD COMPUTING

7

EXECUTIVE SUMMARY 5

Modernization in Demand 5

Automated is Better 5

OMG Standards 5

Innovative Solutions 5

SOFTWARE MODERNIZATION BASICS 6

What is Software Modernization 6

What is Software Migration? 6

Platform Migration 6

Language Migration 6

Database Migration 6

User Interface Migration 6

Hardware Migration 6

Why does Software need Modernization? 7

Common Examples 7

It Need Not be Old 8

Reasons for Modernization 8

Difficulty 8

Cost 8

Lack of Integration 9

Competitive Pressure 9

New Business Models 9

Mergers & Acquisitions 9

Inefficiency 9

Lack of Business Agility 9

Traditional Choices 9

1) Rewrite 9

Unbearably Long Time 9

Humungous Cost 10

Introduction of New Bugs 10

2) Discard and Build Afresh 10

Discarding Baby with the Bath Water? 10

3) Adopt Packaged Solution 10

Better: Automated Transform 10

AUTOMATED SOFTWARE MODERNIZATION 10

What is Automated Software Modernization? 11

Modeling Shows the Way 11

Our Automated Modernization Methodology 12

Reverse Engineering 12

Forward Engineering 12

Explaining Model Driven Architecture (MDA) 13



What is a Model? 13

What is a Metamodel? 14

The Evolution of "MDA" 15

MDA Begins with Business 15

MDA Then Adds Technology 15

MDA Then Generates Code 16

The MDA Stack 16

Significant Benefits of MDA 16

Maintainable Business Model 16

Cost Savings 17

Business Agility 17

Institutionalization of Knowledge 17

Future Proof Investment 18

More Powerful I.T. Department 18

Using MDA and ADM for Software Modernization 19

ADM: Architecture Driven Modernization 19

How does ADM Prevent Silos? 20

ADM Process Defined 20

1) Build the Metamodel 20

2) Recover the Design 20

3) Build the Blueprint Hypermodel 20

4) Assess and Strategize 21

5) Select Modernization Option 22

Full Platform Migration 22

Modernization via Partial Migration 22

Modernization without migration 22

6) Implement Methodology 24

Platform Selection 24

Determining Software Architecture 24

Web-enable the New App (Optional) 24

Migrate to a New Database (Optional) 25

Generate Code 25

Code Enhancement & Refactoring 25

Generate Dynamic Documentation 25

INNOVATIVE APPLICATIONS OF MDA 26

Harnessing your Excel Assets 26

Cloud Computing - Using MDA 27

23% of Companies 27

Microsoft, Google, Amazon 27

What is Cloud Computing 27

Deployment in the Cloud 27

Same as Virtualization? 28

Many Flavors of Cloud 28

Software as a Service (SaaS) 28

ACTIONABLE

INTELLIGENCE

from

UNSTRUCTURED DATA

3



Platform as a Service (PaaS) 28

Infrastructure as a Service (IaaS) 29

Challenges of Deploying 29

Proprietary Nature of Clouds 29

Google App Engine 29

The Amazon Cloud 30

Transaction Processing in the Cloud 30

Primary Key Management 31

Sensitive Data Handling 32

Deploying Using MDA 32

Disaster Recovery in the Cloud 32

Make Unstructured Data Come Alive 33

Understanding ―Unstructure‖ 34

Solutions Strategy 34

Applying OMG Standards 34

Parts of the System 35

Scanners & Parsers 35

Automatic Categorizers 35

Knowledge Retrieval Engine 35

Entity Extraction 35

Fact Extraction 35

Packaging & Delivery Engine 36

Practical Applications 36

E-Discovery from Emails 36

Other Regulatory Compliance 38

Research & Development 38

Law Firms 38

Content Publishers 38

Intelligence & Law Enforcement 38

Document Old Software... Automatically 39

INDUSTRY TRENDS: 2009-2010 40

TRIBUTE TO OUR FOUNDER: DK BOSE 41

CONTACT 42



S oftware modernization is usually the

r e m e d y w h e r e v e r s o f t w a r e

maintenance costs are high, business

agility is low, integration is poor or

interoperability is deficient - which are also the

commonest problems affecting most companies.

MODERNIZATION IN DEMAND

Hence the appetite for software

modernization is high and budgets are beginning

to recognize the need. Forrester Research

recently published that application modernization

and migration budgets account for 25% to 61% of

most companies‘ IT budgets in 2009/2010.

AUTOMATED IS BETTER

Traditional software modernization

alternatives involving brute force rewrite, new

development or replacement by packaged ERP

are all costly, time consuming and inaccurate

solutions that discard years of goodness

inculcated into legacy software assets.

Automated software modernization is the best

solution that is fast, low cost, preserves legacy

value and is least risky.

OMG STANDARDS

OMG‘s Model Driven Architecture (MDA)

methodology provides an automated model-

driven reverse engineering and forward

engineering process called Architecture Driven

Modernization (ADM) which has already been

successfully adopted by a variety of high profile

organizations such as Boeing, U.S. Air Force,

Raytheon, EDS, Thales (European Aerospace)

and governments.

Our process involves building a

Metamodel of your source languages and using

our parsing technology (based on OMG‘s

Knowledge Discovery Metamodel) to extract all

system information, business semantics and

software artifacts into an XML Repository called

the Abstract Syntax Tree Metamodel. From here

we use MDA‘s automated model-to-model (M2M)

transformation procedures to generate a new

source code of your choice. In between, we

manually architect the target application before

setting up the M2M procedures. So you get the

best of both worlds: the speed, low cost and

accuracy of an automated process, and the

flexibility of human

inte l l igence. The

process is language

independent and domain agnostic.

INNOVATIVE SOLUTIONS

We are applying MDA not only for

software modernization and migrations, but also

in many innovative ways to help you harness

your Excel sheets that are running out of control

everywhere; make Cloud Computing easier for

you By helping to port your apps to the Cloud or

from one Cloud to another; document your old

software automatically; making your email

archives come alive with on-demand knowledge

mining; and so on.

EXECUTIVE SUMMARYEXECUTIVE SUMMARYEXECUTIVE SUMMARY



S oftware modernization is the process

of making technological and/or

functional changes to a software to

make i t modern , robus t or

interoperable. It may involve some or all of the

following:

Migrating to a new platform, new language,

new database or new transaction processing

monitor.

Modernizing only the presentation layer, the

process layer, the business rules later, the

data access layer or the database layer.

Re-engineering the architecture, including

SOA enablement and enhanced

interoperability.

Refactoring the code.

Problem remediation.

Improving the functionality.

WHAT IS SOFTWARE MIGRATION?

Migration involves movement. In this

case, it involves the movement of software from

one technology, architecture, stage, or form to

another.

PLATFORM MIGRATION

This involves moving an entire software

application, including code and data, from one

hardware/software platform to another..

Example: From IBM Mainframe COBOL/

CICS/DB2/VSAM platform to Intel-based

Windows Micro Focus COBOL platform with

Oracle database.

LANGUAGE MIGRATION

This involves converting software source

code from one programming language to

another.

Example: Converting Visual Basic 6

programs to C#.

DATABASE MIGRATION

This involves converting only the

database (or data handling) parts of a software

from one type of data storage to another, leaving

the rest of the software virtually unchanged.

Example: Replacing IDMS database with

Oracle database. If the application uses flat files,

these may also be optionally converted to Oracle

tables.

USER INTERFACE MIGRATION

This involves converting only the data

input/output parts of the software to a new kind of

user interface.

Example: Converting PC desktop user

interface to a Web Interface.

HARDWARE MIGRATION

This is usually called ―porting‖ and

involves moving a software from one hardware

platform to another. What actually happens is

that the software has to be ported to a new

Operating System.

Example: Moving from DEC VAX-11/780

hardware to Intel-based PC servers and

desktops. In this case, the software is ported

from VAX OpenVMS to Windows XP/Vista.

What is Software Modernization?

SOFTWARE MODERNIZATION BASICSSOFTWARE MODERNIZATION BASICSSOFTWARE MODERNIZATION BASICS



A ll software needs maintenance,

which means modification for func-

tionality enhancements, error correc-

tion, introduction of new business

rules, accommodation of new technologies and

so on. During the process of maintenance, while

software applications become more feature rich,

and appear better to users, the internal structure

often deteriorates., because documentation

worsens over time and leads programmers to

make mistakes (some of which may remain un-

detected), or perform shoddy

patch work that implements

the necessary changes with-

out fully understanding how it

will impact the whole software,

or the maintenance program-

mer may simply not have the

qualification to handle the change but does it

somehow anyway. Through such repeated inju-

ries to the structure over time, a software applica-

tion can become bloated or difficult to maintain

any further or too costly to maintain or slow or

error-prone or - more often - all of the above.

COMMON EXAMPLES

1. An old COBOL application running on IBM

Mainframes has many problems: (a) It does

not have the modern user interface that

makes people more productive. (b) We can-

not justify the cost of operating an IBM Main-

frame environment when the same work can

be accomplished on a powerful Windows

Server. (c) It is very difficult and costly to find

experienced COBOL programmers to main-

tain the software. (d) Marketing is demanding

Extranet and Web Service facilities for cli-

ents, because our competition offers those

facilities.

2. An old application written in ‗C‘, which runs

some core production floor processes, used

to be such a wonderful asset for the com-

pany. But now it is taking forever to make

simple changes. Last week marketing was

livid because they lost an order due to our

inability to switch from one product line to

another quickly enough. This week a suppos-

edly simple change introduced a bug that

halted production for over 2 hours. IT chief

claims that over time the source code has

become very difficult to maintain because

there is a lot of spaghetti code, dead code

and duplicate code. To top it all, the docu-

mentation is almost useless because it was

not kept updated as the software was

changed.

3. We want to move our Sales Order System to

the Cloud but the dynamic nature of IP ad-

dress assignment within a cloud environment

poses new challenges for how we handle

database clustering and failover rules. There

are other known issues as well and those,

coupled with the perceived risk of the un-

known, is preventing us from moving to the

cloud quickly.

4. A Visual Basic 6 application that was devel-

oped barely five years away has become a

major headache because after Microsoft

dropped support for VB6, the third-party com-

ponents vendors started releasing only .NET

versions of their components and stopped

supporting the VB6 versions. When bugs are

Why does Software need Modernization?

Software only gets worse with time. The process of

maintenance makes most software de-

crepit and in need of modernization.



discovered in those components we have to

design workarounds. We can‘t find any good

developer who wants to work in VB6. Now

our customers are demanding a User Inter-

face that a critical third-party control does not

support. So we might have to replace the

entire component with custom VB6 code that

will cost us a ton of money and bunch of time

that we can ill afford.

5. We have an incentive computation system

for our 15,000 strong salesforce that started

on the IBM Mainframe using the IMS data-

base. Then some additional

functionality needed the IDMS

database. Now we have com-

bined this app with our payroll

app that uses DB2. Now the

management does not want to

pay all these different license

fees and want us to consolidate all data into

the DB2 database platform.

6. Many of our core business processes run on

the IBM Mainframe, but most of our new ap-

plications over the past seven years have

been developed on Java. Now the manage-

ment has decided to eliminate the Mainframe

and move all COBOL apps to the J2EE plat-

form.

7. Our company recently acquired a logistics

firm to strengthen our delivery operations.

The problem is, we have standardized our

information systems on the J2EE platform,

while the newly acquired firm has a mixture

of .NET, COBOL and even Visual Foxpro

apps. All of those now need to be moved to

J2EE.

IT NEED NOT BE OLD

As some of the examples above demon-

strate, it is inaccurate to think that only ancient

and decrepit software running on antiquated

hardware/software platforms (called "legacy soft-

ware" in common parlance) need to be modern-

ized. We treat all software that is in production --

regardless of their language or their age -- as

―legacy systems‖, because most software cur-

rently in production can benefit from moderniza-

tion in smaller or larger measure.

One definition of ―legacy software‖ is

―anything that‘s currently in production‖ -

―anything that works‖.

REASONS FOR MODERNIZATION

We have seen some real-life examples

above. Now let us articulate the main reasons

why we need to modernize software

DIFFICULTY

Older technologies are more difficult to

maintain, and this is a key pain point for many

legacy system owners.

COST

Difficulty translates into cost. Salaries of

hard-to-find resources, time taken to make

changes and licensing fees of older technologies

-- all drive up the total cost of ownership (TCO).

Software maintenance (defect repairs and en-

hancement) is the largest IT line item in Amer-

ica's larger corporations today. Capers Jones

(the much acclaimed Chief Scientist Emeritus of

Software Productivity Research) estimates:

"Maintenance projects will potentially absorb al-

most 70% of the world‘s software professionals

New software may need modernization

as well. It doesn‘t have to be old. It

depends on what the problems are.



during much of the 21st century."

LACK OF INTEGRATION

Legacy software typically does not inte-

grate well with other IT systems.

COMPETITIVE PRESSURE

New technology can offer significant

business advantage (e.g., sleek user interfaces,

web services, etc.) and boost revenues as well

as profitability.

NEW BUSINESS MODELS

New emerging business models often

require more collaboration, new web services

and greater interoperability -- which new technol-

ogy can provide.

REGULATORY CHANGES

Sometimes changes beyond our control

dictate changes that the old software might be ill-

equipped to handle.

MERGERS & ACQUISITIONS

M&A create unforeseen need for integra-

tion, consolidation, bridging and

interoperability that old software

cannot handle.

INEFFICIENCY

Inefficiency and the

need for productivity gain is an-

other common reason why old

software needs to be modern-

ized.

LACK OF BUSINESS AGILITY

Business agility is sometimes a compel-

ling need for the Top Management that is fighting

for every inch of market share. Outmoded, ar-

chaic software prevents IT from responding

quickly enough to the changes demanded by

business.

The cost of "doing nothing" may appear

to be less costly than modernizing, but usually

there are significant costs associated with "doing

nothing".

TRADITIONAL CHOICES

Traditionally, our software modernization

choices are as follows:

1) REWRITE

The problems here are those of time and

cost.

UNBEARABLY LONG TIME

The Gartner Group estimates that the

ultimate productivity of a manual code conversion

effort is no more than 107 lines of COBOL code

per man day. That means a moderate 1 million

line application will take 9,345 man days to con-

vert; equivalent to 39 man years.

So a 20 person team would have

to work a full two years to ac-

complish the conversion.

Keep in mind the princi-

ple of Mythical Man-Month; be-

cause this number is not as scal-

able as it appears. Deploying 80

programmers would probably not

complete the work in 6 months;

and 160 programmers would certainly not com-

plete the job in 3 months.



HUMUNGOUS COST

Even if we offshore this work to India,

this job will cost approximately $3 million.

INTRODUCTION OF NEW BUGS

Even if twenty veritable geniuses were

assigned to the project, the rewritten code would

have bugs — that is a given.

2) DISCARD AND BUILD AFRESH

Some of the same drawbacks as Option-

1 remains. The cost and time involved in a fresh

requirements analysis, functional specifications,

software architecture, technical specs, coding,

testing and deployment would be gargantuan.

Additionally, we would be throwing away

the baby with the bath water.

DISCARDING BABY WITH THE BATH WATER?

Legacy software is usually good. That‘s

why almost every Fortune 100 company still runs

tons of legacy software. Right?

Right. Legacy usually does mean

"success". So many companies have legacy soft-

ware because these old software do the job well.

Because core business proc-

esses -- deep inside a com-

pany -- are not as prone to

change as the more "visible"

parts of a company. Existing

software is also time-tested

and usually free of major bugs. This legacy

(goodness) must be cherished and preserved.

In each of these cases, all the goodness

developed through the years is lost; a good com-

pany asset is trashed; an ideal example of throw-

ing the baby away with the bath water.

3) ADOPT PACKAGED SOLUTION

Typically, where business applications

are concerned, the choice here veers towards an

established Enterprise Software like SAP and

Oracle Apps. These software have indeed be-

come very sophisticated and provide a very rich

set of business functionality out of the box.

But when we look at the implementation

history of Enterprise Apps, we see a almost two

decades of evidence pointing towards serious

cost and time overruns. Why do these projects

take so long to complete?

Because these software are most power-

ful in providing you with industry ―best practices‖

out of the box. But ―best practices‖ is not what

makes a successful company successful; their

success formula lies in the things

they do a little (or a lot) differently

from others: their ―differentiating

factors‖. This is the ―gap‖ that ERP

Functional Consultants determine,

and which the ERP Technical

Consultants then try to bridge by developing cus-

tom code using ABAP, NetWeaver. XI, Java and

other tools. But that gap covering exercise is a

traditional software development lifecycle that

fights the traditional challenges of the Business-

IT Divide, and provide results similar to what tra-

ditional IT provides: time and cost overrun.

If a 3rd party software covers only 90%

or less of your required, this strategy is very

unlikely to provide satisfying results.

BETTER: AUTOMATED TRANSFORM

A lesser known but much better method

is Automated Transformation of old software to

new technology.

Traditional moderni-zation choices are

very limited.

But there IS a better choice:

AUTOMATION

Why lose all the goodness of legacy?

That would be like throwing the baby along with the bath

water.



A utomated software modernization is

a tool-based approach where there

is no manual code conversion and all

new source code is automatically

generated by tools.

However, this is not a push-button black

box that is ready to work out of the box — like a

―black-box‖ Code Pump that blindly inputs one

kind of code and outputs another.

The more successful automated

methodologies involve a detailed manual process

during which the tools are setup and configured

for the exact job at hand before an indefinite

volume of code can be processed successfully.

MODELING SHOWS THE WAY

The Object Management Group (OMG)

has developed the Model Driven Architecture

(MDA) standard that represents a paradigm shift

in software engineering.

The Architecture Driven

Modernization (ADM)

standard was conceived as

a software modernization

standard that can serve as

a roadmap for porting

e x i s t i n g ( n o n - M D A )

software into the MDA

paradigm. ADM is a

scalable and flexible

m o d e r n i z a t i o n

methodology for any kind

of software modernization.

This document explains

ADM in more detail later.

As a member of the OMG, we are global

proponents of MDA (Model Driven Architecture)

and have adopted ADM (Architecture Driven

Modernization) as our automated software

modernization methodology.

What is Automated Software Modernization?

AUTOMATED SOFTWARE MODERNIZATIONAUTOMATED SOFTWARE MODERNIZATIONAUTOMATED SOFTWARE MODERNIZATION



W e use a formal, well-defined

methodology based on the

Model Driven Architecture

(MDA) and the Architecture

Driven Modernization (ADM) standards

formulated by the Object Management Group

(OMG).

REVERSE ENGINEERING

This modeling approach utilizes meta-

models and parsers for parsing the source code

and extracting all atomic level software artifacts

into an Abstract Syntax Tree Metamodel (ASTM).

This, then, is effectively a reverse engineering

step that recovers the software design of an

existing software into metamodel through fully

automated means.

FORWARD ENGINEERING

Once the existing software‘s design

artifacts have been recovered in the Abstract

Syntax Tree Metamodel, we use MDA‘s model-to

-model transformation procedures to forward

engineer the existing code on to a new, modern

platform.

These two steps: (a) Design Recovery,

and (2) Automated Transformation, are depicted

in the schematic below as a high level

representation of our software modernization

methodology.

Our Automated Software Modernization Methodology



M odel Driven Architecture is a

software engineering methodol-

ogy that: goes about understand-

ing business requirements and

construct new software quite differently from

what occurs in the normal software engineering

world.

1. MDA uses models to understand, design,

construct, deploy and maintain software; and

2. MDA insulates ―business‖ from ―technology‖

so that each side can focus on their area of

expertise instead of trying to communicate

ineffectively with one another.

Particularly, the second point above is

quite revolutionary, because normal software

development is based on the very premise that

business people and software technicians must

communicate as effectively as possible so that

the technicians can best understand that busi-

ness wants them to do.

WHAT IS A MODEL?

A Model is a representation of anything.

Figure-1 below are some examples of models.

A good model can make a problem or a

situation easy to understand. That is why the

Explaining Model Driven Architecture (MDA)

This flowchart is the model of a Traffic

Offense Enforcement Process.

This engineering drawing is the

model of a Machine Part.

This is the scaled down model of a

Building.

This COBOL program is the model of the

Business Process that it implements.

Fig - 1



modeling approach is so powerful in so many

industries, sciences and arts. And now with the

advent of MDA, model driven software engineer-

ing and — in our case — model driven ―re-

eingineering‖ has brought the power of modeling

to the software industry.

Modeling allows you to understand

something and simulate its behavior until you are

happy with the results, and then build the hin that

you are modeling. This is depicted in the sche-

matic Figure-2 that represents the Model-

Simulate Cycle.

In order to create, manipulate, simulate

and modify models, we need to first build a Meta-

model.

WHAT IS A METAMODEL?

A metamodel defines the language for

expressing a model. For instance, A Java Lan-

guage Meta-Model defines the grammar, syntax,

rules, constraints and structure of Java. Meta-

models are extremely complex constructs.

Metamodels are at the heart of the Model

Driven Architecture technology — and, therefore,

of our software modernization methodology.

As first step to understanding any exist-

ing software, we construct the metamodel of the

source language of the software we want to

transform into modern technology.

Our metamodels are compliant with the

OMG Meta-Object Facility, same as all OMG

technology, such as Unified Modeling Language .

Fig - 2

Here is a partial meta-model of the

MUMPS programming language.

Fig - 3



THE EVOLUTION OF „MDA‟

Business people do not (and should not

need to) understand computer technology. So

they convey their requirements to someone who

does: the Business Analyst. In traditional IT, this

person is the essential bridge between business

and technology, because he understands a little

of both. So the business peo-

ple communicate their require-

ments to the business analyst,

who now communicates that

to the technology people, and

the technology people then

constructs the solution that the business people

need. This is (and has been, since time immemo-

rial) the traditional IT paradigm.

Visuals are easier to understand than

text. So instead of giving the business user 50

pages of functional specifications to review and

approve, the purpose is much better served if he

is given as much of this in diagrams as possible.

But technology people are not terribly

fond of drawing tons of diagrams because at the

end of the day these are just pretty pictures that

need to be converted into technical specifications

so that programmers can convert them into com-

puter programs.

Wouldn‘t it be great if these ―pretty pic-

tures‖ could be automatically converted into

source code at the touch of a button after the

business people approve of them?

That is what MDA achieves.

MDA BEGINS WITH BUSINESS

MDA empowers the business users with

modeling tools that they can use — without any

interaction with the IT department — to build their

Business Model. This model will be a complete

representation of the business processes they

wish to implement on the computer. This is a

pure business model and knows nothing about

the technology required to implement it — be-

cause the business people who construct it need

know nothing about technology.

This is called the Platform Independent

Model (PIM) because it is platform (i.e., technol-

ogy) agnostic.

This is the democratization of require-

ments definition process where the business

model is build by the business people, for the

business people and consists of only business.

This modeling is accom-

plished using a Business Process

Management (BPM) tool and a

good BPM tool allows simulation,

so that the business people can

fully satisfy themselves that the

business model they have build it a correct repre-

sentation of what they wish to accomplish. Re-

member the Model Simulate Cycle explained ear-

lier in Figure-2?

Once the business people are content

with their business model — the PIM (Platform

Independent Model) — they hand it over to the IT

department to implement it. Until this moment

they need not have communicated with the IT

department at all.

This is the insulation between ―business‖

and ―technology‖ that MDA implements.

MDA THEN ADDS TECHNOLOGY

The IT department than studies the busi-

ness model from the pure technology standpoint

and figures out how to implement it. For instance,

From pretty pictures to source code?

That is what Model Driven Architecture actually achieves!

Pure business focus in a pure business

world.

The Platform Inde-pendent Model is

technology agnostic.



they might decide to use:

J2EE as the basic platform

Java Server Faces (JSF) and JavaScript for

the User Interface

IBM WebSphere as the Application Server

Java Server Pages (JSP) at the backend to

drive the User Interface

Oracle as the Database platform

PL/SQL and Web Service Definition Lan-

guage (WSDL) in the Data Access Layer

and so on…

Having determined this implementation

architecture, the IT department then utilizes

MDA‘s model-to-model transformation proce-

dures to convert the PIM (the

Platform Independent Model —

the pure business model) into

one or more Platform Specific

Models (PSMs) — which are

the ―technology aware‖ ver-

sions of the PIM. So while the PIM is technology

agnostic, the PSMs are technology aware. In

other words: PIM + Technology = PSMs, as

shown in Figure-4.

MDA THEN GENERATES CODE

The next set of model-to-model transfor-

mations convert the PSMs into the corresponding

source codes. Source Code is also a PSM

(Platform Specific Model) because as we have

stated before with reference to a COBOL pro-

gram being the model of the business process it

implements, all source programs are models.

THE „MDA‟ STACK

Figure-5 re-states our understanding of

MDA as a three-step process.

1. Define the BUSINESS MODEL in a pure

business environment without thinking about

technology. This is the Platform Independent

Model (PIM).

2. Let the IT department add the technology

layer to the Business Model. So now we

know how the business model will be imple-

mented. This is expressed as one or more

Platform Specific Models (PSMs) that are

generated from the PIM by using tools.

3. Generate Source Code from the PSMs,

again by using tools.

SIGNIFICANT BENEFITS OF „MDA‟

MAINTANABLE BUSINESS MODEL

MDA gives us a maintainable business

model, not maintainable source code. No longer

do we need to employ an army of coders to main-

The PERFECT INSULATION of

Business from IT is achieved by the 3-layer MDA stack.

Fig - 4



tain the code. Source Code maintenance is usu-

ally a downhill process — the code only gets

worse, never better, until eventually the code be-

comes difficult to maintain and a candidate for

modernization.

The business model is not likely to suffer

from the same predicament.

COST SAVINGS

The majority of IT software budgets to-

day funds code maintenance, not new develop-

ment. An estimate says that for every develop-

ment dollar spent, seven dollars are expended

towards maintaining the code

over the next twenty years.

MDA changes all that,

and shifts the burden of appli-

cation maintenance back to

the user departments, as

there is no code to main, but only business mod-

els to maintain — by the user departments them-

selves.

BUSINESS AGILITY

The epic battle between Business and IT

is over. The proverbial Business-IT Gap stands

perfectly bridged. Courtesy of MDA.

With MDA, when management decides

changes in the business, they need not depend

on IT to reflect those changes in the information

system. They can change the business model

themselves (by their departmental staff) and

have the new application deployed tomorrow.

As long as the implementation platform

and the underlying technology does not change,

once the model-to-model transformation proce-

dures have been defined and tested, source code

generation should be a push-button, virtually in-

stantaneous operation.

INSTITUTIONALIZATION OF KNOWLEDGE

One of the great by-products of MDA is

the institutionalization of knowledge. For the first

time, most of the knowledge floating around in

the company — and certainly almost all of the op-

Fig – 5

BUSINESS AGILITY

Finally Achieved ! By the insulation of Business from I.T.



erational knowledge — now can belong to the

rightful owner of that knowledge: the organiza-

tion.

Because all operational knowledge is

represented in the business model — the PIM

(Platform Independent Model)

— from which MDA is generat-

ing the software that ius run-

ning the company.

Now for the first time,

when someone leaves the

company, a lot of knowledge does not walk out

the door.

FUTURE PROOF INVESTMENT

If you invested in developing a state-of-

the-art application in—say—Java, you can rest as-

sured that sometime in the future that whole ap-

plication will have to be re-cast on a new plat-

form. Obsolescence of all technology is a given.

But the Business Model never becomes

obsolete. It continues to evolve with time.

Since MDA will continue to evolve the

platform specific models and the source code in

keeping with the changing business model, your

investment in MDA is secure and future proof.

MORE POWERFUL I.T. DEPARTMENT

MDA is not anti-IT. It does not do away

with the IT department. Quite the reverse.

MDA builds a stronger and more power-

ful IT department that can contribute more mean-

ingfully to the growth and sustainability of the

organization. Instead of spending most of its en-

ergies in maintaining software and supporting

users with day to day changes, IT can now focus

on what it knows best and does best: technology.

MDA foretells a smaller but stronger IT

department staffed by more senior people and

more technology savvy individuals who can work

with MDA.

An Outsourcing Buster Solution!

That‘s what the Gartner Group called MDA.

KNOWLEDGE NOW BELONGS TO THE Organization, and does not walk out

the door when people leave the

company.



M odel Driven Architecture (MDA)

is arguably one of the most

exciting software engineering

paradigms in practice.

But won‘t the introduction of MDA into an

established organization only tend to create yet

one more information silo alongside its pre-

existing silos, as shown in Figure-6?

The answer is ―No, it need not‖ and the

solution is called Architecture Driven

Modernization (ADM).

A D M

OMG prov ides th is s tandard

methodology for migrating traditional software to

the MDA environment, as well as other

functionality. ADM is the process of

understanding and evolving existing software

assets for the purpose of:

MDA migration

Software improvement

Interoperability

Refactoring

Restructuring

Reuse

Porting

Migration

Translation into another language

Enterprise application integration

Service-oriented architecture

Using MDA and ADM for Software Modernization

Fig- 6



Architecture Driven Modernization

inherits functionality from various other OMG

standards such as:

Knowledge Discovery Metamodel (KDM)

Abstract Syntax Tree Metamodel (ASTM)

Software Metrics Metamodel (SMM)

Our software modernization methodology

is based entirely on ADM.

HOW DOES ‟ADM‟ PREVENT SILOS?

How does ADM help prevent the

formation of more Information Silos?

ADM provides a methodology for

migrating traditional software into the MDA

framework by using automated means based on

Knowledge Discovery Metamodel (KDM) for

recovering the design from existing software and

saving it in an XML Repository, which is the

Abstract Syntax Tree Metamodel (ASTM). From

this repository, one can generate UML which can

be used to build a Business Model — the PIM

(Platform Independent Model), which is the start

of the MDA process.

„ADM‟ PROCESS DEFINED

The schematic in Figure-7 illustrates the

ADM process and its coupling with the MDA

stack.

1) BUILD THE METAMODEL

As the first step to transforming any

application, we must build a Metamodel (or use

an existing Metamodel) of the programming

languages your application is written in.

2) RECOVER THE DESIGN

This is a reverse engineering step where

our parsers analyze the source code (with

reference to the Metamodel) and extract all

possible atomic-level software artifacts (the

―design‖) into an XML Repository (the Abstract

Syntax Tree). Schematic in Figure-8 depicts this

process.

3) BUILD THE BLUEPRINT HYPERMODEL

We then traverse the XML Repository on

an Analyst Workbench to build a Blueprint

Fig - 7



Hypermodel by looking into

diverse technical aspects of the

source code base, such as:

Class Diagrams

Dependency Graphs

Structure Charts

Control Flow Graphs

Sequence Diagrams

Data Flow Diagrams

Cause & Effect Graphs

State Transition Tables

State Model Graphs

Model Driven Analysis

OOA/OOD Views

State Machine Models

and so on

as shown in Figure-9. This kind of detailed

analysis enables us to fully understand the

source code.

4) ASSESS AND STRATEGIZE

We analyze the existing architecture,

diversity of tools used, usage of external function

calls (black boxes), programming ingenuity, data

models, program structure, inter-program

communication, external APIs, and so on. In this

manner we exhaustively assess the ―as is" state

of affairs.

Based on this assessment, we determine

Fig - 9

Fig - 8



the strategic directions advisable for modernizing

the application.

5) SELECT MODERNIZATION OPTION

Of the various strategies deemed

possible in Step-4, here we select our

modernization option of choice. The main

decision is:

1. Adopting full Model Driven

Architecture (MDA)

2. Skipping the Business

Model but using MDA‘s model

-to-model transformation

methodology for migration

If the chosen strategy is #2,

then the next questions are, whether we pursue

full platform migration or some combination of

partial migration strategies.

FULL PLATFORM MIGRATION

This would entail full migration of the

entire application and data on to a new platform.

Our Architecture Driven Modernization provides

best value for this kind of big bang application

transformation.

MODERNIZATION VIA PARTIAL MIGRATION

Partial modernization of existing software

is a highly viable option. As opposed to the Big

Bang approach of migrating the entire application

to a new platform lock, stock and barrel, this is a

phased approach that addresses different parts

of the software in isolation for the rest and

modernizes that part alone.

The parts of a software application that

can usually be modernized in isolation from the

rest of the application usually consist of the

following:

1. The User Interface

2. The Data Storage

Additionally, it is also possible to SOA-

enable an old application quite effectively by

defining services and making these available to

other applications via the HTTP interface (in

which case it would be a Web Service) or

otherwise.

MODERNIZATION WITHOUT MIGRATION

Code refactoring is about improving

existing code. It is a software transformation that

improves the internal software structure while

preserving the external software behavior and

existing functionality. The purpose is to improve

internal quality attributes of the software: to

improve code readability, to simplify code

structure, to change code to adhere to a given

programming paradigm, to improve

maintainability, to improve performance, and to

improve extensibility.

It reduces software decay (aging),

software complexity and software maintenance

costs. It increases software understandability (for

instance, by introducing design patterns) and

software productivity.

The following are just a few examples of

typical code refactoring:

Problem: Duplicate code

Solution: Extract method; pull up

variable; form template method;

substitute algorithm

Problem: Long Method (The longer the

method the harder it is to see what it‘s

doing.)

Solution: Extract method (split a method

WIDE RANGE OF MODERNIZATION

Options are possible using our MDA/ADM-driven automated

techniques.



into two); replace temp with query;

introduce parameter object; preserve

whole object; replace method with

method object

Problem: Large Class (The larger the

class the harder it is to see what it‘s

doing.)

Solution: Extract class (split a class into

two); extract subclass

Problem: Lazy Class (Each class you

create costs money to maintain and

understand. A class that isn't doing

enough to pay for itself should be

eliminated.)

Solution: Collapse hierarchy (when you

have subclasses that aren‘t doing

enough); inline class (when you have a

class that does not do very much, move

all its features into another class and

delete it)

Problem: Feature Envy (Often a Method

Fig -10

The Presentation Layer consists of parts that are used to present data to the end-user. The data it serves includes data from the database as well as Windows or online buttons and forms, boxes for editing or texts, grids, labels, etc. that make the data presentable. It relies on the results generated by the Business Tier and formats the data into screens, widgets, etc.

The UI Client-side Components Tier contains everything that the client is able to display. Includes the Distributed Logic needed to connect to the Proxy Tier on the Server-side to Send and Receive requests. The UI Server-side Components Tier contains everything that runs at the Web Server end, such as C#, VB.Net, ASP, etc. The Proxy Tier that contains SOAP, CORBA, RMI, DCOM, etc.

Reserving a separate layer strictly for Business logic in an N-Tier architecture is a major advantage, in that any changes that need to be made to Business rules can be made here without having any effect on other applications. Contains business objects and rules; data manipulation & transformation.

The data access layer consists of components that access the database. Only the data access layer may access the database. Any other layer that needs data from the database must request this layer to serve that data. As a result, changes made to the database and to tables and other components will not affect the rest of the application. The other layers do not know database credentials,

connect strings, or other sensitive information, because we partition the data access function into the data access layer. So this layer also provides database security. It is also exclusively able to access many services that assist in accessing data, such as Active Directory Services. Data can also come from sources other than the database, e.g., Web Services.

This layer hosts the actual databases and handles storage, query processing, indexing and performance optimization.



that seems more interested in a class

other than the one it's actually in.)

Solution: Move Method

6) IMPLEMENT THE METHODOLOGY

The next steps are typically as follows

(not intended to indicate sequence of events):

PLATFORM SELECTION

A new target platform is selected. For

instance, J2EE, .NET, etc.

DETERMINING SOFTWARE ARCHITECTURE

A new architecture is determined for the

new platform under the 'n-tier' architecture.

The n-tier architecture readily

implements Distributed Application Design

concepts. It distributes a system‘s overall

functionality into a number of layers or ―tiers‖ with

each tier performing

some unique tasks that

are not handled by

other layers. It is

possible to develop

each of these layers

separately from the

others, as long as it can

communicate with the

other layers and adhere

to the s tandard

specifications. It is

possible for each layer

to treat the other layers

in a ―black box‖ fashion.

That means that the

layers do not care how

the other layers

process information, as

long as the data is sent between layers in the

correct format. This separation of concerns

protects the other layers from any changes that

might occur within the functions one

particular layer handles.

Depending on whether

J2EE or .NET is selected as the

target, the exact architectural

components shall vary, as depicted

in the schematic in Figure-11.:

WEB-ENABLE THE NEW APP (OPTIONAL)

We have tools to automatically generate

GUI screens from Mainframe/Midrange

Character User Interfaces, which can then be

manually touched up, as necessary.

MIGRATE TO A NEW DATABASE (OPTIONAL)

Database consolidation (merging

Fig - 11

Automation with Human Intervention

The Best of both

worlds.



multiple databases into one database) is

sometimes a requirement.

GENERATE CODE

New source code is generated in the

target languages. More than one language may

be called for. This may include DDL (Data

Definition Language routines),

W S D L ( W e b S e r v i c e

Definition Language), XSD

(XML Schema Definition),

CSS (Cascading Style

Sheets), Stored Procedures

and other code segments. All source code is part

of our deliverable.

CODE ENHANCEMENT & RE-FACTORING

Additional code re-factoring, code

remediation and enhancements - such as SOA-

enablement and additional functionality - may be

implemented, if required.

GENERATE DYNAMIC DOCUMENTATION

Dynamic documentation of the new code

base is generated, where the documentation will

change in real-time to reflect the latest changes

to the software.

The following schematic (Figure-12)

provides an overview of the entire automated

software modernization process.

From Business Model to Code

MDA addresses the

entire software development life

cycle.

Fig - 12



E very company has hundreds of Excel

sheets. Large companies have

hundreds of thousands if not millions

of them. These Excel sheets, useful as

they are, represent in some sense an

uncontrolled asset that are under the control of

individual users. They may utilize Excel to

implement any kind of data processing that the

Excel framework allows, and

encode in there any kind of

data that is available to them.

Social security numbers,

c o n f i d e n t i a l c o m p a n y

information, confidential client

matters — anything is within the realm of

possibility.

There is exposure. The management can

dictate policies but there is no way of ensuring

that policies are followed by the users.

Now you can. We provide several options

for taking control of your Excel assets.

Using our Excel Compliance Engine you can

monitor all Excel sheets in the organization in

real-time and ensure compliance with

company policies, including regulatory

compliance such as Sarbanes-Oxley and 21

CFR Part-11.

Using our Excel Transformation Engine you

can migrate all Excel sheets into .NET or

Java programs that retain all formula, macros

and look and feel of Excel within a controlled

environment.. This would follow the normal

platform migration lifecycle.

If you wish you can treat your important, rich

formula laden Excel sheets as ―source

programs‖ and use the Excel platform only for

formula modification, and convert the sheets

to .NET or Java for use in production. That

way you can ensure that only properly QA‘ed

Excel sheets go into production.

Harnessing your Excel Assets

Your Excel Under Control

Now your Excel sheets can be moni-tored or converted to .NET or Java… using our tools.

INNOVATIVE APPLICATIONS OF MDAINNOVATIVE APPLICATIONS OF MDAINNOVATIVE APPLICATIONS OF MDA



C loud Computing is fast becoming the

largest IT wave in the 21st century,

and for good reasons, because the

C l oud r e p r es e n ts a un i que

convergence of technologies and value that was

not possible until now. As a result, industry

interest is huge.

23% OF COMPANIES

The INFORMATION MANAGEMENT

website reports that more than 23 percent of U.S.

companies are beginning to plan and test the use

of cloud computing.

MICROSOFT, GOOGLE, AMAZON

Many of the major software houses, from

Microsoft, to Google to Amazon, have jumped on

to the Cloud bandwagon.

WHAT IS CLOUD COMPUTING?

According to generally accepted industry

principles, a Cloud is not just any virtualized

resource. It must exhibit certain specific

characteristics, as below.

The Cloud must be universally available from

any ubiquitous PC, Mac, Linux or other

workstation that is connected to the Internet.

There need be zero capital investment (or

zero new investment).

Users should be able to pay only for what

they use; in other words, metered payment.

The infrastructure should be infinitely scalable

through virtual servers and desktops that can

be provisioned and de-provisioned as

required — and instantly.

These are, obviously, unique and solid

proposition to users. As a result there is

intensifying corporate interest in deploying

applications to the Cloud.

New platforms, such as the Google

AppEngine and Microsoft Azure, have sprung up

for developing applications in the Cloud. The

Amazon Web Services (AWS) platform has

emerged as one of the leaders in Cloud

Computing.

DEPLOYMENT IN THE CLOUD

How easy is it to deploy existing,

traditional software assets to the Cloud?

Cloud Computing - Using MDA

Fig - 1



The short answer is: It is not as easy as

you might think.

This article is a brief practical inquiry into

Cloud Computing and the difficulties of deploying

traditional software applications into the Cloud.

It ends with a brief description of our 6-

step process of deploying software into the Cloud.

SAME AS VIRTUALIZATION?

To the uninitiated, cloud computing

sounds almost indistinguishable from

virtualization. But a cloud is not just any

virtualized service. It must also demonstrate the

virtues of ubiquitous access, metered payment,

zero capital investment and virtually infinite

scalability at will.

So while a cloud is indeed a virtualized

resource, every virtualized resource is not

necessarily a cloud.

MANY FLAVORS OF CLOUD

While buzzwords abound, the schematic

in Figure-1 represents today‘s Cloud Computing

stack.

SOFTWARE AS A SERVICE (SaaS)

SaaS is the simplest form of a

Cloud and virtualizes a packaged

software (like, ERP, CRM, ECM, etc.) in

the Cloud, Prime examples of SaaS

include:

Salesforce.com … CRM

Gmail … Email

Microsoft Online Services …

document management

LotusLive … document management

NetSuite … financial accounting and

more

PLATFORM AS A SERVICE (PaaS)

PaaS provides an entire software

development, production and systems

administration platform as a service. Examples of

PaaS today include:

Google AppEngine: based on Python and

Django

Microsoft Azure: end-to-end tools

Force.com: based on the SalesForce SaaS

infrastructure and Apex language

Bungee Connect: visual development studio

based on Java

LongJump: based on Java/Eclipse

WaveMaker: visual development studio

based on Java and hosted on Amazon EC2

In order to embrace Cloud Computing we

may either:

Develop our application directly on a PaaS

platform;

Or:

First develop our web applications using

desktop development tools; and

Then make the necessary changes to deploy

those applications to a cloud hosting provider

Fig - 2



such as Amazon EC2.

INFRASTRUCTURE AS A SERVICE (IaaS)

Infrastructure as a Service provides an

entire Data Center – with all its servers, racks,

network devices, firewalls, storage devices,

operating systems, system utilities, applications

software, software development tools and

systems administration tools – as a virtual

resource accessible through the Internet on

demand. Prime examples of IaaS are:

Amazon Web Services (AWS)

Servepath GoGrid

Rackspace Mosso

AWS is currently the leader in

functionality spectrum coverage and adoption.

Microsoft has announced as of November

2009 that they will migrate their current PaaS

offering — Azure — towards a full-fledged IaaS

Cloud.

CHALLENGES OF DEPLOYING

As we have stated in short earlier, it is not

easy to deploy an existing application to the

cloud.

PROPRIETARY NATURE OF CLOUDS

GOOGLE APP ENGINE

A simple example of this is with relation

to the Google App Engine PaaS, which lets us

build applications on Google‘s renowned and

highly scalable infrastructure. But in order to

leverage this facility, we must write applications

using -- or migrate applications to – Python, and

use Google‘s development frameworks (i.e.,

Google-specific APIs) that provide tools for using

Fig - 3



the Google file system and data repositories.

More recently, Java APIs have also been made

available.

THE AMAZON CLOUD

A leading PaaS today is Amazon Elastic

Cloud Compute (EC2) that supports transactional

computing, which is what most business software

does. But we cannot just port one‘s existing

application to EC2 without making changes.

EC2 provides the Web Services API for

provisioning, managing and de-provisioning

virtual servers inside the Amazon cloud. It

provides for 2 kinds of storage:

Ephemeral Storage: transient

storage that expires with the

node (virtual server); and

Block Storage: persistent

storage that survives over time

like a NAS. Applications running inside EC2 can

also utilize persistent storage from Amazon S3

(Simple Storage Service).

But S3 is very different from a file system.

It provides a 2-level namespace and comes in the

form of ―buckets‖ that must be accessed via Web

Services that allow for data handling, such as:

find buckets; find objects; discover their

metadata; create new buckets; upload new

object; delete existing buckets and objects. S3

provides the REST API and the SOAP API to

make it easier. We can also use an API wrapper

for our language of choice that can be extracted

out of the S3 REST API , e.g., Jet3t may be used

for Java development. Below are examples using

the command line for S3:

C r e a t e s a b u c k e t c a l l e d

―adasoftsalesorder‖:

S3cmd mb s3://adasoft.sales.order

Loads a file into the bucket:S3cmd put

sales_order_201002.xls s3:// adasoft.sales.order/

sales_order_201002.xls

Whatever be the method, the fact

remains that applications being ported to the

Amazon Cloud must undergo changes at least in

their Database Layer to handle Amazon S3.

TRANSACTION PROCESSING IN THE CLOUD

Transactional Computing is what most

business software does. A transaction consists of

one or more (usually more) pieces of data that

must be processed as one unit (one transaction)

and establish relationships with related data. The

heart of a transaction processing system is a

database. In a typical transactional system, an

Application Server models the data stored in the

database and presents it to the user through a

web based interface.

But our transaction processing business

application may not be that easily ported to a

Cloud. For example, if our architecture uses

Memory based locking to resolve possible

conflicts, then our architecture will fail in the

Cloud because the Cloud dynamically scales

application processing by a process akin to

clustering servers in the non-Cloud world.

Possible solutions:

Convert to clustering technology or cross-

server shared memory systems.

Use the database as the authority on the

state of the system. Provide transactional

integrity through stored procedures (which

destroys portability across databases).

Keep our protection at the application server

level but still achieve multiserver transactional

integrity by creating protection against dirty

It is not easy to de-ploy into the Cloud

Re-programming is required, no matter

which Cloud you deploy to.



writes or by creating a lock in the database.

Create a field in the database table for

managing the lock.

We cannot just deploy a Transactional

System on the Cloud without some programming

changes.

PRIMARY KEY MANAGEMENT

With a web application operating behind

a load balancer in which individual nodes within

the web application do not share state information

with each other, the problem of cross-database

primary key generation becomes a challenge.

The database engine‘s auto-increment

functionality is specific to the database you are

using and is not very flexible: often it is

guaranteed to be unique only within a single

server.

How to programmatically ensure good

primary key management? There are several

solutions.

UUID: We could use the standard UUIDs

to serve as our primary key mechanism. A UUID

(Universal Unique Identifier) is a 128-bit number

used to uniquely identify some object or entity on

the Internet. Depending on the specific

mechanisms used, a UUID is either guaranteed to

be different or is, at least, extremely likely to be

different from any other UUID generated until

3400 AD. But there are potential downsides as

well.

Better solution: Let the database manage

key generation through the creation of a

SEQUENCER table. If necessary multiple tables

can share the same primary key space so that we

don‘t have to create multiple sequencer tables.

This will generate predictably sequential keys. If

we need to remove the element of predictability

from key generation then we need to introduce

some level of randomness into the equation.

Whatever be the solution, re-

programming may be required.

Fig – 4



SENSITIVE DATA HANDLING

Sensitive Data – such as credit cards,

health records and other confidential information –

needs special handling in the Cloud. We may

have to segment our data store in the Cloud in

geographically dispersed locations so that no

single piece (segment) constitutes meaningful

data that can be misused. Alternately, we can

store all private information outside the cloud but

execute as much application logic as possible

inside the cloud.

These strategies cannot be automatically

implemented without code changes.

DEPLOYING USING MDA

Our automated application transformation

techniques based on MDA enable us to extract

the Data Access Layer and the Database Layer

from any application that needs to be ported to

the Cloud; making those Cloud-compliant, and

deploying, in a 6-step process as depicted in

Figure-4.

The DESIGN RECOVERY process is the

typical reverse engineering step we employ

based on OMG‘s Architecture Driven

Modernization (ADM) standard.

Since much of the difficulty in deploying

to the Cloud involved persistent data store and

retrieval methods, the original Data Access Layer

and the Database Layer are extracted from the

overall software and separately modernized, as

shown in Figure-4. They are then re-integrated

with the rest of the original software and then we

have deployment-ready code.

DISASTER RECOVERY IN THE CLOUD

A new platform creates new scope for

innovation. Disaster recovery woes can be

addressed by segmenting data across multiple

geographical locations — say in 12 segments,

where any 8 segments can enable us to fully

reconstruct the data.

Fig - 5



Make Unstructured Data Come Alive

D ata is everywhere, but far too often,

not the information we need.

Businesses continue to generate a

huge volume of memos, reports,

minutes of meetings, planning documents,

proposals, emails, website content, blogs, wikis

and other content. But this wealth of data is not

providing companies with the information base it

needs to make the right

decisions when it needs to.

Because all this unstructured

data is not actionable

intelligence. As a result,

although we are awash with

data everywhere, we make uninformed decisions

based on a very small slice of that information

that is readily

available to us.

Figure-1 shows

how the Information

Framework stands

broken.

Worse still,

all this underutilized

d e l u g e o f

unstructured data is

actually causing

companies to lose

money. IDC estimated in their report titled ―The

High Cost of Not Finding Information‖ (IDC

#29127) that companies with 1,000 white collar

employees typically wasted in excess of $6

million per year searching for information and not

finding it. Add to this the lost revenues caused by

unproductive employee time.

The potential loss from unstructured data is,

therefore, multi-faceted and consists of:

Uninformed decisions

Overlooked risks

Loss of employee time

Loss of opportunity

Loss of revenues

All of these can be fixed by our

metamodel driven information management

Timely access to critical information

separates the winners from the

losers in this information econ-

omy.

Fig - 1



solution that can turn all this unstructured data

into rich, actionable intelligence.

UNDERSTANDING “UNSTRUCTURE”

―Unstructured data‖ is not really

unstructured. Let us take the example of a paper

magazine. It has a wonderful structure. The

Table of Contents offers an instant overview of

the entire magazine and provides an useable

index that we can use to jump to any article by

page number. Within articles, there are pictures

to help us visualize the

information contained in the text;

there are headings that are

bolded and tell us what a section

of text is talking about; there are

blurbs (information callouts) that

highlights some of the main

points of the article; there might be an abstract

providing a gist of the whole article; there may be

footnotes, citations and references that link the

ideas expressed with a world of information

outside the magazine, There are advertisements,

which we immediately recognize as

advertisements. There is information about the

editorial team, the company publishing the

magazine and the authors of the various articles,

An e-mail gives you all the information as

to who wrote the e-mail; when was it written; to

whom was it addressed; who all received a copy;

what was it all about (the Subject); the main body

of the message; and, any reference material

provided as an attachment or an URL

So there is, indeed, a lot of structure in

what we started out as identifying as

―unstructured data‖.

The problem is not with the data. The

problem is that a machine does not understand

this structure automatically unless we find a way

of adding machine-readable information to all this

data.

SOLUTIONS STRATEGY

The key to unleashing knowledge from al

this powerful, but untapped, information lies in

being able to:

Generate the right METADATA (data about

the unstructured data) that a machine can

understand,

CATEGORIZE the data using an easily

understood VOCABULARY, and a

TAXONOMY that indicates the data hierarchy

and relationships.

Provide a KNOWLEDGE RETRIEVAL

mechanism that understands all of the above.

APPLYING OMG STANDARDS

OMG has modeling standards embodied

in Model Driven Architecture that can be utilized

for modeling any kind of information (though it is

originally intended for modeling and

understanding software systems). The

Knowledge Discovery Metamodel (KDM), for

instance, separates knowledge about existing

systems into four orthogonal dimensions:

Structure, Behavior, Data and User Interface,

Unlike software, data has no behavior. But it has

―Unstructured‖ data might have an

excellent structure of its own - that

computers do not understand.



associative fact patterns. So we utilize a modified

version of the KDM concept adapted for

understanding unstructured data, which we call

mKDM.

OMG also has an initiative called the

Semantics of Business Vocabulary and Rules

(SBVR) which is a standard for establishing a

business vocabulary and terminology system that

can be used to express business models. This is

very useful for defining vocabularies to

understand unstructured data, taxonomies to

categorize unstructured data, and rules for

processing unstructured data.

Coupled together, mKDM and SBVR

provide the base technology for creating

metadata; defining the vocabularies, taxonomies

and rules for processing the data; and retrieving

useful information based on linked entities as well

as ―inferred‖ fact patterns. This helps convert

unstructured data into actionable intelligence.

PARTS OF THE SYSTEM

SCANNERS AND PARSERS

Scanners and parsers will process the

unstructured data with reference to the

Knowledge Modeling Standards of OMG, and

produce symbol tables and syntax trees. This will

be an Abstract Syntax Tree Metamodel

representing the unstructured data.

AUTOMATIC CATEGORIZERS

Automatic categorizers will act on the

metadata and perform the following functions:

Linguistic analysis

Statistical inference

Machine learning

Rule-based processing

These will obtain the relevant

vocabularies, taxonomies and rules from the

Semantics of Business Vocabulary & Rules

(SBVR) that is part of our reference Knowledge

Modeling Standard. The SBVR will provide the

relevant business vocabulary necessary to do

this job properly. For instance, if we are doing

this job for a stockbroker, the relevant business

vocabulary will be far different from what will be

relevant for a law firm. Documents will be

assigned to multiple categories.

The output of the automatic categorizers

will be a Metadata Repository; and catalogs, fact

patterns and indexes.

KNOWLEDGE RETRIEVAL ENGINE

Regardless of whether the user is

searching or browsing or seeking information

through a web service or an API, the actual

retrieval will be performed by a Knowledge

Retrieval Engine. It has to scan and parse the

―request for information‖ with reference to the

same vocabularies, taxonomies and rules in the

SBVR that were used by the automatic

categorizers.

It will then retrieve two kinds of

information:

1. ENTITY EXTRACTION: Focus on identifying

named entities.

2. FACT EXTRACTION: Focus on fact patterns



and detecting relationship between data

using ―inference‖.

The retrieved information will be focused and

relevant to the ―request for information‖. It will be

actionable intelligence.

PACKAGING & DELIVERY ENGINE

The retrieved information has to be

packaged and delivered to the seeker of

information using the right channel, The request

can come from one of many channels, such as

interactive search, interactive browsing, web

services, or well defined APIs. The results are

pushed back through the same channel. There is

also more than one way of representing the

results: textually or visually, through spatial

diagrams or mind maps.

Figure-2 is a schematic representing the

methodology..

PRACTICAL APPLICATIONS

Apart from the holistic application of this

methodology across an enterprise for rich

productivity gains, greater revenue and informed

decisions, this methodology also has many

smaller practical applications on limited sets of

data.

E-DISCOVERY FROM EMAILS

Email has become the standard for both

internal and external communication. A

company's email contains important, and

sometimes confidential, information that is today

Fig - 2



increasingly going into massive e-mail archives,

whether to comply with mandatory government

regulations or for information archival.

E-discovery refers to discovery in civil

litigation which deals with information in electronic

format also referred to as Electronically Stored

Information (ESI). Emails can

be a prime source of

information in civil litigation.

Financial and other

firms subject to Sarbanes-

Oxley regulatory compliance

need effective e-discovery

mechanisms from their e-mail archives and other

documents.

Our solution can help you implement a

powerful information retrieval mechanism from

Email Archives, resulting in the following

capabilities, and more:

Advanced search capabilities to find specific

records within your complete and secure

archive.

Locate and produce evidence-quality

messages with metadata in seconds.

Analyze a complete audit trail for every

message.

Review and classify every message (based

on your company's rules and permissions)

that leaves or enters your organization's

domains.

Messages can easily be classified for legal

hold when court or counsel requests that all

data relevant to a particular case be

preserved.

E-mail analytics designed to be utilized in

complex litigation or investigative matters.

Search for and identify key individuals and

assess their relationships and communication

patterns. The Activity Schematic in Figure-3

displays communication patterns with a key

Powerful E-Mail Analytics

can provide never before discovered intelligence from plain company

emails

Fig - 3



individual placed in the center, and e-mail

correspondents connected with radial spokes.

Timeline View can be produced as a

horizontal timeline to help assess critical time

periods in the matter under investigation.

E-mail Analytics help you to easily identify

communications of the key players for

substantive review.

We can transform your email archive into

rich actionable intelligence.

OTHER REGULATORY COMPLIANCE

Regulatory compliance also weighs down

the life science companies (pharmaceutical,

biotech and medical device companies). FDA

regulations pertaining to clinical trials,

manufacturing processes and drug discovery

require similar diligence in

preserving ―evidence‖ for a

stipulated period of time. Such

evidence is also contained in

the unstructured data items

like e-mails and documents.

Our methodology equips the

company and auditors with reliable and quick e-

discovery processes, apart from other proactive

compliance monitoring functions of interest to the

company.

RESEARCH AND DEVELOPMENT

Pharmaceutical companies engaged in

drug development, for instance, can benefit from

every bit of better intelligence and every minute of

human effort saved. Drug development activities

for a single product can span over ten years and

involve collaboration from a wide range of

professionals like research scientists,

pharmacologists, chemists, biologists, chemical

engineers, production floor specialists, clinical

trial units and others. All the information flow

amongst these diverse entities located in diverse

geographical locations has a very large share of

―unstructured‖ data.

LAW FIRMS

Law firms try to make sense from

unstructured data every single minute of their

existence. With the expanding Internet-driven

universe, making sense out of information

overload and using the results meaningfully for

their clients‘ benefit is an ever-expanding

challenge.

CONTENT PUBLISHERS

Companies engaged in any kind of

publishing, especially delivery of content over the

Internet, are competing for differentiation in

search capability.

Content metadata is most important, as

that is indispensable for setting up the catalogs,

fact patterns and indexes that, in turn, can

translate into accuracy of information delivered.

INTELLIGENCE & LAW ENFORCEMENT

Especially in this age of rampant

terrorism, proactive prevention of crimes is a top

priority. The huge world of ―unstructured‖ data

constantly evolving on the Internet is a rich source

of intelligence and alerts, but too humungous for

manual processing and/or informal methods.

A methodology such as ours can

effectively harness and delivery untold value from

the Internet.

The Lifebood of the Enterprise is

information. The information economy thrives and survives

on information.



P rogrammers don‘t like to document.

Even if the first release of a software

is well documented, documentation

typically does not keep up with the

software releases. After sometime, the

documentation is either non-existent or unreliable

(which could be worse than no documentation).

How much money does this lack of

documentation cost the company? Huge amounts

in terms of lost productivity, long maintenance

cycles and faster deterioration of the value of the

software asset.

Now we can generate technical

documentation from any source code —

automatically. Such documentation capability

includes but is not limited to: Application

Inventory, Source View, Class Diagrams,

Dependency Graph, Structure Chart, Control

Flow Graph, Sequence Diagram,

Data Flow Diagram, Cause & Effect

Graph, State Transition Table, State

Model Graph, Business Rule

Modeling, Model Driven Analysis,

OOA/OOD View, Structured

Systems Analysis / Structured

Design Method View, State Machine Model, Dead

Code, Duplicate Code, and Unreferenced

Variable Index.

The diagram in Figure-1 is a Paragraph

Tree of a COBOL program. The schematic in

Figure-2 is a sample Sequence Diagram that has

been annotated for your easy understanding.

These are merely representative of the power of

our automatic documentation capability.

Fig - 2

Document Old Software… automatically

Fig - 1

Poor Documentation is worse than none.

Now you can solve your problem… with

our automated tools.



INDUSTRY TRENDS: 2009INDUSTRY TRENDS: 2009INDUSTRY TRENDS: 2009---201020102010

F ORRESTER RESEARCH said in their

Nov 2009 North America study titled

―Appl ication Modernization and

Migration Trends in 2009/2010‖:

Modernization budgets are remarkably

strong. IT leaders are budgeting to modernize

and migrate their application assets, with a

whopping 86% of the firms allocating a significant

part of their IT budgets for this purpose:

25% of the firms allocating 20% or more of

their IT budgets to modernization

61% of the rest allocating between 19% and

10% of their budgets to the same cause

STRONG DEMAND

59% of the IT decision makers surveyed

in 2009 named software modernization as their

#1 concern.

Poor economic conditions actually favor

modernization, with:

54% of the f i rms

increasing their spending to

migra te f rom ex i s t i ng

programming languages,

da t ab as e ma n a ge m en t

systems, TP monitors and

hardware/software platforms.

49% of the firms increasing their spending to

modernize applications without migrating, by

using techniques that include integration at

presentation, data or process layer; rewrites;

and packaged application option.

COST REDUCTION #1 REASON

Cost reduction is the primary driver of

migration indicated by 79% of the firms, with 1044

of the top IT decision makers in North America

reporting that 66% of IT capital and operating

budgets for software going towards ongoing

maintenance and operations, and not for new

software development. Modernization will release

much of these dollars for new application

development that is sorely needed.

BLOAT AND FUTURE COMPATIBILITY

Other reasons for modernization and

migration included:

Our portfolios are bloated with redundant

technology.

Fears about future compatibility haunt us.

We badly want to reuse software assets

through SOA.

RARE SKILLS ALSO A CONCERN

Up to 65% of respondents also cited fears

about the current and future availability of skilled

personnel as a driver for modernization.

The study concluded with the

observations:

Strong modernization budgets help IT leaders

prepare for economic recovery.

The new urgency in cost cutting focuses on

reducing the cost of ongoing maintenance

and operations.

59% of top IT decision makers

said Software Modernization is their #1 concern.



Rest in peace The dream continues...

Management Coalition, USA (WfMC); IEEE

Computer Society, USA; Computer Society of UK,

London; Institute of Engineers, India; Computer

Society of India; and the OMG, where he was

International Partner for South & South East Asia.

Having spent most of his time in Europe,

particularly in Germany, DK Bose finally founded

ADA Software USA in January 2007 with the

dream of exponential growth in the world‘s largest

software marketplace. We remain resolute in our

determination to make that dream a reality.

TRIBUTE TO OUR FOUNDERTRIBUTE TO OUR FOUNDERTRIBUTE TO OUR FOUNDER

A n icon of the Software Industry, DK

Bose embodied a relentless

passion for technology and

innovation. A firm believer in tool

based development as opposed to brute-force

coding, DK Bose names our company with the

acronym for Application Development Aid.

In 1981 when thousands of Auto-coder

programs needed to be migrated from IBM 1401

-01 to the ICL 2904 platform, he developed

COBGEN, a COBOL Generator that pre-dates

the earliest patented COBOL generator on

record. Since then he was a thought leader in in

automated application migration and legacy

code modernization. In 1989, when Chris Stone

founded the Object Management Group (OMG)

along with Dr. Richard Soley, its current

Chairman & CEO, it was no surprise that DK

Bose was right there to lend support to this

potent vendor-neutral standards organization for

innovation in software engineering. As a result,

ADA has been a staunch OMG member since

its inception and is a global proponent of Model

Driven Architecture (MDA).

Always at the cutting-edge (forget the

cliché, he was true cutting-edge) of systems &

software expertise and a source of mind-

boggling knowledge, he had an amazingly

diversified domain expertise.

A true global road warrior, he had

offices and residences dotted all over Europe. A

regular presence in International Trade Shows

and Seminars everywhere, he was a proactive

member of many professional and standards

organizations, amongst them: World Wide Web

Consortium, USA (W3C); Workflow

DK Bose



PRODUCT INFORMATION

Probal DasGupta Amanda Sidhu

CEO North America Director of Modernization Technologies

Phone: 516 903 4279 Phone: 516 903 3824

Email: [email protected] Email: [email protected]

Toll Free: 888.453.0014

MARKETING PRESENCE

Metropark, NJ New York, NY Atlanta, GA Kirkland, WA

DELIVERY CENTERS & TECHNOLOGY COLLABORATORS

ADA USA T S R I METALOGIC ADA INDIA

Metropark, NJ Kirkland, Washington Calcutta Calcutta / Trivandru,m

USA USA India India

WORLDWIDE

Germany France Belgium Switzerland

Netherlands U.K. Sweden Singapore

India China Senegal Canada

Section-3

CONTACT INFORMATIONCONTACT INFORMATIONCONTACT INFORMATION

M E M B E R



When one needs a heart bypass, one goes to a cardiac surgeon.

When one needs the best storage solutions, one goes to EMC, the storage specialists.

Why would you go to Accenture, Cap Gemini, Infosys or Wipro for software modernization?

WE ARE THE SOFTWARE MODERNIZATION SPECIALISTS. IT IS ALL WE DO.

Call

888.453.0014

Software modernization. It’s all we do!!!

www.adasoftusa.com

379 THORNALL STREET, WEST TOWER - 7TH FL, METROPARK, NJ 08837

software modernization and legacy migration primer

Technology

modernization adm

modernization option22

software migration

software architecture

document old software

business15 mda

technology15 mda

evolution of mda