Joel Kallman has an interesting and amusing reaction to a recent Gartner paper authored by Mark Driver posted here. After reading Joel's reply and Mark's paper, it got me thinking a bit about what was both in and not in the Gartner review and conclusions regarding Oracle Forms migration paths.
But before that, let's consider the longevity of Oracle Forms. Oracle has pledged support for Forms time and time again, and despite the negative stigma that Forms usually drags along with it about being an older technology, it's a perfectly good place to leave any existing applications and perhaps even build a few new ones. Thus, if you have no immediate need to urge to migrate, then simply don't do it. In fact, a new version of Oracle Forms - 12c - is already in development and will integrate with Fusion Middleware 12c.
If you're a Forms customer and for whatever reason want out, there's a number of different options that you can take, all of which are highlighted in the paper:
- Migrate to Oracle ADF
- Migrate to Oracle APEX
- Migrate to a non-Oracle platform
I'm going to ignore the third option - not because it's not a viable one, but my point lies elsewhere.
Given that exclusion, which works best as a Forms migration platform - ADF or APEX?
In the paper, Driver makes a very clear case for ADF over APEX. He considers APEX a tool targeted at "citizen developers" and considers it "less suited for elements of Oracle Forms applications with more complex business logic requirements". He also states that APEX has "very limited support for advanced software development life cycle (SDLC) and application life cycle management (ALM) feature and best practices (e.g., no team support and no direct source code versioning).".
Five years ago, I may be tempted to agree with some or part of that. But clearly not today. APEX 4.1 is a major upgrade from what was available in versions 3.2 and prior. While it definitely excels at building small, "quick hit" type applications, all - not some - but each and every one of our clients are also using APEX for mission critical and essential systems on a daily basis; Applications that drive their primary business operations, whether those are academic, commercial or governmental in nature.
Since 4.0, APEX has incorporated a "Team Development" module, aimed at facilitating the development, bug tracking and release process of APEX applications. The APEX team at Oracle actually uses this tool to track the development of APEX itself. APEX can also work quite well with any source code control system, although not directly. But since most developers put their business rules in PL/SQL, that tends not to be an issue, as all popular PL/SQL IDEs have direct integration with source code control.
While those misstated facts are bothersome, I don't believe they are intentional. I can easily get past them, as we all make mistakes from time to time. What I have a harder time accepting are the misleading statements in the following excerpt:
Select a migration target platform carefully. We believe the least risky (and often the least costly) migration path forward from Oracle Forms is Oracle's JDeveloper IDE and ADF — especially for application leaders who plan to retain their existing programming staff.
Now I have taught countless APEX training classes and have talked to many, many Oracle customers over my 15+ years of working with Oracle products. Never have I ever heard a single person highlight how much easier Java is than APEX. Some put APEX on par with ADF, and others think that ADF as a whole is better suited for enterprise development, and I can't say that I disagree with those assessments. Clearly there is some bias in my sample, but the most vocal of the group were those who were professional developers, not "citizen developers".
As for costs, I'd like to see some figures or numbers behind that argument. Not only is there the possibility of saving some license costs by moving to APEX, but many of our customers actually save on consulting costs by being able to take full ownership of the applications once we deliver them. They don't need to hire consultants to continue to maintain their applications, as they almost always learn how to do that themselves, either from training or their own experience with APEX.
Unless Driver advocates firing your existing staff and starting anew with fresh college graduates for about half the salary, I don't see what basis he is using for his point about retaining programming staff. Allow me to be blunt for a moment: most Oracle Forms developers know PL/SQL and the Oracle Database very well. Given the age of Oracle Forms, most Forms developers are closer to retirement than they are their first day on the job. What type of developer is willing to forego 20+ years of experience in any technology and start fresh learning another technology 3/4 of the way through their career?
The key factor that was largely ignored in this and so many other migration papers is simple: people.
APEX gives developers a new lease on life, so to speak. It gives the PL/SQL developer a chance to once again shine by building web-based applications that their customers will not only love, but want to use. It keeps resources in place with minimal training, and also preserves the years and countless dollars invested in the PL/SQL packages that have been finely tuned over the years.
Java - much like any other programming language - takes years to master. I have tremendous respect for those who have done so. Experts are not made overnight, they are crafted over many, many years of experience. No book or class can substitute for that. Driver's advice assumes that a PL/SQL programmer is the same as a Java programmer, or at least a PL/SQL programmer can easily be made into a Java programmer with a couple weeks of training and a good book. This assumption is just plain wrong, and almost fatally damages his justifications against APEX as a viable Oracle Forms alternative.
Comments
With this I totally agree. Making a good application or migrating one depends on the developers. Ask them what the best way is to go.
I have yet to find any so-called Jave expert to be of any use in, for example, web-based development.
Let's be very precise here: Java is a programming language. Not a development environment/architecture!
Now, if someone claims that j2ee or faces or ajax are java-based architectures that have a lot of value in them to be used for web-related development, I am 100% in agreement. (But that is NOT what the article claimed!)
Does that in any way, shape or format mean that a Java "expert" is automatically an expert in ALL of those?
Find me one! And I mean it!
This is where all these articles, purporting to equate "java knowledge" with "expertise in everything IT", fail. Abismally.
I have over the last 10 years followed just about every major java web-based development in NSW, Australia.
With few exceptions, most of those projects have grossly under-performed. In late delivery - and in many instances just plain non-delivery! Most went grossly over-budget and many were just simply cancelled due to the astronomical costs and delays.
And most had to be "re-architected" and re-factored" long before reaching completion.
That is NOT the hallmark of expertise or efficiency, in any language!
In that same period, I followed three major Forms design/development projects and various Apex ones.
ALL where successful, on-time and on-budget. No exception.
Give me Apex/Forms any day, for any small to medium size development project.
No apologies.
Garner consists of people. People make mistakes...we are allowed to fail from time to time as long as we keep thinking. Gartner is not the equivalent to "TRUE"