Next Generation IDEs for Business Applications

SAP Developer Network


In a weblog entitled "Instant Business Applications," I elaborated on the need to rethink how and by whom business applications are built. The basic conclusion was that we will tend to see more business applications that are small, quickly built, used for short periods of time, and built by business experts rather than IT folks. Transactional, analytical, collaborative, and other kinds of features will be intrinsic to the application and transparent to the user.

In this article, I will discuss how a next generation integrated development environment (IDE) for building business applications should look.

By Mario Herger

10 Mar 2005


Focus on Business Applications

One thing has to be made clear right from the start: The purpose of the IDE is to help users create business applications. We are not talking about creating connectors, building J2EE Engines, or producing videogames. We want to build business applications.

When I talk about a "focus on business applications," I mean that the thinking should be top-down (as in, "How is my customer-object modeled?") and not bottom-up (as in, "Shall I create a stateless session bean?").

This restriction helps us narrow down the requirements for such an IDE. It should be able to handle the typical requirements that a business application must fulfill:

  • permissions for executing tasks or access to data

  • sessions

  • create, read, update, delete, findBy-methods

  • logging and tracing

  • exception handling

  • language and time dependencies

  • hierarchies

  • performance

  • etc.

These features are commodities; I do not want to deal with them on my own or even have to think about them. The IDE should do that for me. The focus should be on what the modeled objects look like, what the business logic does, how the objects are related to each other, what the user interface looks like, how the process paths work, and so on.

Focus on Developer Types

If we want to allow the creation of (Instant) Business Applications, we need to serve two types of "developers."

On one hand, there's the classical "programmer developer" who wants to get his hands on the coding, modify table structures the "hard" way, debug and pest-control the application. This person wants to have total control over every single piece of the application, to pimp up the application like someone who loves to dig into the entrails of his car -customize it, make it noisier, make it low like a low rider.

On the other hand, there's the "business expert developer" who is frightened by the slightest piece of coding, but who feels quite comfortable with visual tools that allow dragging and dropping of objects, combine, and map them. This person knows the business process very well.

Both sides have to be accounted for by modern IDE architectures. One IDE probably won't be able to serve both sides equally, offering full complexity here and offering simplicity there. The solution might be to have two flavors of the same IDE, or to have two distinct IDEs. But the important thing is that both sides use similar semantics and share the same metadata. This brings us to the next requirement for such an IDE: it is based on metadata and it is model driven.

Focus on Models

Model-driven means that before I create any coding or tables, I first describe them. Not on a piece of paper with a crayon, or in a specification, but with tools directly in the IDE.

For example, I describe that this "Customer" object has the following twenty attributes, that I have a hierarchy of "Products," that the "Product" texts are language-dependent, and that the "Document" object is an attribute to my "Vendor," which I name "Contracts," that a process step "A" is followed by a process step "B," and "process step" A is obligatory and has a duration that shall not be exceeded.

Many of those "descriptions" are just checkboxes ("language-dependent: Yes or No?"), relations ("Drag&Drop") or texts ("Name of Attribute"). And all those descriptions are stored in extensive metadata repositories. The metadata models follow the standards, but I as a developer don't have to care about that.

Now you could say that UML diagrams already take care of that. This is true only to a certain extent: UML diagrams are a good approach, but not very far-reaching and too generic for our purpose. The generation of code-shells with empty methods is not enough for our new understanding. With UML you can design everything. However, this advantage also turns into a disadvantage.

Business applications can be narrowed down into basic functions, basic features that are needed on a repeated basis, and independent from what process the business application covers. A hierarchy is a hierarchy, whether it's a product hierarchy or an organizational hierarchy. Language dependencies (or, localization needs) for master data always has the same structure. Create, Read, Update, Delete, and Search methods are necessary for each object. Those methods typically need permission checks and logging and tracing capabilities included.

So why reinvent the wheel every time? Why not use a generic hierarchy and language dependency function and generate the appropriate data access coding? Not only does it save me time, it also simplifies maintenance.

Those functions and properties of an application can be set quite simple in a model, just by clicking on a checkbox, choosing a selection, or dragging a line between two boxes. The modeling environment validates the settings each time we make a change, so that we do not screw up the whole model. Only then, when I feel comfortable, I press a button to activate/deploy/install/you-name-it the model. With this step the coding is generated, tables are created, and configurations are set.

If I forgot that the "Customer" can have several "Addresses"? No problem; go back to the IDE, change the properties of the appropriate value and install again. Imagine what you had to do in old times - create a new table, change the coding, change the UI, and propagate it to all levels where this change has an impact. Now it's nearly a one-click step, and propagation happens automatically or the affected places are displayed for manual change.

Focus on Platform Independency

Now that we generate the coding, there is no reason why it should be only Java-coding. Or only ABAP-coding. Why not .Net-coding this time? We are familiar with the operation system and database independencies of modern business applications, but why should we still have to talk just Java, or ABAP, or .NET, or anything else?

Given this, the generated coding can also have different flavors, depending on the modeled application. E.g., objects modeled for a retail application might require different performance-tuning than an object modeled for a financial application.

Focus on Integration

When we talk about integration in an IDE, we mean the integration of tools into one place to launch them from there.In the vast majority of IDEs, those tools focus heavily on creating a piece of coding, or - in the best case - to modeling a UML diagram. In addition, they mainly cover the transactional aspect of an application.

When I talk about integration, I see modeling and coding tools heavily interacting in one IDE. Furthermore, those tools integrate transactional and analytical models as well as information from unstructured sources and collaborative features into the project. And all those are coming from different sources.

When I create an object, let's say the "Customer," should I care that I do it for the analytical or the transactional world? The answer, no longer that surprising, is "No." The definition of the "Customer" could already cover the analytical and the transactional structure. No need to define them separately and to stumble later again into the mapping issue, when the data has to be extracted.

Integration also needs to service-enable the application. Any business application must follow the service standards and be able to consume and expose functionality from and to outside applications.

In addition, integration also means human-integration: Developers have to work together with those tools. The development environment must support development teams creating and maintaining business applications.

Focus on the Future

Where do I see the future for SAP? There are basically two approaches available today, which still need some work to reach the vision.

The solution for the business expert developer is SAP NetWeaver Visual Composer. This thin-client, browser-based graphical IDE hides all the coding from the user; you just model and configure your business application. The Visual Composer already includes the BI Kit for Visual Composer, which brings in the analytical world and helps to combine it with the transactional world.

The solution for the programmer developer is the SAP NetWeaver Developer Studio with the Composite Application Framework. This fat-client, partly graphical IDE empowers a programmer to add coding to the generated sources, debug, trace, and "pimp-up" the application.


Any IDE should be evaluated by the following criteria:

  • Is it model-driven? Metadata-based?

  • Is it driven by coding-generation?

  • Is it usable by different types of developers (business expert and programmer)?

  • Is it usable for large development teams and does it support the whole lifecycle of a business application development project?

  • Is it service-oriented?

  • Is it platform-independent with respect to coding, database, and operating system?

  • Does it provide easy access to and allow the creation of objects from analytical, transactional, collaborative, and unstructured information applications under one umbrella?

  • Does it allow the best way of building business applications?

I am sure that I missed some important features and functionality, but the general aspect from a business application point of view - considering the types of users and the kind of information necessary - seems important to me.

Related Content:

Content Options

Copyright © 2005 SAP AG, Inc. All Rights Reserved. SAP, mySAP,, xApps, xApp, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product, service names, trademarks and registered trademarks mentioned are the trademarks of their respective owners.

SAP Developer Network