Skip to Content
Author's profile photo Tom Van Doorslaer

The curse of the Development Framework

I’m currently working on a really cool and challenging project, in which we’re using quite some API’s and frameworks that are new to me. I already know WebDynpro for ABAP. I also know FloorPlan Manager pretty well. GUIBB’s are no rocket science to me either.

But there’s one thing that annoys me with every new framework I learn.

Every development framework limits the possibilities for the developer.

You see, WebDynpro for ABAP is a really good framework, which allows ABAP developers to focus on the functionality code, and model the frontend via click ‘n point.

Terrific, you can create really nice web-applications, without any knowledge of HTML. Great!

Except if you do know HTML really well and want to do some funky stuff. No-go in WDA.

I know, there’s the HTML5 islands, but those weren’t around when I first started WDA.

In any case, I don’t want to rant about WebDynpro. I do very much still love the entire framework. It forces a developer to split out business logic from the view, and to work according to the MVC principle. I like it.  It’s perfect for what it was intended to do: uniformize SAP based Web applications both in look and feel, and software architecture.

Once you know the framework, you can do really cool stuff with it.

Once you get to know it. That’s the catch.

I’ve trained plenty of people in WebDynpro, and the typical classical ABAP developer can have quite some difficulty in learning it.

And there’s plenty of frameworks to learn..


Our current architecture looks like a stack of Jenga blocks and contains lots and lots of frameworks. Somewhere in there, you see webdynpro, which itself limits the developer, but you get a lot back for those limitations:

  • HTML frontend, without writing a singe tag or Javascript line.
  • Session persistency
  • Data binding
  • uniformity across applications
  • security


So with WebDynpro, there’s a positive trade-off. You lose quite some flexibility, but you gain a lot out of the box.

Floorplan manager, in it’s purest form doesn’t limit you too much either. You can just compose a complete floorplan with freestyle applications.

But then there’s the GUIBB’s. There are only a dozen of UIBB types, which mean they further limit the developer possibilities.

And then there’s the FBI, generic feeder, which only comes in two flavors: A form, or a list.



Just the idea of a generic feeder class already puzzled me. A feeder class was to intended to let the developer create the field-list definition, actions and data retrieval. A generic feeder class means that you pushdown the ABAP code even further down into some other framework, and try to strip out again, as much code as possible and replace it with configuration.

Sound like that old tagline again: “No developers required!”

Fact is, that every framework indeed further reduces the possibilities of a developer, up to the point that the developer can only do some really basic stuff and is practically obsolete. But then the complaints start coming in. The product is too limited. We want different behaviour…

So you ask the developer to implement these changes. Except that, the framework doesn’t support it. So the developer has to work around the framework, which usually doesn’t result in a nice solution, and is probably quite error-prone…

Final thought

And that’s the curse of the framework: too little, and your developers go awol, too much and it renders itself obsolete. The more experienced your developer, the less he needs a framework, but the more he choses certain prefered productivity frameworks.

