Reason #17: Magic xpa has a Built-In Licensing Mechanism

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

One of the deficiencies of C# as it compares to Magic xpa is that it lacks any sort of licensing mechanism. Licensing is important for software publishers who want to use Magic xpa to create and protect commercial software. It also provides an added measure of security and risk prevention to corporate software users. Licensing mechanisms help to prevent unlicensed software usage and therefore reduce the risk that a company can be sued for copyright and other violations. When considering migration of Magic eDeveloper to C#.NET or ASP.NET or Java (or uniPaaS or Magic xpa), it is important to consider your need for licensing mechanisms.

 Magic xpa’s built-in license-metering mechanism uses your local area network (LAN) to communicate between Magic xpa instances running on different machines on the network. As part of our ongoing commitment to comply with the latest and highest industry standards, Magic introduced a new policy for the activation of our software licenses in 2012. The improved process, implements a highly secure, automated method of license protection, enabling you to better monitor the use of your licensed software.

You activate and receive your licenses after validating your Product Key on Magic’s License Activation Portal. The metering mechanism helps organizations avoid any unintentional violation of the license. The license-metering module ensures that no more than the allowed number of connections uses Magic xpa concurrently.

Magic xpa includes a license management scheme. The license management system comprises three main components: a License File, which stores all the license information for a specific site; the Magic xpa Engine, which uses data from the License File to allow or prevent user access to an installed Magic xpa product; a License Server, which provides license information to the Magic xpa engine, and also counts the active users of the installed product.

Magic xpa offers three license modes: no license, demo license and permanent license. The Magic xpa License File, when initially created, contains a default demo license. This demo license has no time limit but is limited in its functionality and cannot be used for the development and deployment of mission-critical applications. Permanent licenses have no time limit. When you load Magic xpa with no license, essentially without specifying a license name, the Single User Edition will run.

The single-user limitation is relevant for both the development of the application, as well as its deployment. Magic xpa Single User Edition provides almost the complete range of features found in the commercial edition of Magic xpa, excluding multi-user related features and capabilities.

Magic xpa also includes convenient mechanisms for counting licenses and running floating licenses. To count licenses, you can run MGSTATIONS.exe from the Magic xpa directory to verify the license count of a specified license on a network.

Magic xpa's default behavior is that you have to define the number of licenses that each server uses during the execution of a project. This number is checked across all the servers in a multi-project environment to ensure that it is within the license limitation. For example, if you have a license with 20 threads, and you have two projects running in a multi-project environment, you have to distribute the threads in advance. Project A might receive 15 threads, while Project B receives 5.

In a multi-project environment, each server runs a different project. This means that the capacity of each server (project) is a key issue, and the ability to share licenses (threads/users) is very important.

Magic xpa's floating license mechanism lets you make optimum use of these licenses in a multi-project environment, by sharing licenses between servers. Therefore, when a particular project is idle, other projects can utilize its licenses.

Because the Magic xpa broker controls the servers and their capacity, it needs to know the total number of licenses that are available for its servers. The broker adds up the total maximum threads and users belonging to each server. The broker uses this figure as the total number of available threads/users. If the broker sees that a particular server is not using its allocated number of threads/users, the floating license mechanism means that they can be used by other servers.

Using C# to manually license software is a fool’s errand. Using C# to bind in a third-party licensing scheme is also very expensive and time consuming. The advantage of the Magic xpa Application Platform is that licensing is built-in to the platform as a protection to both corporate end users and software developers.

For additional information on how an upgrade to Magic xpa is superior to Magic to .NET conversion please convert here.

Reason #16: Straightforward Security Management

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

Magic greatly simplifies security issues for developers, giving them the power to create highly secure applications without a lot of hassle. This is another reason why Magic eDeveloper or uniPaaS to .NET migration via C#.NET is a mistake compared to upgrading to .NET with Magic xpa.

User rights management is simplified in Magic because the developer and administrator/supervisor use Magic xpa’s built-in Authorization System, Active Directory or LDAP. The Authorization System enables developers and certain users to control access to Magic xpa projects in Studio modes. This control is achieved through setting access keys to various Magic xpa project elements, and by assigning specific rights to users and user groups.

