Franke: Going a little bit further with the CIO example, what business or soft skills are important for developers, and how can they get them?

Jung: Having a basic understanding of your business, being involved, being visible, knowing what you sell and how your company sells it - or provides a service, whatever they're doing - is pretty basic but pretty important. When a business person comes to you with requirements, a differentiating factor is being able to help them with those requirements, not just saying, "Ok, I'm just going to code whatever they tell me." It's knowing enough about the business to be able to say, "Well, I think I know what you're getting at here, but there's actually a better way to do this," and being able to be that bridge to combine the business and the technology, and being able to provide feedback.

I think one of the best ways to do that is to get out and be involved. Make sure that you're going to meetings that are telling you about the state of your business. At a previous employer where we were a typical SAP customer, we would do things where the guys from IT would go work in one of the departments for a day or two, maybe go work in the purchasing department or work in the warehouse and see how the guys work. You're not going to learn everything about doing that job, but it's going to make you better at writing software for that part of the business and helping them with their requirements if you've been out there doing it for a day or two.

Jung: If you look at the current version of NetWeaver CE, there are modeling tools all throughout there: the ones that give the main focus as modeling tools, Visual Composer, Guided Procedures, and there are new tools coming down the road. But there's also the idea of taking the parts of traditional programming that are kind of repetitive and dropping in some modeling capabilities.

If you look at Web Dynpro Java, a context mapping, service consumption, the relationship between navigation between windows - those are all defined in modeling tools, yet you can still drop behind what's generated by those modeling tools and go into coding.

So I think we see two aspects of modeling tools: the first aspect and what a lot of people notice right away is, "Hey, I don't necessarily need to be a programmer, I've got these tools that can take me so far, that can let me build a certain type of application and I can be a business process expert or, even if I'm a programmer, I can quickly prototype something." And that's where a tool like Visual Composer is particularly strong.

Then we see other aspects where we can use modeling tools as productivity enhancements for full-blown developers, and we're building those kinds of capabilities into the core development platform: NetWeaver Development Studio and the ABAP Workbench. So we take the things that would be difficult to describe in code or would be repetitive, and we replace those parts of the programming model with modeling tools but still give you the full power of the underlying programming language.

Reed: Before we wrap up, I'd like to talk about how these trends fit into SAP's eSOA strategy. At TechEd, I had a chance to ask SAP CTO Vishal Sikka, about which programming language SAP was favoring going forward, and he basically said that we need to reframe the question. His point was that with the new eSOA NetWeaver development platform, the idea is to make it irrelevant which programming language we choose to use. Essentially, the eSOA layer is designed to work with any open standard. Do you agree with that?  If so, how should SAP developers round out their skills to ensure that they understand not only the underlying language of choice, but the eSOA layer?

Jung: I do agree with that, but there's a point I'll get to in a second on that as well. But first of all, that is important; that came back earlier in our discussion about languages and about tooling. Obviously, if we follow an eSOA paradigm, if we truly open and enable everything that we build, and we build in these smaller units of work that can be tested individually, that opens things up and SAP delivers something - business logic, maybe it's written in ABAP, but like we said earlier, it doesn't matter any more. I can consume that in .NET, I can consume that in Java, I consume that in another ABAP environment, so it does open things up.

At the same time, although it doesn't matter what programming language we choose, I would say that SAP provides the best tools in the marketplace for building Enterprise Services. And when it comes to security and scalability, it can matter who you get your tools from to build Enterprise Services: Although we're all based on open standards, not everybody's performance and security running within that is the same.

So I would put a plug in there that we feel that we still provide the best tools, but at the same time, they're inter-operable and how you consume what's been built as an enterprise service is an open option as well. But I would put out there again: SAP feels that we are building some of the best consumption tools as well.

But certainly to the question of ABAP or Java, it becomes a bit of a moot point and I recommend to people that they use the one that they are most comfortable with. That means where they already have skill set investment, where they already have transport and versioning mechanisms set up, and where they see their company being the most efficient because, at the end of the day, it's about providing value to the business. The business end-user doesn't care whether you used ABAP or Java to implement your service, and even when it comes to user interfaces, much of the user interface technology looks the same to the end-user, so whether using ABAP or Java, they care about how quickly you delivered it to them, at what cost and how flexible it is moving to the future. Those are the real questions that IT departments should be concerned with.

Reed: Excellent. Well, we've covered a lot of ground today. Jon Franke, do you have any questions you'd like to pose to Thomas that we didn't cover?

Franke: We talked a lot about developers, Thomas, and how they can use SDN. How about people more on the business side, what's there for them?

Jung: Well, there's a whole BPX section, and they're trying to gather their own set of forums and blog posts that are more centric to BPX, that talk about things from a more business aspect and that are broken down into industry verticals. There, people can talk not just about the, areas that have been popular on SDN for a while - you know, a lot of us talk about the nuts and bolts of programming. But there are areas where people can come together and meet that are more interested in how a particular business vertical works.

Reed: And Thomas, for those that want to catch the ABAP Development Updating Your Skills to NetWeaver 7.0, it is available as part of a TechEd package on SDN. Are you planning on offering it at an upcoming conference as well?

Jung: Yes, actually. If there's anyone listening in Australia, at the Mastering SAP Technologies conference this June, we give it as a workshop on the last day of the conference. And then I'm sure as this year's TechEd rolls around, we'll probably be giving an updated version of it for this year's TechEd. I can't say for certain since we haven't started doing the planning, but I imagine it will be back in some way, shape or form.

And, actually, if you're in the Chicago area, we'll be giving it in the upcoming ASUG Chapter meeting. (I don't have the exact date off the top of my head - it's in March, I know - but you can always check the ASUG event calendar and see when the Chicago chapter meeting is.) We're going to give it as a hands-on workshop during that chapter meeting. As other events pop up, I think we'll see, because it was pretty popular, other places where we can plug it in.

Reed: Great. Thomas, do you have any final comments or words of wisdom for SAP developers?

Jung: I think we covered quite a bit here today. The main point that I want people to walk away with is that, regardless of what your skill set is, don't panic. You hear us talk a lot about new technologies, new tools - a lot of these are an expansion of the market, new capabilities. It doesn't mean that the capability you have today is going away necessarily, and the advice that I usually give other developers is to sort of follow your passion. If you've got a particular technology that you're good in, that you enjoy doing, be the best at it that you can be and that's also an excellent way to outsource-proof yourself.

If you really enjoy what you're doing - the programming language, the type of programming that you're doing - you're almost instantly going to be better at it if you find true enjoyment in it, so that's a key factor.

Reed: Excellent. Well, I think those are words to live by, inside and outside of SAP. Thomas, best of luck on your work with SAP Labs and we'll look for you on the SAP Developer Network for more discussions on the evolution of SAP development.

Jung: All right. Thank you for having me.

Reed: Great. On that note, I'd like to thank our listeners for tuning in today for this podcast interview on the future of SAP development. This podcast was a joint venture between SearchSAP.com and my site, JonERP.com, bringing you career answers for SAP professionals. And with that, I'd like to turn it back to our host, Jon Franke of SearchSAP.com.

Franke: Well, thanks for joining us, everyone, and that about does it for this edition of SearchSAP.com's podcast series with Jon Reed and Thomas Jung. Until next time, I'm Jon Franke. Thanks for joining us.

Editor's Note: This interview is not a verbatim conversation from the podcast. It was edited for clarity and readability; however, no content from the original conversation was removed.

Download Now (Must Be Registered and Logged In!)