SAP Says J2EE Devs Opps Arise from Biz Needs

Enterprise software maker SAP has some strong advice for Java/J2EE developers concerned about outsourcing: Focus your energies on your company's business problems -- and not slow-moving Java standards. Integration Developer News spoke with SAP's chief standards-watcher, Michael Bechauf. who offers Java/J2EE devs four (4) keys for how to find the best enterprise dev career opps in the coming two years. (WARNING: Some may find these controversial.)

Tags: Bechauf, Java/J2EE, Business, Developers, Java, Portability, JCP,

Java/J2EE pros looking to keep career prospects healthy should pay close attention to their own company's executive suite -- and not as much to Java/J2EE standards groups.

That's the advice of SAP's chief standards-watcher Michael Bechauf, who serves as SAP's vice president of NetWeaver standards. In his post, Bechauf works with and tracks work from the country's leading standards group and consortia on Java and web services, including JCP (Java Community Process), the WS-I (Web Services Interoperability Organization) and OASIS (Organization for the Advancement of Structured Information Standards).

Bechauf offers Java/J2EE devs four (4) key suggestions for how they can find the best opportunities in the coming two years. (WARNING: Some may find these controversial.) In brief, Bechauf says:

1. Set aside Java/J2EE portability concerns (Vendors have already "sacrificed" portability.);

2. The JCP won't be able to give you the "next" Java career map;

