View
3.396
Download
6
Category
Tags:
Preview:
DESCRIPTION
Software modernization is usually the remedy wherever software maintenance costs are high, business agility is low, integration is poor or interoperability is deficient - which are also the commonest problems affecting most companies. This document explains the Automated Software Modernization option based on OMG's Model Driven Architecture and Architecture Driven Modernization standards.
Citation preview
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
Software Modernization. It’s all we do!!! PAGE 2 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
TABLE OF CONTENTSTABLE OF CONTENTSTABLE OF CONTENTS
Special Section on
CLOUD COMPUTING
Page 27
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
Software Modernization. It’s all we do!!! PAGE 3 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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
Page 33
Software Modernization. It’s all we do!!! PAGE 4 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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
Software Modernization. It’s all we do!!! PAGE 5 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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
Software Modernization. It’s all we do!!! PAGE 6 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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
Software Modernization. It’s all we do!!! PAGE 7 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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.
Software Modernization. It’s all we do!!! PAGE 8 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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.
Software Modernization. It’s all we do!!! PAGE 9 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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.
Software Modernization. It’s all we do!!! PAGE 10 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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.
Software Modernization. It’s all we do!!! PAGE 11 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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
Software Modernization. It’s all we do!!! PAGE 12 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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
Software Modernization. It’s all we do!!! PAGE 13 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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
Software Modernization. It’s all we do!!! PAGE 14 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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
Software Modernization. It’s all we do!!! PAGE 15 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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.
Software Modernization. It’s all we do!!! PAGE 16 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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
Software Modernization. It’s all we do!!! PAGE 17 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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.
Software Modernization. It’s all we do!!! PAGE 18 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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.
Software Modernization. It’s all we do!!! PAGE 19 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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
Software Modernization. It’s all we do!!! PAGE 20 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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
Software Modernization. It’s all we do!!! PAGE 21 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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
Software Modernization. It’s all we do!!! PAGE 22 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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.
Software Modernization. It’s all we do!!! PAGE 23 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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.
Software Modernization. It’s all we do!!! PAGE 24 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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.
Software Modernization. It’s all we do!!! PAGE 25 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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
Software Modernization. It’s all we do!!! PAGE 26 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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
Software Modernization. It’s all we do!!! PAGE 27 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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
Software Modernization. It’s all we do!!! PAGE 28 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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
Software Modernization. It’s all we do!!! PAGE 29 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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
Software Modernization. It’s all we do!!! PAGE 30 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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.
Software Modernization. It’s all we do!!! PAGE 31 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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
Software Modernization. It’s all we do!!! PAGE 32 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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
Software Modernization. It’s all we do!!! PAGE 33 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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
Software Modernization. It’s all we do!!! PAGE 34 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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.
Software Modernization. It’s all we do!!! PAGE 35 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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
Software Modernization. It’s all we do!!! PAGE 36 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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
Software Modernization. It’s all we do!!! PAGE 37 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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
Software Modernization. It’s all we do!!! PAGE 38 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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.
Software Modernization. It’s all we do!!! PAGE 39 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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.
Software Modernization. It’s all we do!!! PAGE 40 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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.
Software Modernization. It’s all we do!!! PAGE 41 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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
Software Modernization. It’s all we do!!! PAGE 42 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
PRODUCT INFORMATION
Probal DasGupta Amanda Sidhu
CEO North America Director of Modernization Technologies
Phone: 516 903 4279 Phone: 516 903 3824
Email: probal.dasgupta@adasoftusa.com Email: amanda.sidhu@adasoftusa.com
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
Software Modernization. It’s all we do!!! PAGE 43 OF 42
SOFTWARE MODERNIZATION - POWERED BY MODELING
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
Recommended