Skip to Content

Usability in ABAP Programs

I’ll start this post guiding you through a “classic” situation from a ABAPer’s daily life:


  • You start in a project and receive some Functional Specifications, that you must turn into good ABAP developments;
  • After you’ve finished, you explain your applications to Functional Team. They test them and says that everything seems fine (that’s not REALLY what happens, but let’s skip the unit test validation phase)
  • Then Functional Team will explain your apps to the user, that also tests and says that everything seems fine.
  • 2 days after your Project’s Go Live, your team receives lots of errors stating that “the output values are wrong” and that “values entered on the selection screen are not being correctly used as filters”.
  • Everybody realizes that most errors were raised because end-users didn’t really understand how the program works, and your project’s team gets happy because all errors are now “fixed” and system is up and running, ready to aid users in their daily activites.



Have you ever got into situations like this, with similar “errors”? I’m sure that most of you have faced this scenario in most (maybe all?) projects you have worked. We can surely say that the system is up and running, but… is it really ready to aid users in their daily activities? Why the user stated that everything was wrong while the programs were right(from business requirements perspective)?


Well, would you buy something in an webstore that is not easy-to-use? In a webstore where you don’t feel that personal data you entered is being correclty and securely used by website’s application? And what if you HAD to buy things in that webstore because it’s the only webstore that has the product you’re looking for? And what if you had to buy in it every day? Maybe that’s how that end-user is felling about using the recent delivered ABAP apps in his company. I bet that, is his place, you would also say that lots of things are wrong because they look wrong.


I’ve seen many ABAPers blamming users for wasting their time with simple questions. These ABAPers thinks that, as they explained how the program works and made a consistent documentation, the user automatically become an expert in that app, even if things are not complety clear at program’s outputs.


It’s not only about getting and showing the correct information. It is about HOW you present them to the end-user. They are the reason why we’re here, and they must get something that is easy-to-use. One of the HUGE mistakesthat many projects out there are making is to ignore the end-user thoughts.


It’s very common to see a Module-Pool Functional Specification with 5 screens that were designed without the end-user… How can you design something for a user if you don’t know what they need? And I’m not talking about “business needs”, I’m talking about usability.


Sometimes it seems that some companies are building softwares from backwards, thinking first about program structure and data retrieving, instead of thinking about the end-user. What he trully needs? How he will use the application? Which kind of design will aid him at gainning speed in his daily activites? How software design can prevent his errors? These are questions that are, unfortunately, almost never made. 


And I know that ABAP programs have some limitations due to the elements that we can add to the program interface, but I believe that developers can create cool designs if they keep open-minded and work together with the users.


Now it’s your time: Have you ever faced situations like that? Do you also feel that thinking about the User Experience can help delivering succesfull Projects?


This is my first post about usability in ABAP, and I’m planning to create posts showing some badly designed ABAP programs and how I believe they could be improved. I’d like to ask you to join me in this analysis, giving suggestions and making comments. You can start developing “usability-driven” by looking at this link, which has a lot of interesting thoughts about usability in ABAP programs, from the “SAP Design Guild” (It’s really worth the click). I didn’t worked on that topics, but it has tons of good information.

Thanks and See you soon!

Ps.: I’ll be also posting this in Brazilian ABAP Blog “ABAP Zombie”, translated to Brazlian Portuguese. Se você for brasileiro e quiser comentar em português, sinta-se à vontade!