I like the WebDynpro framework, it manages to keep the balance, but can we stop adding more and more layers to it?

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Bikas Tarway
      Bikas Tarway

      Very nice thoughts, I think BSP was there which was offering much flexibility to the developers but for uniformity and ease of development I think these frameworks are best.

      Moreover for maintenance if one do not have highly skilled developers like you  🙂



      Author's profile photo John Patterson
      John Patterson

      Interesting topic

      I like the FPM and POWL feeder classes implementations because they can produce very quick wins, great for projects where you need to pump out a lot of consistent looking applications with little effort, high re-usability of code, easy to maintain .

      The trouble I find with the all or nothing style frameworks like FPM is the illusion of simplicity, easy to learn, hard to master, they will often produce 80-20 scenarios, 80% of the functionality can be quickly created in 20% of the time, because of the inversion of control, you burn a lot of time trying to solve problems that may be trivial when not using a framework at all.

      I completely agree with your statement

      The more experienced your developer, the less he needs a framework, but the more he choses certain prefered productivity frameworks.

      and ill add to it

      the more experienced developer will know which tools work best for what job

      Lately i have seen a tendency in SAP standard code for frameworks like FPM and BOPF to be combined and used at will like a man with a hammer. As you pointed out every additional framework limits the possibilities for developers, also means for customers who have implemented functionality built with these combined frameworks, that they will need to retain a specialized skill set for maintaining the needed extensions to the code CRM/SRM/EHS etc


      Author's profile photo Tom Van Doorslaer
      Tom Van Doorslaer
      Blog Post Author


      And whereas WebDynpro is more widespread and still rather transparent. (simply in SE80)

      FPM knowledge is already less available.

      BOPF even less

      and the combination of BOPF, with FPM (FBI) is even less known and far less transparent.

      So at which point did the framework become a burden?

      Still, when used by the right people, in the right context, it can be a very powerful tool.

      But by dividing the logic from the layout to such an extent that people on both ends no longer know what is going on in the other end: well, is that a wise thing to do?

      So those right people, are the ones who know both ends, and those aren't plenty...

      Author's profile photo Amy King
      Amy King

      Hi Tom,

      I was considering this same issue just last week after attending some FPM training. FPM GUIBBs appear to severely restrict the product, and I can easily imagine a scenario in which a developer builds a FPM application only to have the business owners decide they want to add features FPM doesn't support. The developer would be left with two poor options-- either shoehorn the new features into FPM and end up with a product that doesn't feel polished or rebuild the product without FPM and deliver the revised product late.

      SAP does seem to be seeking a balance between flexibility and framework. ITS and BSP were arguably too flexible and often resulted in what I like to call "User Interface Salad". Web Dynpro feels closer to the right balance but then SAP went a step further and introduced FPM which trades too much flexibility for framework.

      SAP appears to be still in search of the Goldilocks Effect-- that balance that is "just right".



      Author's profile photo Tom Van Doorslaer
      Tom Van Doorslaer
      Blog Post Author

      the one feature of FPM, which I really like, is the Page builder.

      Perfect for building dashboards, and having data fetched asynchronously.

      Everything else seems to be added weight...

      Author's profile photo Chris Paine
      Chris Paine

      Amy, There's a clear answer, it's called UI5 🙂

      However, I'd disagree with your comment that creating new UIBBs makes for a product that looks less polished. It's pretty easy to create a freestyle UIBB and I think just as easy (if not easier) within the FPM as external to it.

      However, yes it takes a reasonable amount to learn how to leverage all that framework. I've rarely seen anyone (other than myself) building custom code that uses wires for example.

      I agree with John - " easy to learn, hard to master"



      Author's profile photo Kenneth Moore
      Kenneth Moore

      I've been doing WD4A for a little while now.  But not so versed in FPM.  I think there are advantages in coming late for the dance in that FPM is now a mature product.  Looks promising, what little bit I know about and have used it.  The downside of coming late, something new has already come out and SAP loses interest in continuing to innovate the "older" technology.  Happens way too often with SAP.  Luckily, ABAP has been a constant in the constantly changing landscape!  (could you imagine saying that statement when you were first introduced to ABAP!  I hated it at first!)

      But don't get me started on BOPF.  I've just been introduced to that via a class and it is just bizarre to me.  It takes longer to code for the framework than the actual task you are trying to achieve!  The disadvantages out weight all the advantages.

      Author's profile photo David Fernandez Castro
      David Fernandez Castro

      I have to say that I share most of your thoughts...

      It seems all those frameworks are aimed at avoiding programming at the expense of a reduced flexibility. It is clear that every step towards abstraction adds constraints to the underlying technology layer, reducing its power.

      After all, I think that almost every project includes "special" situations that are not handled well with all this abstraction and requires get down to business and step back some levels of abstraction to resolve them. After all, things like Freestyle UIBBs are handy for that.

      When programming BSP applications with BSP extensions, Javascript libraries, JSON and so on, technologies like Web Dynpro are like a child's play; for better or for worse? It depends maybe...

      Author's profile photo Fred Verheul
      Fred Verheul

      I agree that it's hard to get the balance right when designing a framework, and IMO SAP tends to overdo it in general.

      On the other hand, we should not blame the framework, just because SAP hasn't done a stellar job explaining it, like with FPM and BOPF, with the result that it's not well known, therefore hardly used, etc. I'm sure that with better examples, tutorials and real best practices on how to use it (going beyond the basics), we wouldn't have a lot of the problems we're having.

      Author's profile photo Tom Van Doorslaer
      Tom Van Doorslaer
      Blog Post Author

      Maybe the problem isn't in "how to use it?", but rather "in which situation do I use this framework?"

      Most frameworks are built with a specific purpose in mind (like most products and applications).

      It's foolish to pull such a framework out of it's context, and try to make it fit with a completely different purpose.

      that's like, building a database in excel.

      doing reporting in a planning tool

      using the business client on an iPad

      or digging a hole with your car-keys...

      Author's profile photo Matthias Steiner
      Matthias Steiner

      Nice one Tom...

      (Wrote about this a while back myself:

      Author's profile photo Tom Van Doorslaer
      Tom Van Doorslaer
      Blog Post Author

      Yup, I remember your article, and the discussion which it sparked.

      Development frameworks that obsolete the developer, are a decade-old fairy tale and non-developers still don't understand where the complexity of development really lies.

      It's not about writing code. It's about inventing algorithms.

      That's something a framework can't do. Worse, the framework only limits your creativity in inventing such algorithms.

      At best, the framework takes a lot of trivial work out of your hands (logging, front-end design, architecture,...)

      And then they overdo it...

      As long as the big software vendors, and the project-architects fail to get the balance between freedom and framework right, we need to keep reminding them