As a repository based system, Magic xpa is vastly superior to the tedious coding required for rights management in C#. The Magic xpa Rights repository lists the name and keys of all the rights defined for a project. The developer can define a bank of rights and assign them to the project's various repositories and elements. Any project element that has an access right assigned to it will be blocked to users who have not been assigned this right. Project-layer security is always defined during development.

In addition, Magic xpa includes a flexible authorization system to control what each user can and cannot do in Magic xpa. The authorization system lets the application developer or system supervisor limit access to various activities in Magic xpa to those users specifically authorized to have such access.

The authorization system exercises its control through sets of rights and the use of built-in Magic xpa functions. Rights can be thought of as keys to locks. Rights assignments connect users, who are classified by role, with the application’s components, which are classified by accessibility. This means that certain classes of users are allowed to access certain parts of an application.

The person in the role of Supervisor can assign rights that give each user access only to the activities for which that user is authorized. Any activity that is not specifically restricted by the Supervisor or the developer remains accessible to all users and does not require any rights assignment. To access the authorization system repositories, the developer must log on to the system as a user which has the SUPERVISOR GROUP assigned to the user. This group is reserved by Magic xpa, and is automatically included in any Magic xpa system. In addition, a Supervisor user (which has this group assigned to it) is also automatically included in any Magic xpa system.

Typically, when one is implementing a security system in Magic xpa, rights are granted according to the user’s job function, which corresponds to a Magic xpa Group. That is, a user who is a bookkeeper will have a different set of menus and screens than a person who is in Sales. Other rights, however, may only be granted to certain individuals, such as the ability to approve paychecks or adjust time cards.

Managing rights in C# can be like looking for a needle in a haystack. Instead of having to search through potentially millions of lines of code to find everywhere that a role is checked, Magic xpa provides a single, consolidated location known as the Rights Repository. What a nightmare it would be to have to parse an entire code base to learn and document what roles are assigned to what permissions.

For additional information on how an upgrade to Magic xpa is superior to Magic eDeveloper to .NET conversion please convert here.

Reason #14: Web Services

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

Today's entry in the reasons not to convert Magic eDeveloper, uniPaaS, or Magic xpa to C#.NET code is Web Services. If you ask Microsoft how-to incorporate Web Services into an application, they simply refer you to ASP.NET. Why? Because C# is considered an unsuitable match for developing programs that publish or subscribe Web Services.

But let’s suppose you decide to be stubborn and persist in migrating your Magic Web Services to C# which uses a line-by-line coding approach.

In a simple example, just to pass a SOAP header, your C# code would look something like this:

<%@ Page Language="C#" %>

<asp:Label id="ReturnValue" runat="server" />

<script runat=server language=c#>

 void Page_Load(Object o, EventArgs e)

 {

  MyHeader mySoapHeader = new MyHeader();

  // Populate the values of the SOAP header.

  mySoapHeader.Username = Username;

  mySoapHeader.Password = SecurelyStoredPassword;

  // Create a new instance of the proxy class.

  MyWebService proxy = new MyWebService();

 

  // Add the MyHeader SOAP header to the SOAP request.

  proxy.MyHeaderValue = mySoapHeader;

  // Call the method on the proxy class that communicates with

  // your Web service method.

  string results = proxy.MyWebMethod();

  // Display the results of the method in a label.

  ReturnValue.Text = results;

 }

</script>

Here’s how you do it in Magic xpa: interact with the dialog box Header field.

Also, when consuming Web services (either by using the Invoke Web S or Invoke Web S Lite operation), the Magic xpa engine does a lot of work for us.

Magic xpa lets you call a Web service directly or uses the Systinet Web Services framework (named "Systinet Server for Java") for providing and consuming Web Services.

Magic xpa provides rich Web Services support including:

·         SOAP 1.1 and SOAP 1.2

·         WSDL 1.1

·         WS-I Attachments Profile 1.0

·         MTOM/XOP support

·         WS-I Basic Profile 1.1 Compliance

·         Transport level security – SSL\TLS

·         WS-Security 1.0 – authentication, encryption and digital signing of SOAP messages

Ask yourself this question: Is my company in business to write programming code? If writing code is not your business and not at the heart of the charter of your company, then why spend so much time managing code when you can manage applications that support your business instead?