You must be Logged on to comment or reply to a post.
  • One aspect of usability that I think is important for users, that might not be often considered is: how easily/simply/quickly/cheaply can enhancements that really add value, be made. Of course the answer to that is - it depends on how well written the program was in the first place. I've often found though, that those programs written by developers who consciously craft their developments - the usual things, modularisation, good commenting, encapsulation etc. - are the ones who's programs satisfy the users early on. Perhaps this is because careful developers are also those who are good at understanding, from a business perspective, the end-user needs.


    • Agreed.  I think that knowledge from a business side only helps development.  We know the right questions to ask.  Being careful is a great talent.  One that I am always learning.


      • I also agree with you Math and Michelle, that careful developers turns out to create the apps that really satisfy user needs.

        But I think those kind of developers are ones that really do care about their developments, and are not seeing their created as a simple "job that will pay the rent". You must like your job and creation to be able to take development to this point.

        Thank you very much for you commentary!

        • LOVE my job.  I tried on many different hats, consultant, project manager, functional lead, but I went back to technical - my first love.

          I find that I really care if my design is good.  (Functional or technical.)  I love working with the functional person.  We couldn't design the best solutions without them.  However I love working with the end user too.  That's a big part of my job satisfaction.

          Love the topic...  Love to comment...  The debate is good.  But this is a stubborn topic for me.  I've been in a position where all they wanted was for me to code exactly what was in the specifications with no creativity.  As you can guess that didn't work out very well.  It's the fastest I've ever program.  It's the worst job that I've ever did.  (It's happened more than once.)


          • This is what most ABAP developers I've seen has been doing for years: "code exactly what was in the specification".  And they also use the specifications as a kind of "shelter", so they can blame the Functional Team when something goes wrong.
          • That's what I tried to say all the time!!! although you can see that actitude in both sides, I hate when the things goes like this, but not always is in your side to decide, a project/team can be very very political, especially if there are things to hide :-), My thoughts goes to that kind of situation, when the best you cand do is know where your responsabilites begin and where it ends, because if you don't, you'll be always the one to be blame...sad, but most of the projects I worked went like this...
          • They shouldn't have.   That's too bad.  Actually, I think it is both the functional person and the developer's fault equally.  Unless of course, you have a developer that doesn't get to meet with the user.  Then the blame goes solely to the functional person.  I feel it's a team effort.  Therefore the team is to blame.  Functional, developer, and business user.
          • now we're talking! 🙂 sadly in the most projects I have been involved hadn't a feeling like a global team, were structured some like areas:

            - Key users
            - Functionals(in the customer side)
            - Fucntionals(in the consultancy side)
            - Technicals(in the consultancy side, same than the functionals or worse in other company)

            No one wants to show his weakness, so, let's spin the bottle! and pray that does not threaten my ***.

            I know is bad, evil, etc. but if you have ecosystem like this, you only can adapt or die, at least is what said someone called Darwin.
            Of course if you have some hierarchical power, you can try to change things, and of course, worth a try, but, there are fears to get in the blacklist, fears to increase the project budget, fears to what the customer said, etc. If you are a "low level soldier", forget about it! lucky you if someone wants to hear your opinion...

            At the end you have to do the best you can with what you have, and if we have project splitted by resposabilities, as I said before, know where your responsability begins and where ends.

            I am approaching the dangerous offtopic area, so I hope I have clarified my position.

          • Wow!  Interesting thoughts.  Have you thought about writing a blog?  Spin the bottle.  That's a hard one.  Having a boss on your team - well hopefully they are a good boss, and know where the weaknesses are and try to fill the void.

            "Low level soldier" - well OK come work with me!  Sometimes the low level soldier has the best ideas.  The new programmer thinks of something different.  The lowest business person will have to use what you've built.  Do they care about it?  Oh yeah.   They also know their jobs.  And can tell you or give you suggestions on what you build.

            Know where you responsibility begins and ends.  Interesting thought.  Again another blog?

            My answer is it is a team project and everyone is responsible.  Right?  Wrong.  In the real world if a project is not on time, does not work, or has other issues.  Well there is always someone wanting to know "WHO" to blame.

            That's where I have troubles.  I usually function in that grey area.  Where I could be blamed easily.  Do I care?  Of course.  Would it make my answer different?  Of course not.  My job would be a lot less fun if I had to do only technical, only functional, only project management...  I like to have a bit of a mix.  Strange but true.  I like the "upper management" to approve.  The "lower level" people who will use the project to be a part of the team.  The functional person who knows configuration, business processes to be included, and finally the business process expert.  You know the guy who stretches into the entire process, SAP and other technology - the business and all areas the business touches.

            Now who is to blame?  I don't meet my deadlines.  I didn't have the requirements in time.  So who's to blame?  I'm saying I help write the requirements.  And most of the times I do.  But the business did not have the hours to give to us.  Who is to blame?  Us for needing too many hours or the business for not be dedicated.  You know the business whose normal job is to make product.

            Interesting.  I'd have to think about it a lot.  I'd love to see you write a blog about it.

  • I think that work should be done by the functional consultant, he is the closest to the end user and who must know about the daily works, of course, the developer shall have initiative about the design, and propose cool stuff,  but must be the functional who check the application graphical behavior if is suited to the end user needs.
    I agree with you that the developer should read the "SAP Design Guild" at least he must pay special attention to the SAP standard applications and try to inherit the standard graphical behavior I think is the best way to the user get used at any app without fall to desperation 🙂
    • AHHHHHHHHHHHHHHHHHHHHHH!!!!  I'm jumping up and down!  You've hit one of my rants.  The developer should do more than just blindly develop from specifications.  They should know the system well enough to help with the specifications, meet with the users, and the functional team.   When you, the developer, have time, do a prototype for them.  The key here is that you - the developer should be working with both the functional, bussiness users, and process designers.  In my perfect world - well it is Innojam, no users, no pressure, just fun.  But besides that is that the developer works side by side with all of the people to create a good product.

      I'll add more into other comments.   BUT I don't agree that the functional consultant should know it all and not listen to the developer.  We should never feel like we are a step down from the functional guy.  Or that we don't know something about the system that will help with the end product....  Everyone should be responsible for the outcome the developer, the functional person, the business user, the business process owner, we all need to know what we are working on and why!!!!

      BUT I STRONGLY FEEL A GOOD DEVELOPER DOESN'T JUST DEVELOP. How, what, where, when why?  All good questions.


      • Calm down... I agree in the most of the parts, but I don't think the developer must take responsability for a poor or incomplete graphical design when the app is done, is a functional job to test and detect those before the user puts the hands on it, you know, more salary more responsabilities 🙂 ...anyway that's why a functional is called functional...

        As I said: "the developer shall have initiative about the design, and propose cool stuff, but must be the functional who check the application graphical behavior if is suited to the end user needs" of course I assumed when is someone proposing is someone listeing...this is not the army...

        BUT I STRONGLY FEEL A GOOD DEVELOPER DOESN'T JUST DEVELOP. <- Not everyone has the same capabilities, so who can develop, design, speak with the user, test, etc. without mistakes and have enought time to breathe, GOOD! But if you are a developer, at least, be the best you can, and if is only developing, that's ok, better be a master of one thing than apprentice of everything...

        • Calm down???!!!  Nope.  I doubt I ever will on this one.  You hit on a big part of when I don't like my job.  I don't like my job when someone hands me detailed specifications right down to what function module to use.  Really?  I get pretty bored doing that.  I can do it quickly.  I can guarantee it won't work when the end user runs it.  I will get the requirements back and forth hopefully prior to going to Production.

          The same person who things the developer doesn't need to be involved may think only the approval user needs to be involved those usually are not the people who have to "live" with what is developed.

          More salary?  How do you know that?  I sure don't.  Responsible for the design?  We all should as a team be responsible for the work we put out.  More responsible - ok - they have a responsibility as a functional person to pick the correct solution.  When that solution involves programming.  I believe the specifications now become the responsibility of both the technical and functional person.  Do you really think the functional person is going down alone?  We are a team.

          Develop only develop.  Does that mean I don't develop well.  Boy I hope not.  Again, team comes into play here.  Yes, I do know some functionality as well as development.  Again I feel that makes the best developer.  The one who can look at the design proposed by the functional person, and say - hey, there is an easier way to do this.  If I develop in XYZ it will be easier.   The end user knows what they would like the best - web dynpro, classic dynpro, ALV....  If we work with the end user and the functional person, we can develop something so much better than developing without a thought to what the end user is thinking.

          Ah well - I believe on this one we are going to agree to disagree.  I do feel strongly.  I also feel like it should be written in stone, in bold, in..  I've programmed in areas I'm not strong in, it makes for a bumpy ride.  Can I do it? Sure.  I sure hope I'm not an apprentice programmer.  I know the basics of how the system works.  What ties what together, how config works what we can do to make our programs more configurable so we don't make a lot of changes to a program already written.

          OK - enough this morning....  Maybe I'll write a ranting blog again.  🙂  I now am armed with more information.   Including books like "Change by Design" by Tim Brown.


          • Well if you don't want to calm down that's your problem... but before get mad, and start jumping try to understand what I said, and don't tell me that you did, because for your answers you demostrate that you didn't. Again and again, I DIDN'T SAY A DEVELOP DOESN'T NEED TO BE INVOLVED, FOR GOD'S SAKE! I'M A DEVELOPER!!!

            - More salary? How do you know that? <-beliveme I know, at least here in Spain..doesn't matter how technicall skilled you are, your rate always will be inferior compared to a functional consultant...I don't like it but the market works like this.

            Scrumm, Inmojams, world without war, flowers and butterflies, Man! I really envy your projects, when you all can work together because you have enought budget, enought people, enought knowlege, enought time, ei! we all in the same boat, your mistake is my mistake! are we still talking about consulting companies? 🙂

      • Count me in for this comment.
        Oh!! I am so badly happy...Michelle, you think like many other developers out here....YEAH!!!

        In fact I have been thinking for quite a while that the same developer who would develop an object should be involved right from the design phase of object....


      • When I entered the IT industry some ...mumble.. years ago, there was no split between "functional" and "technical". We had "Analyst Programmers" or "Systems Analysts"... who could program and talk to the end users.

        The whole functional/technical split arose for a number of reasons. The prime reason, in my experience, is that the big consultancies didn't like doing technical stuff, because a) it's too hard to measure quality b) it's hard to find people who can do it c) highly paid partners who can talk-the-talk couldn't do it...  Much better to find business people who can talk techy a bit, and have them take over the "talking to the customer" bit, and always saying yes.

        Now it comes full circle and we hear clients crying out for "techno/functionals".

        Now I've slandered my dear friends and colleagues on the functional side, I'll duck for cover. 🙂

        • Good points!  Me too - my title used to be Programmer Analyst.  It just got changed to engineer designer or something like that.  Same job different title.  Anyway prior to SAP, we did it all without a functional person in the middle.

          I however, agree the functional person has to be included for a good design.  I can't know it all.  As much as I would wish I could.  The functional person knows the things that can be done in config.  (Don't get me wrong.  I know something about that too.  I was a functional person for awhile.  I hated all the meetings.) 

          We have to be involved in the beginning to get a solid design.  Yes, as with any project we will split out to our own tasks.  But working hand in hand with the user, functional person, project manager, consultants...  We'll get a great design instead of a good design. (Or even worse design that doesn't work.)

          Thanks for the comment - I kind of agree with it.

          We have to be able to talk with the customer.  It's just one of the skills we look for when hiring a programmer.


      • This is why methodologies like Agile and Scrum were invented... and these are not reserved for the Java or non-ABAP worlds. With the advent of rapid modelling tools like Web Dynpro, it's easier than ever to present users with an initial prototype, while focusing on iterative releases where you add or change your application, in cooperation with functional users.

        I believe Scrum and Agile can be used for classical ABAP developments, as well. If you're not familiar with these techniques, read up on them, then spend the next few days convincing your managers about their advantages. I guess the days of ranting will soon be numbered!


        • These can be great, but there are problems in applying them in a validated environment. The FDA, in their definitition of validated, say: (the process) will consistently produce a product meeting its *predetermined* *specifications* and quality attributes.

          There are innovative ways of applying Agile and other techniques in validated environment - that will be /should be fine - but it's getting the people in charge of quality - the ones who have to deal with the regulatary authorities to agree, that can be problematic.

          • This is all about mindset... more of a paradigm shift, really. In our ever-changing world, the whole concept of "Predetermined specifications" is not as valid as it once was (?). Change is the game.

            Maybe it's time to challenge these old concepts. Or, maybe, by not challenging them, we continue shooting ourselves in the foot. Or, more to the point, we allow the QA guys (the executive arm of the authorities) to continue shooting themselves...

            Having worked in agile environments for the past year (yes, in a highly regulated environment, for a large corporation), I can confirm the possibility of implementing these ways of working, to the benefit and agreement of the whole organization. BUT, it takes the whole organization's involvement in order to make it work. Also the QA people. In my opinion, this is the challenge we should face.

            And, of course, the net outcome is a lot more fun and inspiring than continuing to face the old techie-functional-business-guy tug-of-war...

            I'm not saying it will work everywhere, just that I'm Xtremely happy to be outside the old loop.

  • I agree with Luis. This work should definitely be done by the functional consultant. If we ask to end-user they always expect "Do" button and when they click, it should read their mind and do everything they want. Consequently, whenever ABAP developer (especially for juniors) starts to work with end-user directly, the things goes worse. I remember when I was "junior" I was saying "We can do everything you want" to the customers. Later I started to say "It is not proper to do in that way" and finally I started to say "No, we can't do in that way". I can discuss this with functional consultant and negotiate with them. But when it comes to end-users, they always expect what they are used to do. They should be convinced to change some habits without affecting their business processes. Most of the time, business processes should also be changed.
    And these work cannot be done by ABAP developer. This is the functional consultant's job. They know the both side and they can find the best solution that don't harm the system and meet the requirements. Of course with the help of the ABAP developer.
    • OK - ANOTHER RANT!!!!

      I hope my developer friends jump in soon.  I know the technology.  I know what can be done.  I have a skill set and knowledge that the functional guy does not.  He may ask for a custom table that isn't needed.   He/She may ask for a new program when an enhancement will work.  Prototype is the best way to go.  Have you ever played the game telephone?  You tell someone something they tell the next person it, and they change it slightly, by the time it gets back to you the message is wrong.

      Really?  You really think JUST the functional should be involved the design.  Not me!  Never me!  I want, need, and am usually involved in the design.  I don't usually work on the blueprint phase, but if the business user needs some ideas, I mock them up in a prototype.

      My job would be boring, incorrect, and not respected if I just followed everything the "functionals" told me to do.  Do they know about text elements, objects, number ranges, change objects, ALV, WebDynpro...  The lists goes on and on.  Each person should work and respect the other's talents and knowledge.

      I believe a project goes wrong when the developers blindly do what a functional asks.  Or the developer is the ONLY one talking to the business group without a functional.  We work together hand and hand.  Not ball and chain with one or the other leading and dragging us around...

      I'm still fuming!   A hot spot with me!


      • Hey, I didn't say the developer should only code like a machine. Of course he/she should work in cooperation with the functional consultant. However, "direct contact" with the end-user is dangerous.
        There always should be a functional consultant with him/her. After discussing the requirements, functional consultant and developer can discuss/negotiate the pros and cons of the alternatives and find the best solution.
        Calm down Michelle, this is also my sensitive point. I was arguing the same things with my project manager yesterday.


        • I think I understand why Michelle is being kinda harsh when talking about this point.

          This is because probablye she worked with funtional people and managers that saw ABAP developers as pure "coding machines". I really hate that kind of view, but sadly IT IS very commom... At least here in Brazil 🙂

          I understand that direct contat with the user is dangerous, but what if you had a experiencied ABAP developer on the first project's meetings, where you check the requirements and start to design the whole business process?

          I do thing that program's design is DEVELOPER'S resposability. The functional team have to tell us what the business process is and WHAT information the end-user is expecting to get, but it's we ABAP developers that must decide HOW the program will do so.

          Thanks for your comments!
          Mauricio Roberto Cruz

        • No direct contact with the user?  Really?  I believe we are a team.  As a part of that team the functional, user, and yes developer work together to come up with a great solution.

          Less harsh, but still to the point.  We are not coding zombies nor should our only contact be with the functional person.  Direct contact with the user is a must!  That's the only way the design will work for everyone involved. 

          My 100 dollars this morning.  (Lost the 10 cents somewhere in the discussion.)


          A different point Trond made (Agile & Scrum) Love them both.

          • Of course we are not coding zombies. I too believe that we are a team. I'm not saying developer should never work with end-user. They must work together. However, functional consultant shouldn't leave them alone. That's what I meant with direct contact.


          • OK - I got a good laugh this morning.  We will just have to agree to disagree.  The technical person meeting with the business user without the functional person?  Of course I think it can and should be done.  The functional person has decided custom program needs to be done / with the help of the entire team.  So the functional person can have a black box where the code doesn't matter just the results.  OK, now I know some functional consultants need to be involved in design, just like I feel the need to be in with design.

            Meeting notes, descussions, decision even Steamworks can be a good form of communications.  But I wouldn't expect to sit in all of your meetings - what a waste of my time.  You shouldn't expect to sit in all my meetings - again what a waste of time.  At a later date we might have a person to person talk.  About why I decided what I did, and maybe some different ideas bounced back an fourth.

            So yes, I think I can meet with the business users without a functional person needing to be there.  There is so much work here, it would be impossible.

            Now your next blog - perhaps we can corridinate something were I write one side and you write the other, and then release the blogs at the same time.  Tom and I did that - although we agreed with each other.  It was very effective.

            I could easily give examples of some bad designs when the developer doesn't talk with the business person.  I'll pull from my consulting days.  So I won't get in trouble with my current job.  And of course, names will be deleted.



          • Stop the press - you are not the original author of this post.  Maybe all three of us should get together virtually and decide when to release some ranting blogs.

            Of course it would be you two against my one.  But that's OK.


          • Ok I'm stopping 🙂 I've already started to write a blog post about my comments about this topic. A virtual discussion will be great if we can arrange. I'll also be at Innojam and Teched Vegas and we will have more time to discuss there.


      • I'm with you on this one Michelle. The divide is largely artificial and unnecessary. Historically - within my career - it wasn't done like this. The only reason it carries on is because this is how it was done last year...
  • A junior developer will blindly follow a functional person’s lead.

    A good programmer will work with the functional person on a good solid design.  (Good careful programming practices. - Matt says it well.)

    A great programmer will work with the team.  Functional, business, and process design person at the start.  They will offer up technologies that may not have been thought about.  They can quickly "Mock" up screens so the user will see a visual prior to the actual product.

    All of the programmers and functionals should be involving the business as best as they can.  Each program that is completed should have a user acceptance test.   And of course, white boards, brain storming, etc.  We will be working with this at Innojam at Teched in Vegas. It will be a cross section of people coming up with a great design.  If you can please come and do it.    It's amazing what you can get done as a team instead of each part segregated.  It would also change the tone of this blog - I bet.

    Now I think the developer should know something about the area they are programming in.  It helps them when they ask why.  By the way what about the Jr. Functional  person.  The developer has to cover off for them.

    My "RANT" - and boy could I rant some more!


      • Hey,

        I so badly wish to 'LIKE' your statement but there is no option 🙂
        However there can be more permutation and combination.How about a Sr. funct. assumes that the functionality would remain same as he has been working in past and there can be no change in the new requirement.
        Believe me, the tech. guy would see stars to convice these guys....I have already experienced the same.


        • I don't think there's no option.

          In fact, I think that believing that "there's no option" is the main reason why everybody is working as a separated area, instead of working together.

          • I still agree the developer needs to work hand and hand with the functional person.  The Jr. and Jr. combination could work.  As long as they have some Sr. person looking at their solutions.

            By the way sometimes the Jr. can come in with a solution that was never thought about!  It can lead to some really innovated development. (It happened here.  I had to go ask the "Jr." program how he made the program.  That way I could do the same thing in the future.)



          • hahahahahahahahahah I'm extremely sorry! I answered your comments after answering the others, think I got too much into the discussion =D

            Thank you!

    • Michelle, you really got my point in this blog 🙂

      I'd love to have the opportunitty to "mock" up screens and functionatilies each time I step into a project, and I already did it a few time, and I can say that it REALLY works - you won't find any "secrets" after everything is done.

      Sadly I won't be at Innojam, but I hope we have something like that in Brazil one day.  Happy to see that there are people that also think that we should all work together - developers, functionals and end-users, instead of keep going in this separated worlds we live on.

      At the next blogs i'll try to apply some UX technics into ABAP, like doing some research with the users, creating use cases, task analysis, mock ups and prototypes. Hope I can deliver that soon.

      Thank you for your comments!
      Mauricio Roberto Cruz

      • Perfect - now I don't have to rant!  Just agree.  It takes the entire team including the developer to come together and offer a great solution!

        Wish you could make it!  It's going to be a fun Innojam - it doesn't really matter which location!


        • Hi Michelle,
            Please do continue your ranting; this is an important subject, but if developers don't demand access to the users, then we will continue along the path that Mauricio spoke of in his original blog - Systems that are functionally correct, but unusable in real life.

          FWIW, I recently took  part in the Sydney Innojam, and I was part of a team at the 2010 Teched Innojam.  They're a great example of why (and how) team work gets things done.  I highly recommend to anyone remotely connected with SAP to get involved in an Innojam - whether you're on the Business side, a "Functional" person or a straight techo.


          • Thank you!  I plan on ranting, and ranting, until I sway people, and hopefully someone has read this and understands a developers need to do more.  And sadly at times I can't stop myself from nicely ranting at work.  "nicely" mmmmmm...  I may start another rant and try to get some of the others that commented ranting, those on the other side of things at the same time.  Maybe a good MQ set of articles.  I'll have to ask Otto.

  • Your blog brings up a couple of great points but in particular I like the comment about starting with technical design even before you fully 'get' the requirements. I think the same is true in the world of systems architecture, time and time again the architecture is defined before the requirements are fully understood. This is a very IT centric  approach to solving business problems and it is problematic in and of itself. We all get the concepts of standards and we all get the ideas of compatibility and supportability but the end-game has to be about usability and suitability.  If IT and those who are aligned with the IT organization and role persist in building technically sound but functionally unsuitable solutions they shouldn't be suprised if business units go maverick and do their own thing in isolation - viz the iPAD.
    • In one of my roles, I work very closely with the endusers and "functional" guys. (I enclose it in " since, it's only a rough description for the working environment). As a result, we - yes, we - are able to produce some very cool functionality.

      Part of this is down to the way I program - using the layer paradigm. In this way, when the user wants the screen to be cyan rather than heliotrope, I can make that change very quickly, without affecting any other part of the program.

      • Agreed.  Work together.  Don't keep the technical design in the functional person's hands.  Don't just blindly develop something without the functional person working with the process to see what is really needed.  Also they do know this little think called configuration.  They can configure solutions and not need technical help at all!


  • When you are a developer working on some "software factory" it's impossible to work closely with end-users. I already worked for a company at software factory and every time that we received complex requirement we used to meet end-users and hear their needs directly from them, avoiding handovers and "game telephone".

    It means, when we faced complex requirements join developer, functional analyst and end-user is a MUST HAVE.

    I'm truly believe that developers have very good insights about usability and screen designs. Functional analysts must provide functional solution, but technical design, including screens design, should be a part of developer work.

    • Really?  That's interesting.  I would agree that functional and technical analyst have to work together to get the right design.  But functional analyst are strong functionally.  (You said it.)  Developers are strong technically.  How can they get the right screen design, etc without talking to the users?  I would think there would be a lot of rework that could be avoided simply by having the technical, functional, and customer working together.

      Just my thought.  I don't and never have worked for a "software factory".  Just as a consultant, functional person, and project manager.  (And of course, technical person.)  I find my functional knowledge is becoming out of date, but is still good enough to help me program.   The people that went from technical to functional, their technical skills are out of date.  It takes us all to design the solution.  In my place of business the technical and functional specification are one in the same.  The problems come when the functional person writes both the technical and functional parts of the specification.  I am not a "programming zombie".  I am sometimes VERY hard to work with.  Some of you would hate working with me.  I need creativity in my job.  And so I do talk with the customer and the functional consultant.  Sometimes even when the functional consultant doesn't think I need to. 

      Now if it is a non-critical program, I will suggest changes, and when denied I will follow instuructions.   I let the functional consultant fall a bit when the solution doesn't work. 

      Their are times when the functional consultant very strongly feels I shouldn't talk to the customer.  So I do work like a "programming Zombie".  I get done a lot faster.  But the result isn't something I'm proud of. 

      I know what can be done technically why not let me access the customer? (Once you know it isn't functional - even before then.)


    • I also worked in a software factory, in fact, I can say I was "born" inside a software factory, and it's really hard to get close to the end-user in those situations.

      Thinking about that time, I remember we had modification requests for design-related issues, and those were always saw as "Functional Team" error, as apps design was created based on the spec.

      The software factory concept does works in some companies, but that doesn't mean that developers can't be close to the end-users... Just one good developer that could get involved with the users from project's start can solve tons of issues - not just design-related ones.

  • Hey Alejandro,

    Question is what are the benchmarks or how do we measure our capabilities?
    e.g. how do I know that I can call myself a techno-functional guy TRULY?
    How do I know that I am moving towards being a SAP consultant rather than being a technical consultant?
    Is certification a good way?



    • One thing that rattles my cage a bit, is the idea that you move "from" technical "to" functional. As though functional is somehow better, requiring more skill. The two roles are different, NOT incompatible skills, and can be combined, to great effect, in one individual. Not everyone can do both, but it isn't, in fact, that unusual. What makes such a role difficult to find in practice, is the blinkered mindset that technical and functional can never meet.

      • I totally agree 🙂 be a good developer has the same difficulty as a good functional, and of course no everyone have the same capabilities, you can se good developers "converted" to a horrible functionals, project managers, etc just because is the only way to increment the their salary. The problem is that most of the people thinks that a SAP developer only have to know ABAP, and ABAP is just a programming language, like C or Cobol... we can't do anything by ourselves without a functional/analyst...poor us...
        • Ok, I agree that a SAP developer can do much more than only develop, but what about key-users that turned into functional? Shouldn't they have some IT knowledge before turning into a SAP functional?

          How many of you ABAPers out there have already dealed with Functional guys who don't know that a SELECT means?

          And what about ABAPers that want just to develop ABAP programs? They can get functional expertise over the years, and I believe most of you just got to know SAP internal business process this way.

          It would be extremely perfect if everyone thought the same and were aiming to become strong SAP Developers, with both functional and technical skills, but this is not likely to happen. However, these two areas CAN and MUST work together to deliver the best to the customer, and that's what my article is all about.

          • A whole different question?  Should the business turn into a functional person?  Can they?

            I can say where I worked there have been a lot of people successful at making the change.  Now they have to have a technical mind set.  Some have developed Crystals, some have developed queries, some have done nothing.   BUT they can think logically.

            Hand in hand.  The functional team and ABAP team have to work together.  A good developer can work to strengthen the functional person's knowledge of selects, technical knowledge, and more.

            A good functional person will strengthen the ABAPer's knowledge of the functional area - or the project they are working on.

            New functional / new to ABAP.  Well get ready for a long project with lots of questions.

            MMMMMMmmmmm...  Another blog here?  I can debate this one too.  I think both sides need to know something about the other.

            BTW the move from technical to functional should not be considered a promotion all the time.  They are just different skill sets.  I think someone has already said that in this conversation.

          • I would say a good technical consultant can always turn into very good functional (techno-functional) consultant and then solution architect and the hierarchy goes up and up...

            I am not sure how easy would be for a funct. consultant to get into technicality though?
            This is no offence just a thought and can be very well be proven wrong.No debates on this....


          • No Debates!!!  What fun are you?  I agree, I think it would be harder to go from functional to technical.  So really not a debate.

            I think they can do it.  Many have some sort of technical knowledge they have to in order to design the functional solutions.  In my simple mind all configuration is - a table that controls how a program runs.  IE different paths depending on the program reading the configuration table.  Once you start thinking like that.  The functional consultant already knows how to set up those business rules that will be used to program.

            Harder - agreed.  Impossible - no.   I think they have to work with the developer to get the best solution if it is custom.  I think the developer should work with the functional consultant to determine if custom development is needed or if there is a way to change functional settings.

            BTW - a good ABAP developer sets up "Z" configuration tables at key points so that they don't have to make a program change for the program to work differently.  The functional consultant can just change the table.  I do this with anything where there was a debate during blueprinting.  Another argument for us to be involved early.

            Well - I can say this blog is really good.  The responses even better.  They make me think and make me respond.  (Maybe not good.  Although people can skip my responses if they are too boring or repetitive.)

            Thank you Mauricio!

          • Thank you for commenting and adding your thoughts here at the comments 🙂

            I'm satisfied with the results from this blog, and I'm already thinking in a lot of new ones! More debates are yet to come 🙂

        • Really?  Does a bad functional person make more money than an expert Technical person?  Is the job movement up or sideways?  Manager is up, but it does not mean a technical person could manage.

    • Why should you have to get any certification?  How do you know?  How do you know you are good technically?

      When I do phone interviews for development consultants, I do ask some functional questions depending on what they are being hired for.

      Since I believe all technical people should know at least a little bit of the functional, and all functional person should know a little bit of the technical.  That person has the same title.

      NOW - BPX, that person knows a lot about what the technology can do - not just SAP, a lot about what the configuration can do, and a lot about the business process.  So how do you know if you are a BPX?  That I don't know - as I learn more and more functional areas - is that me?  Nope.  At my work it's the title Business Process Architect.  And they do the 10,000 feet design and then the blueprinting / project team takes over.

      So yet another job to talk about!

      Again another blog?  These are some great points.  And could easily be put into a blog.  (Ranting to support your ideas.)

      "If a tree falls, and no one hears it, does that mean it doesn't make any sound?"

      It may make a difference to other people.  See the certification 5, and the work they have done.  I'm the wrong one to talk about it. 🙂

  • Hello All,

    Sorry for pitching in so late, but i see quite a few rants floating around.

    Imho SAP "educated" users should definitely be a part of the specifications workshop. By "educated" i mean users having prior SAP experience.More often than not they provide valuable feedback!

    On the contrary a "non-educated" user can be a pain. They ask uncomfortable questions like, "In Java we could do this, why is it not possible in SAP?". How do you answer this? You can't compare two programming languages & their UI capabiities for god's sake!

    Hope i can get my point across 🙂


    PS: This is not a rant, but a precaution to be on the safe-side.

    • 🙂  Education in the way you describe is exactly what we need. 

      Agreed - you can't compare two languages. It would be impossible, they each have good and bad points.  You can have each language in your tool belt and pick the right one for the right application.

      Not a rant - in this answer,


    • I beg to differ. WDA and WDJ might look the same from a usability point of view, but WDA is based on the ABAP framework, which is inherently more stable, solid and FT-500 proven than Java/J2EE and it's scruffy array of geek-invented open-source components (OK, we're in ranting mode, right?!?)


    • Woo Hoo!  That means I don't have to read the JAVA book for ABAPers that I've had laying around.  Sure, I don't.  I would differ as well.  It is a completely different language.  The more languages you know, the more you find similar things.  The same?  Sometimes.  Overall there are no differences.  Nope never seen that.

      • I never read that book, either. I tried, but the complexity of the whole Java world is astonishing. Like trying to build a space shuttle when all you need is a lawn mower... (uh-oh, not a very favourable comparison for ABAP...)

        Trond (still in ranting mode)

        • LOL!!!!  I bet the JAVA programmers would say the exact opposite.  It's easier to program in JAVA and ABAP is the space shuttle!

          Someday maybe I'll actually read that book.  I haven't had to yet.


          BTW - I like ranting, debating, it makes life interesting.

    • Yeah!!!
      Make it sound positive by saying
      ABAP is evolution and not COPY please....
      This statement of yours opens a Pandora box..
      Do we say Human Beings are copies of Monkeys/early men? Rather we say evolution.....

      Also do you say Java is copy of C++??and then keep going down the hierarchy......u will reach till LOGO languaage I bet....

      We take best out of technologies/languages and reuse the ECLIPSE in ABAP is currently in news.....I can say this as I have worked with Java and working with ABAP...
      Just a comment...not at all meant to offend anyone...We however cannot rather should not compare languages...Ultimately its the end product which is delivered.................


      • Great comment Kumud, I would just add that I've never said anywhere in this article that it was purely related to abap web technologies. In fact, my main goal was to hit classic ABAP developers....
  • I don't want the functional consultant to give me the fields - he can give me screenshots or show me where he is looking at the field in the system.

    I just want them to work with the user.  Come up with what they want.  Maybe just a general idea of a screen.  I want them to show me on the SAP screen / transaction what data they are looking for.

    The exact tables/fields?  Well I've had them do that, and be completely wrong.  Also it would take away from my analyst role.

  • I've been in projects in different Countries as SAP FI/CO but in Brazil the ABAPers got a extra role: to be almost a functional consultant. Business process knowledge is very required here. It explains a tendency to converge the professional focus to both skills.
    • I can only partially agree with you. Business process knowledge is really very required here in Brazil, but the majority of ABAPers whom I've worked with really didn't care about lerning "the functional side of the force". They just wanted to deliver a program that's correctly following the specification.

      Lucky you that worked with good professionals 🙂