BEA: J2EE Career Devs Need To Look Past APIs
BEA's exes say its "Liquid Computing" view of SOA should signal the end of an era for J2EE developers. The time has passed where knowing Java APIs will be marketable, BEA execs told IDN. See BEA's 'Do's and Don't" for J2EE devs, and why they need to focus on life outside-the-container, including business rules, schemas and even integration and sharing with NET and Open Source.
Execs from BEA, the company that first saw the immense market potential of J2EE containers, says savvy J2EE developers should use take their Liquid Computing plans (outlined at last week's eWorld) as a signal that CIOs/CFOs will expect more from their J2EE developers.
Tops of "want lists" for J2EE devs in the coming years will include:
(1) More productivity;
(2) Better alignment with business needs; and
(3) More skills to dealing with code/application needs outside the J2EE container (in things like integration, interoperability, and B2B communications).
"The idea that companies will continue to fund ongoing coding is just disappearing.," Cornelius Willis, vice president of BEA's developer marketing told IDN. "Customers' tolerance for new application development is extremely low. They are so much less interested in deploying new applications or coding new apps. So, the message to J2EE developers is becoming quite simple: 'You don't need to build huge backend applications. It's about how quickly you can apply the technology to the business opportunity'," Willis said.
IDN has interviewed Willis and a number of other BEA execs to take a deeper look at why BEA says the climate for J2EE development is changing, and what new skills J2EE devs should focus on.
So, what exactly do CIOs/CFOs want from their IT developer staff? Willis said that BEA "is seeing is that customers really just want to get their existing applications into maintenance mode." Rather than cope with one-off application projects, Willis told IDN that BEA's customers want a "maintenance infrastructure" for the code and applications and business rules they've already built. "Instead of coding new functionality from scratch, they want to be able to configure existing code and have that respond to the new needs of their business."
So, what might that mean for J2EE devs? "Being an expert in APIs and subsets of APIs is going to be increasingly less marketable," Willis said. "I think that's pretty obvious to anybody watching the situation. I don't think that's a controversial statement anymore." He quickly added that impacts on J2EE devs are industry-wide and not specific to BEA's SOA approach.
"All the J2EE vendors today are all working hard on good abstractions for all sorts of Java/J2EE functionality," Willis said. "BEA has a programming framework, but work is also on-going at Oracle, IBM, Sun and many tools vendors. We think we have a two-year lead on them, but the overall goal of all this work is pretty clear: all J2EE vendors are working hard to increase productivity of the J2EE programmer by an order of magnitude. The financial realities from customers are forcing us to. "
Inside the 'Application Maintenance Infrastructure'
Willis concedes that "Many CFOs or CTOs may not see the entire benefits picture from a services-oriented approach." But, he hastened to add:: "One thing for sure. "They do understand that they cannot afford to keep going with a 'business-as-usual' approach to app support and development. Customers tell us every day that their systems are just too hard to maintain, and that it's taking them months and months to build something that should only take weeks or days."
Tops on their list of "maintenance" functions are data and application integration projects, especially ones that ties J2EE container assets to others throughout the enterprise, including .NET and legacy platforms. "We see that in the future all development will be integration, and all integration will involve development," Willis said.
"Increasingly, there will be a developer model for converting existing corporate applications into services," which, he said, will make it much easier and cost-effective for developers to do updates, deployments and cross-platform integrations.
The key to J2EE professionals participating in this trend, Willis and others at BEA say, is to look beyond the J2EE Container. In fact, with its Liquid Computing initiative, BEA is in effect telling J2EE developers that rather than the container being the center of the J2EE developer's universe, it becomes a focal point for interoperability, integration and sharing, said Peter Linkin, BEA's Senior Director of Product Marketing for BEA's Integration Solutions unit. Linkin, most recently from integration broker vendor Vitria, says that integration will increasingly become a responsibility of the enterprise developer -- Java, .NET and even C++.
Staying in Demand
"Those developers in the most demand will be those that can best adapt to business requirements, and match their skills to those requirements," Linkin said. "It will mean more than just knowing about EJBs and message queues. It will mean they will need to know about reuse and manageability of code, and think of applications as loosely-coupled components."
[BEA's QuickSilver project one implementation of this vision. While no shipdate has been announced, the BEA vision is to provide J2EE developers a console-driven suite of integration software built around Web services protocols, the purpose is to enable them to transport data and business rules between Java and non-Java systems with as little coding as possible, using abstractions and an integration-enabled container (tied into the development/deployment console).]
To help J2EE devs attack this challenge head-on, BEA is bolding moving to bring abstractions to as many levels of J2EE code development as possible, including plumbing, workflow, business rules/triggers, and even modeling. "In general, CTOs want developers to get more involved with integration as not just a way to tie applications together, but to make applications more easily to upgrade and mange," Linkin said.
BEA's Don't's and Do's for J2EE Developers
BEA execs have a short list of don't (and do's) for J2EE developers looking to polish their skills for the SOA-driven world.
First, some eye-popping don'ts
"In two years," Willis added, "a successful senior developer (J2EE or in any language) will know how to use a given vendor's toolkit, be able to translate their project's application requirements, and do an implementation -- all without a middleman architect or business/workflow requirements person."
So, What's a J2EE Dev To Do?
For all the mis-steps that a J2EE dev could take, BEA has some suggestions where J2EE devs could make good investments of their time.
When BEA looks at SOAs, developers are dealing with services and end points that are standardized. We're basically sending XML or a document, between these end points and what's behind these end points is of almost no concern. A dev is not going to be worried about on-the-wire stuff, in fact, developers may be dealing with applications written not just in Java, but in Perl, Python, Ruby and .NET. But, you are concerned with how people treat their schemas, the schema will be what dictates the degree of success you'll have in tying your services to the end points.