You've invested tens, if not hundreds, of person years in your application. It has taken years or even decades of elapsed time to develop. While it may have some quirks you'd like to change or features that could be added, it has been customized over time to exactly meet the needs of users.
But you want to move to a modern platform. Why start from scratch? What if there was a way you could continue to capture the value of the asset in which you've invested so much time?
Over the years, millions have gone into development and training costs to get your application to address the needs of your business. Along the way, you've learned what you might have done differently, but by and large, it does exactly what you need. However, license, support, and maintenance costs are largely out of your control.
You want to move to a platform where you have the freedom to develop and deploy your application in the way that makes the most sense to you, without your vendor's licensing model tying your hands. Why start from scratch? What if there was a way you could continue to capture the value of the asset in which you've invested so much capital without paying a vendor in perpetuity?
Your application supports critical business processes. You've invested a lot in user training. Users are familiar with your application; they have muscle memory in their daily work flows. Your developers are familiar with the design and implementation of the application. It is very likely that you've created external interfaces to your application. There is a tremendous investment in knowledge tied to your application.
You want to move to a platform that gives you the freedom to grow in new directions and use new tools, without losing the value of that knowledge.
The Progress ABL market has a single supplier. The technology is closed source, proprietary. So, there is nowhere else to go for licensing, support, maintenance, and new features. This creates very little competitive pressure on pricing and little incentive for innovation. This is not a healthy model for the customer.
The #1 complaint we hear from Progress customers is the high cost of the platform.
Since there is only one vendor, there is very little competitive pressure controlling prices in this market. As a result, you do all the work in developing your application, but you still pay a sizable amount of fees above and beyond that to deploy it, and to support and maintain the platform beneath it. As your user base and choice of deployment platforms increases, so do your costs.
In addition, the pool of available Progress developers is relatively small, so their costs are typically higher than those on other platforms, such as Java.
Finally, some application partners have noted that there is an opportunity cost associated with a Progress application, in that market awareness and acceptance tends to be significantly lower than for that of an open and modern platform like Java.
A language's design defines what an application can do easily and consequently, the application's constraints. As a language originally conceived to be English-like and intuitive, the ABL now suffers from this original design principle and other limitations built into the core platform.
The ABL is a very syntax-heavy language; most new features are supported directly by adding syntax. This syntax has grown over the years to include thousands of keywords in myriad, often inconsistent combinations. This compares to only dozens of keywords and a relatively simple syntax in Java. Since most new Progress development features must be provided in the form of language changes, and there is only one vendor that can modify the core platform, it is difficult for third parties to add value to the platform in a first class manner. The technology ecosystem is thus inherently limited.
The ABL client is a single-threaded, fat client, even when run in batch or Appserver mode. Although the database is multi-user, programs must be written to the client's single-threaded limitation. We have seen this lead to application designs which emulate multi-threading using child processes, coordinated through database or file system locking and polling, or by other external means. These tend to be fragile and inefficient implementations.
The OpenEdge runtime leverages shared memory for efficient data access between client and database. This is certainly an advantage on a single physical system, but it precludes splitting an application design across systems, insofar as that advantage is eliminated by doing so.
Most modern languages support object oriented (OO) and functional programming. The ABL has relatively weak OO facilities and no support for functional code.
By contrast, modern, open platforms such as Java can be extended in a first class manner by any developer. They support multi-threading, first class OO programming, and functional code. They enable efficient and multi-tier application architectures. This flexbility and power enable an entire industry to offer a vast choice of libraries, frameworks, tools, and even languages which add useful functionality to the core platform.
Finally, it should be noted that since conversion with FWD is fully automated and repeatable, it can be integrated into the normal build process. Thus, FWD easily supports continued development with the ABL. Notwithstanding the issues note above, this may be a good choice for some teams for reasons of continuity or just preference.
A major complaint we've heard from Progress customers is that it is hard to find skilled Progress developers, and they tend to be expensive when available. This does not appear to be a population that is growing much, if at all, and certainly not when compared to a platform like Java. This equates to relatively higher cost and higher risk associated with Progress development projects.
We often have heard the rationale that Progress developers justify their higher cost, because they can be more productive with the ABL than a developer of equivalent skill using a third generation language (3GL). However, we would contend that productivity is not an inherent advantage of the platform when developing large scale applications, due to the complexity associated with the enormous amount of implicit behavior in the ABL. We believe that, as a rule, it is the quality of the developer and ones familiarity with the platform and application domain that determines productivity.
With FWD, the direction of future development is up to you. If scarcity and cost of Progress developers is not a pressing issue, or if re-training existing Progress developers to use Java is a concern, you can continue developing in the ABL and just deploy your converted application in Java.
Due to the relatively small size of the Progress market and the fact that the core platform can only be extended by one vendor, there are limited tools available. The lack of third party tools, libraries, and open source projects means that any feature not included in the core platform must be implemented by each team from scratch. This results in duplicated effort and less tested, less robust implementations for common features.
Of course, if you are comfortable with the tools you are using, you can continue to develop in the ABL and just deploy to the Java platform.
Java is an open, modern platform. There are no license fees required to develop and run Java applications. In many cases (see the FWD license requirements), there is no license fee associated with the FWD technology either.
While there certainly are commercial solutions available for Java, there are many, high quality, open source Java libraries and frameworks available at no cost.
Athough the Java platform is stewarded by a single vendor, it has been open source since 2006, and there is a community process for proposing, deliberating, and adding new features. It has attracted the investment of numerous large and small vendors alike, and of millions of developers worldwide. There are countless libraries, frameworks, development tools, open source projects, books, consultants, and training materials available. The technology ecosystem for Java is thriving.
Java has all the facilities one would expect in a modern language, including object oriented programming, functional programming, concurrency, generics, and more. Its modern architecture and extensive facilities enable the creation of robust, scalable systems using well-tested, reusable components.
Java has been adopted on many software and hardware platforms, giving developers a wide variety of deployment choices.
The Java platform is extensible at multiple levels. One easily can create and integrate new libraries in a first class manner. It is even possible to create new, domain specific languages atop the Java virtual machine. In fact, FWD itself does this with an abstract syntax tree processing language known as TRPL ("triple").
First and most obvious, FWD is open source and free (as in free beer) for most simple deployment scenarios. So, many users will have no license costs at all! Even for distribution or hosting models, the cost of a one-time, dual license will be much less expensive than the annual fees Progress customers are accustomed to paying in perpetuity.
Beyond the out-of-pocket savings on fees compared to Progress or some other migration solution, it is important to consider the switching costs of various migration strategies. Due to its core design principles of 100% conversion automation and full runtime compatiblity, FWD is likely to be the fastest and lowest cost option to migrate from the Progress ABL to Java in most cases.
The other most commonly considered options are:
- do nothing;
- a full manual rewrite from scratch;
- a partial manual rewrite, assisted by partial automation.
A full, manual rewrite can at first seem a seductive option. It gives you the chance to correct the mistakes of the past and start fresh. However, the reality of this approach sets in pretty quickly when you consider its actual cost and complexity. If the original application took years or decades to develop, there is no reason to believe replacing it from scratch will be much faster.
If any benefit of the new application is to be realized without waiting many years for the entire effort to complete, it very likely will be necessary to integrate new modules with the original application as they become available. This creates a more fragile, more complex, hybrid application to support for a long period of time. It also will compromise the design of the new application, which now has to support this hybrid, legacy mode.
The development of a replacement application will take a very long time. The original application must be supported and maintained during this period. It would be highly unusual for user/customer requirements to stand still for this long in most organizations, so the original application will require ongoing development for new features as well. Parallel development of a new application thus requires additional development resources.
Clearly, a full, manual rewrite is not the least cost option. So, what about using partial automation to do the "grunt work" of a conversion effort, and manually rewriting only the parts that the partial automation can not handle? At first, this seems like a reasonable approach, but it suffers from many of the same drawbacks as a full rewrite.
If an automation solution is only able to address part of the conversion, it is because it skips the hardest parts and leaves those for you to figure out! While partial solutions may churn through your code base and claim to convert a high percentage of it, you can be sure that those are the areas with the most regular syntax and simpler idioms. Since the result is unfinished, it can't be built, run, and tested immediately. The 80/20 rule applies here. You may end up with "only" 20% or so of your code to rewrite manually, but that will be the 20% that takes 80% of the time to get right. You're still facing years of rewrite effort.
Furthermore, we know of no other automation solution that offers a fully compatible runtime environment. A huge proportion of a Progress application's behavior is due to the highly complex, implicit rules encapsulated into the black box of the ABL runtime environment. It simply is infeasible that any conversion solution without a runtime could produce a compatible converted application. All of that implicit behavior would have to be realized by emitting redundant, explicit, application code. The level of code bloat simply would be impractical.
This leads us to conclude that the result of existing partial automation solutions can not be a compatible application. A different application with new behavior leads to modified work flows and business processes, which results in user retraining. Of course, the application won't run until you finish rewriting all the hardest parts, which isn't likely to be that much faster than that full manual rewrite.
FWD is different. It automates 100% of the conversion, so it converts your entire application. Yes, there is prep work to do and every application has unique challenges to figure out. But that work is done up front, so conversion is repeatable, and the result of each conversion cycle can be compiled, run, and tested immediately using a fully compatible runtime environment. This means less overall project time, even, generally speaking, if gaps in the FWD technology need to be filled or features fixed along the way. This makes FWD the lowest cost conversion option.
All the same reasons that make FWD the least cost option over doing nothing, manually rewriting your application, or using partial automation, also make FWD the least risk approach. A shorter project cycle and lower spend mean lower risk associated with the project.
Consider also that FWD's core design principle of strict runtime compatibility reduces the risk of unknown application behavior. Since FWD produces a functionally identical application, there are no new or different application flows or business processes, so the risk associated with these types of changes is eliminated. Existing features behave as they did before. Unfortunately, existing functional bugs will come along for the ride as well! Testing effort can be limited to ensuring the application behaves identically before and after conversion.
Since FWD is open source, risks associated with proprietary technology are eliminated. You can access the source without reliance on a particular vendor. Troubleshooting and fixing problems is directly under your control.
Multiple applications have been converted and run with FWD, ranging in size from ~250K to ~6 million lines of ABL code. These include ChUI, GUI, batch, and Appserver deployments. The first application converted with FWD was a ChUI application of ~840K lines of ABL code. It has been deployed continuously in a mission critical, production environment at several customer sites, 24x7, without any showstopper problems since 2009.