For additional information on how an upgrade is superior to Magic to .NET conversion please convert here.

Reason # 13: Maintainability of Applications

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

As we mentioned in our previous discussion of software quality, maintainability of a program or maintainability of code is one of the six key measures of software quality. It is also the area where the Magic xpa Application Platform absolutely shines over alternative means of software development and deployment such as C#, ASP and Java.

Maintainability of C#.NET code is such a common and ongoing problem for developers that Microsoft, although unable to control bad coding practices, created a maintainability index that tells you just how bad your code is. If you are considering migration of Magic eDeveloper, uniPaaS or Magic xpa to C#.NET instead of upgrading to .NET directly with Magic xpa, then you shouldn’t ignore the problems of maintainability in C# versus Magic xpa. Here’s why:

C# software projects are commonly derailed by bad engineering decisions that make the code un-maintainable. These bad decisions often fall into one of two categories: over-engineering or under-engineering. Under-engineering results in spaghetti code. This is particularly common with code conversion projects. The code conversion creates a giant meatball of code. Thick, impenetrable and impossible to understand. Those charged with maintaining that code by manually programming in C# start by adding a string of spaghetti here, a string of spaghetti there. Pretty soon you have a giant wad of overcooked, undercooked and raw spaghetti smothering your poor meatball. There was no plan, no experience and no recipe for code maintenance. The situation gets worse when a renegade hacker is called in to rescue the code. But all they can do is add more spaghetti of their own and the code gets worse and worse. With Magic xpa, the platform itself provides the needed “applistructure” for an easily maintained application. Magic xpa applications are more like a finely layered lasagna, well thought out, uniformly structured and therefore highly maintainable. 

Over-engineering results in bloated code. A great many C# developers, including those who create code-generators, are overly enamored with patterns. Since they have no application platform to work with, they are forced to create application design patterns and it is extremely common to go overboard with these code snippets. Developers who inherit migrated code are also highly likely to overcompensate and be pattern-happy. It is almost impossible to see it in the early stages of code maintenance. The over-engineering of converted code is problematic however, because it causes incremental  amounts of overhead code to be added for each new change or piece of functionality implemented. Over-engineering will crop up when trying to cope with new operating system and database changes as well. Over time, these chunks of overhead snowball and negatively impact maintenance costs, lag schedules and ultimately cause projects to be abandoned and fail. The Magic xpa Application Platform provides the applistructure that allows you to focus on business logic. Maintaining code is never a matter of over or under engineering but instead a focused activity of measurable improvements.

The vulnerabilities of C# are also found in the area of code redundancy. Whereas Magic xpa leverages a platform, C# programmers have to create their own application architecture from scratch. The .NET framework is not an application architecture, that’s why the word framework was carefully selected because it is neither platform nor architecture. While every developer knows the DRY principle: Don’t Repeat Yourself. The problem with a code generator is that it is impossible for the developer to know when they are repeating code that was generated elsewhere. The converted Magic applications become so bloated and complex when deconstructed into C# code that the code to be maintained ends up having massively repetitive aspects. While efforts will be made and assurances given, it is just impossible to avoid code bloating by duplication of nearly-matched patterns.

Since the code generator won’t see the repeatability within complex patterns, it will simply engage in wholesale duplication of code. The code is not DRY conformant and therefore nearly impossible to maintain over time.

Magic xpa’s repository-based development approach enhances project organization. Rather than dealing with mountains of text, you work in well-organized Magic xpa repositories. C# on the other hand allows for wreckless programming. Poorly organized code can lead to the introduction of dumb bugs and will result in slipped schedules or worse.The superior organization of a Magic xpa application means that it is easier to on-board a new Magic xpa programmer from scratch than it is to orient even an experienced C# programmer to code-generated projects.

For additional information on how an upgrade to Magic xpa is superior to Magic to .NETconversion please convert here.

Reason #10: Rapid Return on Investment (RROI) with Magic vs. Converting to C# 3GL

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