3. Focus on "portable data" not just portable code: (Devs that know how to move data and rules around an enterprise;

4. Take a fresh look at persistence (Base it on business needs, not just language needs).

To learn more about SAP's views on how Java/J2EE devs should prepare their careers for the next two years, IDN spoke in depth with Bechauf to gain some "insider insights" from a Java standards participant on why devs focusing on Java acronyms might be missing out.

Where Java/J2EE Devs Should and Shouldn't Focus
"Being a Java/J2EE technology expert, even in such specialized areas as persistence, EJBs and JDO, will soon not be enough to secure a high salary," Bechauf told Integration Developer News. "If you look at what the highly paid people have done over the past 2-3 years, you'll notice that they've refocused on being able to understand which technology approaches are best used for each business purpose."

Bechauf's views, while controversial, are borne out by his daily conversations with F1000 customers. Customers, Bechauf says, are increasingly looking for talent people inside their business who can help them get more control over skyrocketing IT spending and lengthy build cycles. The Java/J2EE devs (or .NET devs) who step up to fill that need, Bechauf insists, will be the ones whose careers will prosper well into the 2000s.

"If I were to guess what Java devs need to learn in the next two years, they clearly need to move away from only knowing about the technology and more toward a broader understanding of their company's business processes," Bechauf told IDN.

Translation: Standards-watching may be important for vendors, but Bechauf recommends that end-user Java/J2EE devs and architects would be much better served by paying attention to their boss than by discussions in standards groups or even online forums.

But aren't JCP standards mega-important to all Java/J2EE devs? Aren't they the key to keeping Microsoft at bay, and pushing the Java/J2EE state-of-the-art forward with vendors agreeing on core portability concepts and innovating at the edges? Bechauf is not so sure.

  • 1. Set Aside Java's Portability Concerns
    In fact, Bechauf openly wonders whether Java portability is about to be lost. With so many Java/J2EE vendors innovating at all levels -- IDEs, plug-ins, bean patterns, XML support, etc., he told IDN, "I would argue that [Java] portability right now is already sacrificed."

    Bechauf submits that the idea of Java portability continues to be important to Java/J2EE vendors (who want to compete for business with companies who have installed another vendor's Java platform), and to Java/J2EE developers (who want to make sure they can change jobs easily). But Bechauf adds that today's end-user executives have priorities higher than [Java] portability.

    "If you take portability from [an end user] perspective, that's not what matters today. What matters to them today is: How do you build your UI? How do you build database persistence? How do you increase productivity for your applications?" His evidence for this shift is direct: simple day-to-day experiences and discussions with SAP customers.

    According to Bechauf, over the last several years, many Java vendors, including SAP, have created proprietary extensions to the Java/J2EE standard. "These extensions are often proprietary and are based on who our target customer is, Bechauf said. "The target customers of many Java vendors are very different, and so the extensions each vendor will build will be different. At SAP, our target customer is predominantly the business application developer who is focused on database portability."

    Bechauf told IDN that SAP's customer is much more concerned about getting his data across multiple systems than he is about portability of a single J2EE feature to [run on] another platform. "So, our customer's concern is very much on software logistics: Can I easily install a patch or upgrade 20,000 times? How long does it take to install? Can I offer a hot patch to 20,000 customers, across to my distributors, partners or others in my supply chain?" he explained.

    2. JCP Won't Set the Career Map
    "The days when the Java developer can guarantee a career by just adopting the [latest] JCP technology that gets adopted are over," Bechauf told ID. Despite recent upgrades, the JCP process remains slow and complex, and "really too complicated for the average [Java/J2EE] developer to rely on."

    In fact, as Bechauf sees it, some visions of the JCP may actually make it harder -- not easier -- for Java devs to boost their career prospects. He worries that the JCP may be overstepping or over-engineering the J2EE stack. "Certain types of today's APIs, and some new specs such as the JBI, are not necessarily something that the true majority of application developers should care about," Bechauf said. "Many of these [APIs and JSRs] are not what today's Java developer/architect that works for an end-user IT shop should worry about -- these are issues that the J2EE or adapter vendors should care about."

    Take a look at a partial list of Java/J2EE standards initiatives that Bechauf follows for SAP, and see where he notes some cracks.

    JBI --"JBI is really an infrastructure-related JSR. SAP has been in the Expert Group for quite some time, but we're not 100% clear to us where all this is going. There was a true plug-and-play framework for adapters that was discussed, but there's not a clear picture yet of just how business intelligence will be dealt with in Java. As it stands right now, JBI still hasn't clearly articulated what it wants to do. There are a lot of ideas, but there's not a fully finalized draft spec out there, and we're waiting for the spec lead to address where this is going."

  • JCA -- JCA lays certain ground rules for how to integrate external third-party adapters into J2EE, but it misses fundamental parts, such as: What about message format? Here's why Bechauf says the issue of message format is important for Java/J2EE devs: "If you have an adapter and [introduce] some sort of normalized XML message into the adapter, how will that be exactly translated into the proprietary adapter? If you want a true plug-and-play framework, that's the very minimum you need to agree upon."

  • BPEL --"There's an issue when it comes to having Java developers get more exposure to business rules and workflows. For example, there are many discussions around how to easily plug business process engines, like BPEL engine, into a service bus."
  • EJB 3.0 --"Maybe EJB 3.0, for example, will be a revolution. But developers should also consider that it's possible that each [Java] vendor will adopt proprietary extensions to EJB 3.0's basic principles. In either case, CMP (Container-Managed Persistence) remains a very tricky operation for even the most experienced developer, and solutions developers can use for persistence should be easier to choose, implement and test."
  • Despite the highly publicized work the JCP is doing with EJB 3.0, Bechauf is a bit dubious about Java/J2EE developers who put all their career eggs in the JCP basket. In fact, Bechauf said the recent buzz around EJB 3.0, along with an explosion of individual JSRs, may be building a false sense of security among the Java/J2EE hierarchy. "We're now faced with a more fundamental question," Bechauf said, "which is 'Where should the JCP go from here?'"

    To Bechauf, the rush of JCP activity is a "mad attempt" to fend off Microsoft's assault on the server side of computing (via .NET, BizTalk and other platform upgrades).

    He concedes that he's concerned that the JCP may be a bit off track, even as the community process has been very busy taking on issues on a number of fronts, including
  • a wide array of JSR proposals in support of web services, business workflows and integration-directed technologies;
  • steps to speed up the JSR process; and even
  • rules changes to bring new developer and end-user voices in under the JCP tent.

  • While Bechauf quickly agrees that each of these goals are important to the overall future of enterprise Java, he's not so sure that the JCP should be taking on these roles. "We need to ask what exactly is the focus that the [Java/J2EE] community at large should have. I think we would find that vendors and end-users may differ on that question."

    The debate over [Java's plumbing] should be over, or at least should be of less importance," Bechauf said. "The only problem that Java has at the moment, it still doesn't have the level of maturity where you can basically say, 'Describe me your business problem, and then I can map that problem into software.'"

    3. Focus on Portable Data, Not Code
    At SAP, Bechauf admits that database portability is "extremely, extremely important for us." The reason: "Part of SAP's value proposition is that we want to work with every database." Bechauf even suggests that this focus on database portability -- rather than Java/J2EE code portability -- could lead to more Java/J2EE career opportunities, not fewer.

    "We think that if [Java vendors] were focusing on database portability, that would free developer and architect brains for business rules," Bechauf said. "So, instead of focusing on the whole [Java] stack, which seems to be where the JCP wants to take developers, why not just let them focus on where the greatest opportunity is?"

    If Bechauf sounds a bit flippant, he doesn't mean to. In fact, he comes to this conclusion from a close look at SAP's own history of success in becoming the largest ERP vendor. Bechauf predicts that the technology and business conditions of the mid-1990s that led to SAP's explosive success are about to be duplicated in the mid-2000s. Developers should pay close attention, because what on the surface might look like technological confusions are really career opportunities in disguise -- for those Java/J2EE developers willing to look outside their technical box.

    Let's take a closer look at why Bechauf sees portable data as just important, if not more so, than portable code. "As SAP started out, we had the goal to give business application developers all the tools they needed to focus their efforts on solving the business tasks at hand," Bechauf said. "At that time, there was no single [programming] language that could do that, and so we developed a proprietary development language (ABAP) that would give technical developers a means to implement business solutions in an easier way, compared to other solutions available at the time," he added.

    4) A New Perspective on Persistence -- Beyond J2EE
    One of the keys to ABAP's value-add, Bechauf said, was that it would take care of all the necessary, mind-bending details to ensure that data from one application or database could be shared (and mean the same thing) with data from other locations and applications -- even outside the company with outside partners. This care to cross-platform data portability also roughly corresponded to how a business exec might think of "persistence" -- keeping data consistent and unchanged across multiple applications/connections.

    "From the very beginning, we agreed upon [common] terminologies that could be used to start and/or expand a data dictionary," Bechauf explained. "This meant that the developer or designer didn't have to worry about specific data types: They could simply deal with something called a 'currency' or 'address' and it would be understandable throughout [the application]. How this was exactly mapped to the database, aligning the differences in data definition languages used by different databases, was something we did [under the covers] so that this wouldn't be a big concern to the application developer."

    This business-driven approach to solving the problem of "persistence" (persistence of data across multiple nodes, at least) paid mega-dividends to SAP. "This approach to solving a business problem [related] to building and deploying the application was one of our biggest value-adds, early on and even today," Bechauf told IDN.

    While ABAP remains SAP's proprietary language, it has evolved in some notable ways that may sound familiar to the standards-driven Java/J2EE developer, Bechauf said. For instance, ABAP is now more accommodating with mainstream languages and standards, such as Java/J2EE, XML and .NET. In fact, SAP engineers are even collaborating with Java and .NET design engineers to make sure the ties between ABAP, Java/J2EE and .NET remain tight, even as new versions of all languages are in various stages of beta and commercial release.

    But, Bechauf adds, SAP's motivation for keeping ABAP compliant with other languages differs greatly for how the Java/J2EE looks at the world. "Standards or portability were not the main focus of ABAP," Bechauf said. "[ABAP's main focus] was, and still is, the need to give developers a way to better understand how to support their business's needs, and how to build solutions that reflect those business needs. And Java is just not there, still. On its own, at least, it [Java/J2EE] isn't capable of easily helping technologists deliver an end-to-end business solution."

    This database-centric view of persistence stands in contrast to several longstanding issues J2EE devs face when attacking the problem persistence, in Bechauf's view. "It still seems almost like a black art to understand which persistence solution is the right choice for a particular business problem. There are multiple schools of thought" that have plusses and minuses (such as JDO or EJBs), but they are all based on the technology involved, not on the business application. Even the new discussions surrounding persistence for the new EJB 3.0 won't fully address the fact that developers need to get better acquainted with business rules, Bechauf added.

    "It's hard for me to guess how this all will come out, but I hope there will be a powerful solution that addresses business needs," Bechauf said. "Hopefully, developers won't have to choose or get locked into A, B or C [technology] option, but you choose one technology and you choose the option you need."

    J2EE Stack, Careers at the Crossroads
    So, as Bechauf sees it, the Java/J2EE community is at a crossroads on how best to blend the needs of the business CxO exec with the need to maintain a broad Java/J2EE technology base that will meet as many needs as possible, for both the technician and the business professional.

    Java/J2EE techniques and technologies are not always able to meet these growing business demands, Bechauf said. And the Java/J2EE community is not always willing to face this fact. Often, this can mean a Java/J2EE career opportunity might be lost. Bechauf offered a use case to illustrate how pursuit of portability can take a high price from some Java/J2EE careers.

    "In our case, SAP recognized that we can't always completely give control to the [J2EE] container. But, no matter what persistence solution we use, we make sure there is an underlying common database layer that specifically addresses database portability in the data dictionary," Bechauf said. "We follow standards and specs where possible, but we never can lose focus on our value proposition -- and that is to let the application developer focus on what the business application task requires."