Some developers have remarked that it seems SAP is moving
away from classic ABAP development and going toward true object orientation. What does the future
hold for ABAP versus OO?
First off, the majority of SAP code around is still ABAP. However, what we're seeing today is a need to expand beyond pure ABAP, which is why SAP opened up to Java a few years ago. The Java world is very different from what we used to have and offers many advantages. We have our own J2EE engine in place and we're working with Eclipse to facilitate OO development in SAP. Meanwhile, ABAP is more than 10 years old and has the benefit of being a proven technology.
For those concerned about ABAP's future, I want to make it very clear that ABAP will live on. The majority of current SAP development going on is still done in ABAP, and there are tremendous investments made in ABAP.
So rather than viewing an either/or proposition, think of it as merely opening up for other
technologies. What we see today is something of an equalization process where ABAP and Java are
used in a complementary way. You can use either approach for pretty much anything, and SAP provides
the platform and the tools to make it come together seamlessly. What new development tools are on
We're going into an era of model-driven development. Increasingly, the question is: Are we still going to hand-code everything, or can we automatically generate most of the code? In other words, the focus is going away from directly coding every tedious call by hand and instead focusing on the pieces that are really interesting.
With that in mind, I see two big things in terms of development tools that should be of particular interest. First, there is a new, browser-based tool called Visual Composer. This product allows for building models in a graphical way by drag-and-drop, drawing lines and so forth. You can build from an analytical dashboard with a BW connection, creating complete transactions right there on screen.
I mentioned Eclipse earlier; it's a development environment for Java that is very similar to the
ABAP workbench. On top of that, we have the composite application framework, a modeling tool that
supports building applications in that it generates most of the code while letting you focus on the
last 10% of fine-tuning. Speaking of Eclipse, will ABAP development be possible in Eclipse?
At the moment, I don't see that happening. The ABAP workbench is very strong and there isn't much reason to move it to Eclipse. Bear in mind, the ABAP Workbench has the advantage of having had over a decade to evolve.
The only scenario where I see ABAP in Eclipse is as a result of an increasingly model-driven
development world. ABAP code may be generated out of other tools, but I believe the ABAP Workbench will stay where
it is for the foreseeable future. Remote function calls (RFC)/BAPI support seems to be dwindling.
Is SAP moving away from providing business objects with supporting BAPIs?
SAP will, of course, continue to support existing BAPIs, though we actively try to cut bloated BAPIs to the right size whenever possible and make them ESA compliant. When you're talking about developing new BAPIs and RFCs, the focus today is on making sure they are ESA compliant. Will SAP Java Connector (JCo) become fully compliant with the J2EE Connector Architecture standards?
Normally, SAP tends to offer a richer set of functionality than what is in the standard. But we are aware that JCo isn't J2EE Connector Architecture standard compliant today. SAP is working on JCo to make it more compliant, but I can't make any guarantees as to the extent, nor can I give you a timeline for when -- or if - it will become 100% JCA compliant. What skills should ABAP developers focus on to stay competitive?
Look beyond the home system and focus on the technologies that allow you to talk to other systems and applications. That means mastering SAP Exchange Infrastructure (XI,) getting practical experience with Web Services and staying on top of integration technologies like Web Dynpro.
The applications we'll see in the future are primarily composite applications. Your system will
talk to other systems; your data will come from somewhere else. To stay competitive, you need to
learn how to seamlessly integrate with others. That doesn't mean just being able to tap someone
else's data; it also means opening up your own system to the other party as well. As more companies
outsource development work to low-cost countries, how can U.S.-based SAP developers compete?
The circumstances differ a lot from industry to industry, but overall, I believe there is a lot of added value a U.S.-based developer can offer that an overseas worker can't. Since you can't compete on price, you must emphasize the things you can do that they can't.
One obvious area to focus on is customer contact. A local developer can sit down and go over the specifics of a project face-to-face, see the facilities and the processes involved and do frequent mid-project reviews to make sure the customer is happy with the end result. A developer on the other side of the globe can never have that kind of real-life connection, especially when considering the time difference, cultural differences and so forth.
As for the type of work you do, I'd advise against touching anything that smells of maintenance work. Anything that is routine to you can easily be moved to India or China for a fraction of the cost. Instead, put your effort into getting into innovative projects. When you're creating new things, you're breaking new ground and can't easily be replaced.
Meet members from Herger's team at the SAP NetWeaver Developer Info Days event that is held in conjunction with the ASUG Annual Conference & Vendor Fair in Anaheim, Calif., on May 1-4. This educational developer workshop takes place May 4-5, right after the ASUG event. Contact Martha Schmidhauser at firstname.lastname@example.org for more information about NetWeaver development.