Building new software systems for businesses is a critical process and one that must complete in the least possible amount of time. Return on Investment is on the mind of every entrepreneur who has to sign off on a development budget to get new business systems in place that will deliver unique competitive advantage. So in today’s business climate, the emphasis is on rapid return on investment (RROI). The break-even point needs to be achieved at the earliest possible moment. Every cost has to be analyzed against the expected returns to arrive at estimated break even dates. So here’s reason # 10: Rapid ROI. The RROI you achieve with Magic is not possible if you convert Magic eDeveloper, uniPaaS or Magic xpa to C#.NET.  We’ve been talking about it for a long time at Magic. You can achieve ROI in your application development process faster and with greater assurance when using Magic than you can with C#, ASP or Java.  

Application development tends to occur in phases. For our purposes, let’s consider these four phases: Design, Build, Test and Deploy. When the pressure is on to create new business applications on demanding schedules, you need to have all four of these phases occurring almost simultaneously, but traditional computer programming tools do not allow this. All four of these phases require an investment of time, but if you can execute some of the phases in parallel, then you can get to the final destination faster. So with Magic testing isn’t something that happens at the end of a software process, it is an iterative process that occurs throughout the project. For this reason, it may be more useful to think of Design, Build, Test, Maintain not as phases, but rather as layers of the Magic development task. The design layer tends to be front-loaded in the project, but some design occurs while maintaining the program. The test layer tends to be back-loaded towards the end of a project, but using sound iterative design principles, testing definitely occurs throughout the life of the project. Time is money is perhaps a cliché but critical when discussing the ROI of business software development projects for new business systems. (Maintenance is another interesting topic that I will also address separately).

Application Development ROI calculations must put the emphasis on the investment that goes into dollars paid to the developers on the project; i.e. how many developers will it take and for how long? The sooner the project comes to a successful end, the faster the ROI for the project, and the sooner the new business can deploy their new systems and reap the benefits.

The time saved - hence the ROI - using Magic is significant: typically from 4 to 6 times faster than that of other development technologies.

The table at left is based on extensive market research and compares each of the four phases (layers) of the application development lifecycle for 3GLs (Third Generation Languages), 4GLs (Fourth Generation Languages) and Magic. If x, y, z, and w represent the time spent on an average 3GL application for each of the application development phases, research shows that generally 4GLs cut the time in half. With Magic even better time- savings are achieved. The productivity gains shown below are conservative calculations by Magic Software based on interviews with Magic programmers.

In order to achieve rapid ROI, each phase of the lifecycle must not only be completed quickly, but must also have the highest reliability to ensure the fastest payback for the investment being made. 

Magic’s progressive development paradigm allows prototype applications to be quickly and easily created. In fact, the Magic paradigm has often been used to convince venture capitalists and other investors that achievement of a new start-up business’ goals for new business systems is in fact achievable. Without Magic, some businesses might not even “get off the ground.” In addition, the ability to support applications over time despite changing business models, platforms, and standards is inherent in the Magic xpa Application Platform and earlier versions of Magic’s development and deployment technology.

Rapid ROI remains a key critical measure for every business from startups to established industry titans and is often the difference between success and failure. For additional information on how an upgrade to Magic xpa is superior to Magic to .NET conversion please convert here. 

Reason #8: Client-Server Interactions Must Be Programmed Manually in C#

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

Reason #8: Client-Server Interactions Must Be Programmed Manually in C#

We’re continuing our series of articles for those comparing migrating Magic applications to C#.NET or ASP.NET and the simpler alternative of upgrading Magic to Magic xpa, which is fully .NET based. Since so many Magic applications are client-server in nature, we need to consider what a client-server application loses when it is stripped of its platform.

Are you really eager to maintain a code base that is machine generated and that does something you’ve never had to do as a Magic programmer: manage low-level client-server communications? Creating a client socket in C# with ordinary .NET functions is messy, to say the least. And once you have the socket, you need to create an instance to get event-driven access to the data. Receiving data with  doesn't guarantee your messages arrive in one piece, though. So more manual programming is required.   You’ll need to program ways to keep messages together, for example you might create one suitable for simplistic text messaging and one suitable for arbitrary message-based communication.

So you’ll have to write programs that are also able to pass text with a suitable end marker, such as a new line. But what if a new line is a part of the data you want to pass? Oops, more programming. Now you’ll have to create handlers for data received in read events.

