20
Reasons to Migrate Magic eDeveloper, uniPaaS and Magic xpa to .NET by Upgrading
Rather than Converting
Reason #5: Upgrading
to Magic xpa reduces risk versus C#, ASP, or Java
As
Magic customers rely on applications to support key business functions, it is
important to ensure that the application resides in the latest fully supported
versions of Magic technologies. The choice for those running applications
between Magic eDeveloper to .NET
conversion and Magic eDeveloper to C#, ASP or Java conversion is an
important decision fraught with risk.
IT
risk identification, management and response is a key concern for all
enterprise IT departments. Senior executives and management have a
responsibility of “Assuring investors and shareholders that a ‘standard of due
care’ around mitigating IT risks is being met by the organization.” (IT
Governance Institute, COBIT 4.1 Framework, 2007). In an enterprise environment,
there is considerable risk in
working with unsupported architectures, and this risks non-compliance with
federal legislation and SOX guidelines.
In fact, our Fortune 500 customers tell us that the upgrade to Magic xpa
is essential to maintaining SOX compliance. We have to note that Magic’s
platform is just one piece of the overall architecture of the business
computing environment, and as other components of the architecture change, it
is important to ensure that all components are compatible. Hardware, Infrastructure, Operating Systems
and Databases that come in touch with Magic Applications, are constantly
changing by their respective vendors, and evolving irrespective of the
computing technology in use. Most of these
vendors tend to have limited life spans on their deliverables and the needs of
a complex computing environment require prudent upgrades of these components.
Reason #5: Upgrading
to Magic xpa reduces risk versus C#, ASP, or Java
Infrastructure
changes are driven by a number of factors: 1) Lack of available parts for older
hardware may lead to BIOS, processor or other incompatibilities; 2) Operating
System versions that are under cease-of-support and end-of-life conditions; 3) Enterprise IT mandates and “green”
initiatives; 4) Change-of-behavior or discontinued features in databases,
middleware and other components. Indeed, upgraded operating systems and
database versions often provide tremendous advantages in terms of performance,
integrity and security. Should an
infrastructure component upgrade be unsupported by the older application
platform technology, there is considerable risk that business operations could
be disrupted:
a) Because
the unsupported component may cause the Magic technology to become
unpredictable, or cease to work altogether.
b) Because
an older component may fail and it may be difficult to source an older
compatible replacement.
c) The
older the version, the less the likelihood of available service-level
agreements, warranties, support or the human resources knowledgeable about
older technologies and problems, this can lead to delays that may take a long
time to diagnose and/or resolve.
d) Development
work may increasingly involve complex workarounds and fixes;
e) Production
system down time can increase to unacceptable levels, up to and including
complete system failure.
Magic applications are often part of a larger Corporate Enterprise
Application Portfolio;
it is important that your applications do not become an “island”, with no
ability to interact with newer technologies.
The latest versions of Magic xpa 2.x are constantly being updated to take advantage of newer emerging technologies and standards to
ensure interoperability with other industry standard technologies including
.NET.
Both risk and cost
savings are compelling reasons to ensure that all elements of your Magic
applications will be utilizing the latest technologies from Magic Software. The
IT Governance Institute suggests that the goal of risk response is to “Ensure
that IT-related risk issues, opportunities and events are addressed in a
cost-effective manner and in line with business priorities.” (IT Governance
Institute, Enterprise Risk: Identify, Govern and Manage IT Risk, The Risk IT
Framework Exposure Draft, 2009.) The problem with converting to C#.NET, ASP.NET
or Java is that they all increase cost and risk. There is much more effort
after the conversion to maintaining an application with large programming teams
required to accomplish what could be accomplished by a single Magic developer
before. Costs skyrocket with the code-centric approaches, risks mount as
unending communication cycles are generated by those trying to figure out what
the machine generated code does, and bugs spread across the code-base as
developers unfamiliar with the language or the business logic introduce new
issues and risks that are simply not present when upgrading.
But the time to
upgrade is now (actually its way poast time, but not too late). Magic Software
removed support for eDeveloper 9.4 in December 2009, while eDeveloper 10.2 was
superseded by uniPaaS; and uniPaaS is now superseded by Magic xpa 2.x.
The importance of
moving from eDeveloper 9.4 to Magic xpa
in a timely manner, and continuing to leverage the investment made in Magic applications is only magnified when
considering the risk your company is exposed to when not fully migrated to Magic
xpa and .NET.
As many businesses
continue to expand their vision of a fully integrated Service Oriented
Architecture (SOA), Web Services, RIA, SaaS, Green IT, etc., the importance to
the business of using the latest Technology Stack available demands high
visibility. The success of your IT team
in the eyes of internal business customers depends on your reputation for
deployment on Magic Software’s modern extensible platform, Magic xpa
Application Platform, which can become an integral part of your enterprise’s
world-class technology architecture.
For
additional information on how an upgrade to Magic xpa is superior to Magic eDeveloper to .NET conversion
please convert here.
