Are youconsidering your career path in the Oracle core technology arena? Missing 1/2 a brain? Then consider a career in database administration (haha, only joking, really, I have plenty of DBA friends and they all have more than 1/2 a brain ;)
Or are you a traditional Oracle Forms or Reports developer who shies away from DBA work because you think DBA work is dull (haha, no really, I'm only joking), aren't actually scared of users (still a joke, I kid you not), and think optimisation is something left for, well, who cares?
The problem for traditional Oracle developers, for those actually concerned about career development while remaining a developer (and by this I mean you have aspirations to stay a programmer, become a top notch developer, you're not retiring soon, you don't want to become a manager, or worse yet, a DBA (seriously I really am joking)), is where do you go from here, given the traditional development areas are dying (ie. Forms & Reports), while sticking in the Oracle core-tech area, where all the big money and good looking people are?
(Alright, I'm being discriminatory to DBAs in this post, but a little fun never hurt anyone, except my DBA pals who get this all the time ;)
As far as can be made out at the moment, traditional Oracle developers have the following avenues to go down:
0) Convert to the dark-side and learn .Net or Ruby on Rails
1) Don't learn anything knew and retire using traditional Oracle development tools like Forms.... knowing good and well that Cobol programmers are now rolling in cash, so you will too (anybody actually ever encountered a rich Cobol programmer?..... oh, and, is, um, willing to give me some cash?)
2) Application Express aka Apex aka HTML DB aka mod_plsql with flashy bits and yet another respository
3) JDeveloper with ADF Business Components and ADF Faces
(oh, and maybe #4, XML/BI Publisher - which I'll leave out of this discussion)
Let's investigate these options.
#0, ah, no, that's an entirely different post.
#1 assumes that the Oracle Forms world is dying. Actually, it's not, but don't expect anything exciting to happen in the Forms arena any time soon. Are you happy extending existing Forms systems, like a safe job, and no interest in learning new stuff? Stick to Forms, though I question why you're in computing in the first place? Have you forgotten the chase .... learning new technologies, making your users "oooooh" and "ahhhhh", making your fellow programmers jealous with tales of the latest technologies you get to play with, the thrill of project deadlines, the thrill of finding bugs and passing those project deadlines, the excitement as the boss shakes your hand and says "Well done Jones" (even if your name isn't Jones)?
What about #2, Apex (Application Express)? Weeeeeeeeeell, here's my sticking point with Apex: Apex is too proprietary compared to JDeveloper and is worse for your developer career path. Coincidentally in this manner Apex is just like Forms - and by this I mean have you ever leaped to a new development environment and said - "Ah, this is just like Oracle Forms"? No, well that's because not much else does what Forms does these days - so what you've learnt wont really help you elsewhere. Bang goes the career path with Forms or Apex.
This isn't to say JDev doesn't include proprietary technology, because it does. Lets explain this a little bit more when considering Apex....
Why? JDeveloper's ADF is based on something called the MVC design pattern. This software architecture pattern is used heavily in 3-tier based systems (MVC is non existent in Forms) and among other technologies (including Ruby on Rails if we want to name a buzz-world compliant language/framework), and is used within the J2EE world for building enterprise scale applications (and remember, most of the work in the Oracle arena is in enterprise apps, not dinky little apps running standalone on a PC).
The key to the MVC architecture is that it allows us to build and swap-in separate technologies to deal with the model (ie. the persistence API that talks to the database), the view end (ie. the UI technology such as JSF, ADF Faces, Swing etc) for rendering the user interface (UI) and controller technologies (simplistically the bit that co-ordinates the M and the V).
For a Forms programmer moving to the JDev ADF world, the developer is encouraged to use ADF Business Components, and ADF Faces.
Now once you've been exposed to 1 set of Model or View technologies, be they
As you become more proficient in Java, and look at these other technologies, and even non-Java based solutions, you start to ask some really tough questions of new emerging technologies..... is it stateful or stateless? Does it provide failover? Can it scale? does it handle the browser back button? can it plug into our SSO services .... and so on .... (Don't know what I'm talking about? Turn to the JDeveloper side my apprentice ;)
One of the other career benefits is, unlike if the Forms or Apex market dies, if one of the technologies you've been using in the JDev sphere (or Java sphere) is quickly superseded by one of the other players, say ADF BC falls to EJB 3.0, at least you're knowledge isn't so heavily wrapped around a proprietary solution, and you don't get the sack.
The beauty too, is once you're at this level, you're no longer just a simple old Oracle developer, you're way on the right track to become a hot Oracle programmer who will be directing projects at your organisation, driving hot cars, and making a fortune on the stock market (well, 1 out of 3 ain't bad).
Surely this has got to be better than being a DBA, Forms or Apex programmer for the rest of your (programmer) life ;)
[This post was inspired by Grant Ronald's recent post What is faster for development: Oracle Forms or JDeveloper? Grant's article is a great one in telling you how simple JDev programming is becoming.... but I wanted to consider besides the technology "why", from the developer's career path, you should consider JDev]Epilogue: Oracle developers should also carefully consider JDeveloper as there has been many comments that Oracle's EBS v12 and the whole Fusion stack will use JDeveloper technologies. The point being is if you're organisation uses these technologies and you are tasked to extend them, JDeveloper will be the tool that you use to do these. I've not been exposed to either of these technologies (EBS v12 or Fusion) so please take this comment with a grain of salt, unless somebody is willing to post a link to any webpages that prove this fact.
Epliogue x 2: The other purpose behind this post is to start discussions about which *is* better, JDev + ADF or Apex. Currently Oracle is IMHO being "Mum" about this. Given that there are dozens of bloggers now selling, um, promoting Apex and JDeveloper, what about their thoughts on which is they way to go?.... with consideration from all sorts of angles like scalability, skill sets required, failover support, ease of development and so on.