On the server side, you also need to be receiving and sending information (just like a client). But a server has to also keep track of who is connected to it. More programming. It might also be necessary to be able to broadcast messages, that is send them to every client currently connected. More programming.

You’ll also have to write (and/or maintain) code that gives you the ability to protect a socket, using encryption algorithms. More programming. You have to be able to pass an encryption type. More programming. How many encryption types might your application need to support? Oops. More programming for each one! Skip this step by just not telling your boss and you’ve taken a formerly secure Magic application and completely exposed it. Not good.

But wait we’re not done with discussing what you have to do and maintain for encryption in client-server communication layers. First, remember that the server needs to be able to send either a public or private key; because if the key is sent unencrypted, this is not very secure, but it does mean that the communication is not in plain text. The client will also need to generate a symmetric key and encrypt it before sending it to the server. More programming. This is the only way to be sure that the key is never visible to a third party and the connection is kept secure; to access the message you would need to break the encryption algorithm.

If you choose to use encryption in a Magic application, very little is different in your programs and nothing is needed to secure communication between the client and the server. However, in C# programming for your server, you’ll have to program a way for the server to know when the client is ready because the encryption protocols have succeeded. More programming. Otherwise, the client is called before key exchange is complete and the client is not ready to send and receive data. Do you really want to be responsible for maintaining all of this code?

If you attempt to send data to a client before it is ready, it should result in an exception. Similarly, if you want to send data through an encrypted client socket, you should be prepared to write code that will respond to a ready event or check an encryption ready property before even sending data. Stupid, useless (but absolutely necessary code) that the conversion generates by machine and you must maintain ad nauseum into the future.

Imagine in C#, just trying to create a basic server class - without the guts. You’ll need to write programs to create a TCP listener. (Have you got to the business logic yet? No way, not even close!) You’ll need this to wrap up the underlying socket communication, and open threads which will be listening for client connections. You’re also going to need to write functions that listen for clients and that can be used to manage the start up of threads. 

This function is going to have to start up TCP listening and then sit in a loop accepting connections. Oh joy, loop programming in C#. You’re also going to need a function to call TCP clients and these will have to be blocked until a client has connected, at which point you need more code to fire off a thread to handle communication with that new client. You’re going to have to write code that allows your thread firing mechanism to be parameterized too. Otherwise, how will you efficiently handle client communications?

I’m sorry, but I have to stop writing this article. We aren’t even one fourth of the way through discussing the kinds of programming required for client-server communications. Do you really want to be responsible for maintaining all of this? You and what programming Army? Right now, you do have a programming Army that protects you from all of this: it’s Magic!

For additional information on how an upgrade to Magic xpa is superior to Magic uniPaaS to .NET conversion please convert here. 

Reason #7: .NET Done Right

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

Reason #7: .NET Done Right

We’re continuing our series of articles for those deciding between uniPaaS migration to .NET  and uniPaaS to C# or ASP. As a number of Magic xpa developers have astutely observed, Magic xpa is .NET done right.

Magic and .NET

With its deployment engine based on the Microsoft .NET Framework, Magic xpa applications qualify as standard .NET applications. This provides developers with access to a wide range of built-in, commercial and third-party .NET services, forms and controls for use in their applications.  Additionally, use of .NET Windows Forms controls give apps a modern, friendly user experience that increases usability. While fully .NET compliant, Magic xpa continues to support native development on Solaris, AIX, Linux, and IBM i server platforms as well.

In addition, the smarter way of developing and deploying applications inherent to Magic xpa, often called ‘the Magic paradigm,’ continues to offer massive advantages to developers. We see this very clearly in the way Magic xpa provides a superior platform for .NET development of data-centric or transaction-oriented business applications when compared to C# or ASP.

With Magic xpa Application Platform you can embed and integrate any .NET control or assembly. You can upgrade the look and feel of your Client-Server or Rich Internet Applications by directly placing new .NET controls as part of the user interface. You can also enhance the functionality of your application by integrating any form of .NET assembly. But you do so without having to write line-by-line code. The assemblies and controls are accessible from the Composite Resource Repository. The repository based nature of development in Magic xpa is vastly superior compared to the difficult and tedious nature of line-by-line text coding in C#. With Magic xpa, data discovery and manipulation is also handled in a repository based way.

