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.

Tags: J2EE, Developers, BEA, Willis, Business, J2EE Devs, Integration,

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
  • Don't Count on becoming a "Middleware" Expert -- J2EE devs should not just rush out and learn middleware skills. "Writing your own middleware layer is also not a place the ambitious J2EE developer should be, Willis said. "That's not where the value-add is anymore. The true value-add that's coming is for developers to understand the business requirements and help the business more effectively and quickly create competitive advantage.

  • Don't Count on becoming an "Architect" -- "The role of architects will become less and less widespread, because the best practices will be in the framework," Willis said. "People may have that job title, but I think that job title will change and become more practical and less theoretical and it will be more about a given application and how does that app end up in deployment. "

  • Don't ONLY Count on J2EE 1.4 or EJB 3.0 -- While J2EE 1.4 is certainly a step in the right direction for helping J2EE developers learn more about web services, Willis said the latest upgrade doesn't go far enough to help devs with higher-level SOA, workflow and orchestration skills. "I don't think J2EE 1.4 takes us there. I look at the different elements of 1.4 and I think it's the next logical step for the J2EE standard but it does not provide a programming model or abstraction that makes it dramatically easier to program," Willis said. "J2EE 1.4 appears to me to be extensions on core J2EE rather than much simpler extraction of more complex [processes]."

  • Don't Look ONLY to J2EE Experts -- SOA Best Practices are still hard to come by, Willis said. While BEA is working with The Middleware Company to create some industry-wide SOA Blueprints, they just don't exist for Java developers -- yet. "I think the state of the art leaves a lot to be desired. . Like, it's crazy there is not a service-oriented version of Java PetStore," Willis said. "That's an area where Microsoft has quite a significant investment that's worked out well. .NET gives a lot of folks in the Java world a great design pattern, a good idea about how application design can get a lot more productive, so we need to take some queues from them. I think we [in Java] need to do that in the J2EE world."

    "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.

  • Learn More About Your Industry -- "Our core hypothesis is that Java developers need to better understand their business," Willis said. "And while we are offering tools that will help abstract some complexity of plumbing or integration, we don't think it's good to abstract the developer from a basic business understanding, or as a crutch for needing to learn how their business processes operate or what types of transactions support or application upgrades they need." But more than simply better understand the workings of the business, BEA execs also suggest devs pay great attention to several key technical elements, such as schema (XML), workflow, and new industry-wide standards (not just Java) coming down the pike.

  • Learn More about Schemas -- For all the talk about how XML may be irrelevant to Java/J2EE programmers, BEA takes the view that in SOA all traffic will be in the form of XML documents, and ensuring communications between end points (and compatibility among document fields, such as defining a PO) will come from knowing XML. As a consequence: "A solid understanding of XML will be key, not only XML schema and XML techs like XQuery. The data is going to be just as important as having relational data and modeling skills.," a technical BEA exec told IDN.

    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.

  • Learn More About Workflows/Orchestration -- BPELJ is just a matter of time, BEA execs say. BPEL is an agreed upon approach by Java vendors and Microsoft (on the brink of being formally adopted as a standard by OASIS for workflow). " The [development] tools layer is going to business process design and orchestration. So, any developer seriously looking at doing that with tools will do it with BPEL, which is about process workflow from machine to machine -- not human workflow at the point." BEA has also made contributions to other tools/technologies that can jumpstart J2EE devs in this area, including its work on SOA Blueprints (in cooperation with The Middleware Co.) and Beehive project -- its decision to Open Source portions of its Weblogic Workshop developer environment. (and hand-over to the Apache Software Foundation for management)

  • Watch for More OASIS Standards -- BPEL and standard schemas are both for Java-to-non-Java interoperability, BEA execs say. But, J2EE devs should also keep their eyes on other OASIS standards for workflow and orchestration. Here's a business case from BEA for why devs can't have enough background on setting up and managing workflows: "If I'm working in IT for Wal-Mart, and I need to support integration of my systems with Johnson & Johnson's manufacturing or inventory systems, it's important for me to know what the correspondence rules are and what the business contract rules are, and things that make a communications go smoothly, like the definition of a purchase order or an invoice," one BEA technical exec told IDN. BPELJ and XML schema give J2EE devs a good grasp of the workings that go into this kind of project.