Skip to main content

Full of CRUD

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:

  1. Migrate to Oracle ADF
  2. Migrate to Oracle APEX
  3. 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.

My advice when choosing a platform to migrate Oracle Forms to: take a long, hard look at your developers, and note where their talents are.  Ask them if they think that given some time and training if they would be able to continue to maintain applications in another technology at the same level they do today.  If they believe that this is possible, then consider that alternative technology - be it Java, .NET or something else entirely.  But if they believe that their talents are in PL/SQL and the Oracle Database - and you'll likely have the investment by way of PL/SQL-based business logic to prove it - then you owe it to yourself to take an equally long, hard look as APEX as a viable platform to replace Oracle Forms.

Comments

Anonymous said…
I agree completely. With due respect to Joel, Scott has a much more nuanced rebuttal to the Gartner analyst.
raoul said…
"The key factor that was largely ignored in this and so many other migration papers is simple: people."
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.
Learco Brizzi said…
Great post!
Noons said…
The fallacy of the article is that it assumes anyone using Java is automatically a high quality developer/designer - bordering on expert - in web technology.

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.
Peeteba said…
Amen to that Scott! A sharply written, thoughtful and constructive response.
Niels de Bruijn said…
I completely agree with you. People tend to compare APEX with ADF and they just shouldn't. Who sponsored Gartner to write such an article?
Marco Gralike said…
@Niels de Bruijn

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"

Popular posts from this blog

Custom Export to CSV

It's been a while since I've updated my blog. I've been quite busy lately, and just have not had the time that I used to. We're expecting our 1st child in just a few short weeks now, so most of my free time has been spent learning Lamaze breathing, making the weekly run to Babies R Us, and relocating my office from the larger room upstairs to the smaller one downstairs - which I do happen to like MUCH more than I had anticipated. I have everything I need within a short walk - a bathroom, beer fridge, and 52" HD TV. I only need to go upstairs to eat and sleep now, but alas, this will all change soon... Recently, I was asked if you could change the way Export to CSV in ApEx works. The short answer is, of course, no. But it's not too difficult to "roll your own" CSV export procedure. Why would you want to do this? Well, the customer's requirement was to manipulate some data when the Export link was clicked, and then export it to CSV in a forma

Refreshing PL/SQL Regions in APEX

If you've been using APEX long enough, you've probably used a PL/SQL Region to render some sort of HTML that the APEX built-in components simply can't handle. Perhaps a complex chart or region that has a lot of custom content and/or layout. While best practices may be to use an APEX component, or if not, build a plugin, we all know that sometimes reality doesn't give us that kind of time or flexibility. While the PL/SQL Region is quite powerful, it still lacks a key feature: the ability to be refreshed by a Dynamic Action. This is true even in APEX 5. Fortunately, there's a simple workaround that only requires a small change to your code: change your procedure to a function and call it from a Classic Report region. In changing your procedure to a function, you'll likely only need to make one type of change: converting and htp.prn calls to instead populate and return a variable at the end of the function. Most, if not all of the rest of the code can rem

Logging APEX Report Downloads

A customer recently asked how APEX could track who clicked “download” from an Interactive Grid.  After some quick searching of the logs, I realized that APEX simply does not record this type of activity, aside from a simple page view type of “AJAX” entry.  This was not specific enough, and of course, led to the next question - can we prevent users from downloading data from a grid entirely? I knew that any Javascript-based solution would fall short of their security requirements, since it is trivial to reconstruct the URL pattern required to initiate a download, even if the Javascript had removed the option from the menu.  Thus, I had to consider a PL/SQL-based approach - one that could not be bypassed by a malicious end user. To solve this problem, I turned to APEX’s Initialization PL/SQL Code parameter.  Any PL/SQL code entered in this region will be executed before any other APEX-related process.  Thus, it is literally the first place that a developer can interact with an APEX p