Smart Future-Proof Technology

Magic has been enhancing features and helping our customers Outperform the Future for over 30 years and will continue doing so. We provide our long-time customers with simple migration paths to RIA and mobile, and provide an integration platform based on the same technology stack. By migrating your applications to the latest version, our customers can take advantage of new business opportunities quickly, easily and cost-effectively. In Magic xpa you gain:

•          The ability to natively use .NET controls and code as part of an application without losing productivity! This is what our users call .NET done right.
•          Standardization of client look and feel. Magic xpa facilitates a seamless switch from WIN32 to .NET UI and simple support for .NET integration.
•          Magic xpa is stronger and more robust.
•          Magic xpa provides an enhanced, richer more modern user experience
•          With Magic xpa you gain compatibility with the latest databases and operating systems.
•          With Magic xpa, you will find it easier not only to place controls on the forms but also to bind data. 
•          With Magic xpa you gain compatibility with Windows 8 features.
•          And finally, with Magic xpa you have frameset controls that provide you with the ability to create multiple horizontal/ vertical frames and easily transfer data between them within an application.

A Full Solution

Magic customers benefit from Magic’s rich 30-year experience in application development and integration.

You also benefit from our strong community including:

• Extensive professional service expertise and partner network
• Strong developer community including 3000+ ISVs
• Global 24/7 customer support organization
• Strategic alliances and partnerships with mobility and enterprise software vendors including Samsung, SAP, salesforce.com, Oracle JDE, Microsoft, IBM, and more.

For additional information on how an upgrade to Magic xpa is superior to Magic uniPaaS to .NET conversion please convert here. 

Reason #6: Magic v5-8 are not object-oriented or component friendly and C# and Java won’t help (but Magic xpa will).

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

Reason #6: Magic v5-8 are not object-oriented or component friendly and C# and Java won’t help (but Magic xpa will).

Some conversion vendors offering Magic  to .NET conversion won’t even admit that Magic v5-8, Magic eDeveloper, uniPaaS and Magic xpa don’t need to be converted to C# in order to become 100% .NET based applications. An Upgrade to the latest version of Magic xpa will take advantage of the .NET platform without locking you into a non-platform based language like C# that requires large programming teams.

Thousands of companies worldwide have made a clear commitment to an extended life for their Magic applications, as they represent solid, comprehensive, core business functionality within their companies. These decisions are congruent with the key Val IT principle that “IT-enabled investments will be managed through their full economic life cycle.” (IT Governance Institute, The Val IT Framework).

In this series of articles, we will review 10 reasons to upgrade rather than convert. Let’s look at reason number one.

Reason #6: Magic v5-8 are not object-oriented or component friendly and C# and Java won’t help (but Magic xpa will).

By upgrading, you gain a platform with built-in component resource handling capabilities and maximum compatibility with your existing application logic. The Composite Resource Repository (CRR) in the Magic xpa Studio contains all of your objects for making calls to external components.

From the Magic xpa CRR, you can:

·         Reload a component interface or load a new component by selecting Load/Reload Components from the Options menu. When an ECI file is loaded or reloaded, Magic xpa checks the component type defined in the interface and changes the Type property of the CRR accordingly. This would require extra manual programming in C# or Java.

·         Invoke a wizard that will both create a component that connects to an external resource and create the component’s interface. This would require extra manual programming in C# or Java.

·         See the component interface by zooming from the Name column.

·         Assign rights to a component. This would require extra manual programming in C# or Java.

·         Use the Locate mechanism to locate a specific component type. This would require extra manual programming in C# or Java.

If you convert older Magic applications to C# or Java code instead of upgrading, your business logic is stranded or isolated and has no access to the Composite Resource Repository. Regardless of whether you currently deploy Magic v5, Magic v6, Magic v7 or Magic v8, or even a later eDeveloper of uniPaaS application that has not yet taken advantage of the Composite Resource Repository, upgrading is a more efficient way to leverage your Magic application and modernize your application. All development becomes manual in C# and Java and loses the significant inherent advantages of platform based computing. For additional information on how an upgrade is superior to Magic to .NET conversion please convert here.

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.