Reason #5: Upgrading to Magic xpa reduces risk versus C#, ASP, or Java

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. 

Reason #4: Magic xpa Provides Superior .NET Transaction Capabilities

20 Reasons to Migrate Magic eDeveloper, uniPaaS and Magic xpa to .NET by Upgrading Rather than Converting

Reason #4: Magic xpa Provides Superior .NET Transaction Capabilities

Before you get into the thicket of C#.NET, ASP.NET or Java programming, you might just want to consider how much more difficult it is to deal with transactions in these manual languages than it is with the Magic xpa Application Platform. These 3^rd Party Vendors offering Magic Software Migration services forget that you are going to need to write your own code in C#.NET, ASP.NET or Java to make up for the transaction capabilities of the Magic xpa Application Platform.

Business applications frequently require transactional programming techniques. How easily one can program a transaction depends on the language and platform. The Magic xpa Application Platform enhances the .NET platform making it possible for Magic programmers to create transactions with significantly less effort than C#, ASP.NET or Java developers.

Transactions are an integral part of developing data-bound applications. A key to developing applications in a database environment is the ability to optimally use transactions to ensure data integrity.

The word “transaction” is used very often when discussing SQL applications. A transaction is an integral part of a process, contributing to the composition of the whole application, and it can be defined as the execution of a set of logically related data modifications, which must be committed (completed and written to disk) or aborted as a single unit.

This means that either the entire process succeeded or the entire process failed. There is no middle ground. Several operations such as UPDATE, DELETE and INSERT may create a single unit. Only if all the operations are successful, will this logical unit be successful.

A transaction process may be an entire business logic process or a smaller unit that is part of a business logic process.

Transactions can be used to secure Read operations, as opposed to Read/Write operations. A Read transaction ensures that the data read within the transaction is not modified by other users.

The transaction processing technique automatically logs all of the updates of a transaction to a temporary transaction file. The updates in this file are cleared only when the transaction is complete, that is, the updates to all the regular database tables have been completed successfully. If a problem is detected in any of the tables affected by the transaction, the entire transaction is canceled and the database is rolled back, that is, restored to its original state before the transaction occurred. The rollback uses the information stored in the Transaction Log file to restore the project.

Reason #4: Magic xpa Provides Superior .NET Transaction Capabilities

There are many challenging issues when implementing transactions using C# or ASP.NET. The first problem is isolation. The volatile resource must adhere to the isolation property of ACID, lock the underlying resource it manages, and prevent access by multiple transactions. However, C#.NET and ASP.NET only offer thread-based locks, which prevents access only by concurrent threads, not concurrent transactions. The second problem is state management. The resource manager needs to enable the transaction to modify the state of the resource and yet must be able to roll back any such changes if the transaction is aborted.

Magic xpa offers extensive transaction-handling capabilities that avoid heavy manual programming efforts in C# and Java. For additional information on how an upgrade is superior to  3^rd Party Magic Software Migration conversion please convert here.