Can we reinvent the grey haired ABAPer?
Over the years I have read many resumes, and interviewed many ABAP developers. Where I am dismayed is when I come across ABAPers (a decent proportion) who have made no real effort to proactively update their skills from what they learned a decade ago. Presumably if you are reading this blog you don’t fall into this category. It is as if there are two communities …. what I see online, and what I see on the street.
Here are some examples of my experiences with prospective ABAP developers and consultants in the last couple of years:
– ABAPers who don’t know about the existence of SDN, or of SAP Press, or that you can run an ABAP minisap environment on your own machine;
– ABAPers who think creating a BAdI implementation is enough to qualify them as accomplished object oriented ABAP developers;
– ABAPers (approx. 80%) who I meet have still not touched Web Dynpro ABAP; this before even considering flow-on frameworks such as Floorplan manager or POWL;
– Some ABAPers have come to me listing Web Dynpro ABAP as a skillset, but when I then commenced testing them on it they retracked and admitted no such skills;
– An ABAPer with 10 years experience who wondered why I was asking for Web Dynpro skills, when he had just seen a great new web technology called ITS.
– An ABAPer who appeared to have cut and pasted from a SAP Press book to indicate their list of skills, but when pressed on what a ‘regular expression’ was they had no idea;
– An ABAPer informed me that some interviewers forbid ABAP Objects-based development in their environments because ‘they don’t have the in-house skills to support this type of code’;
Obviously some of these are extreme examples. Nonetheless I feel that organisations and customers would naturally be better served if their developers understood and used modern day ABAP techniques and approaches. So, this leads me to think …. what can we do about it?
Here are my thoughts:
Advice for ABAP Developers
– Waiting for SAP instructor-lead classes is too limited. There are simply too many new techniques and technologies in NetWeaver ABAP development to gain coverage by attending SAP courses alone. Courses are useful for targetting important topics, but also follow SDN, TechEd, SAP Press etc.
– Waiting for a work-related opportunity to learn a new technology is too reactive. Good ABAP developers should seek opportunities to look ahead of the curve. Follow SDN, TechEd, SAP Press etc. If you are not working with an up-to-date release level, download an ABAP WAS trial version from SDN.
– Monitor the latest trends through social networks (LinkedIn groups, Twitter feeds etc.). These days I personally use Twitter to subscribe to SAP announcements, SDN blogs, and to follow SAP mentors.
– The modern-day ABAP developer should also follow trends outside of the ABAP language. Many of the concepts introduced to ABAP over the past decade have originated from other languages and technologies (for instance, XSLT processing, regular expressions, etc). Useful skills to explore would include HTML5/Javascript/CSS (including frameworks such as jquery), RIA development technologies (Flex, Silverlight), and mobile development (iPhone, Android etc.)
Advice for Managers and Team Leaders
– When engaging an ABAP developer, don’t assume your recruitment agency has performed a skills analysis to any depth;
– When engaging an ABAP developer, don’t be lazy with the interview – make sure people with good and up-to-date SAP development knowledge are allowed to participate in the process. Good due diligence up front will make a profound difference over the employment timeframe of a developer / consultant.
– Do your best to ensure your in house team knowledge and skills is up to date, so your people can properly identify others who are not.
– If your ABAPers are being sourced from a consultancy, if possible be allowed to verify their skills also. I have seen poor developers working for some of the largest consultancies.
– When I interview an ABAP developer who clearly hasn’t kept up-to-date, I recommend to them that as a starting point they read some SAP Press books such as the excellent ‘Next Generation ABAP Development’ by Rich Heilman and Thomas Jung (note that a 2nd edition is due in 2011).
SAP has worked hard over the years to reinvest in and extend the ABAP language such that it continues to be a world class development platform and still relevant for our times. There are many in the SDN community who appreciate this and make the most of it in their working lives. We just need to make sure more of our ABAP developers can do the same.
Addendum: It should be added that this blog does not dismiss the value of experience in business processes and functional modules (eg. development in FI/CO/MM etc). However, this experience is not difficult to find on the street these days. The challenge for ABAP developers is to couple their business and functional experience in the SAP application with continous learning to stay current in the latest programming approaches available to them.
I appreciate your viewpoints in the blog. There has been a lot of commoditization in SAP skills particularly the ABAP skill set.
One of your points: "If your ABAPers are being sourced from a consultancy, if possible be allowed to verify their skills also. I have seen poor developers working for some of the largest consultancies." Customers who DON'T do this are asking to be taken advantage of. It's irresponsible in my opinion... no different than me posting my credit card information on a website and naively expecting for no one to use them.
-nathan
The problem IMO is that the mentality of the supposedly 'any ABAPer off the street' and cheap w/new or older ABAP skills is in reality bunk. Yes, they may be cheaper or just plain cheap labor from India, China, or another cheap labor country, but their skills are in most cases very shallow in my experience. Comparing one person w/one or two years of experience to s/o w/20+ years is silly. I will take the 20+ years person any time no matter how much gray (or no hair for that matter) they may have. Programming experience is more important than flipping around a workbench, the new techniques, e.g. OO or WD4A are really not that much different than old-time structured programming and in any case can be learned on the job.
Instead of learning new skills I see many senior developers fixing and then explaining the fixed off-shored code.
This is the fault of short-sighted management who do not want to pay one shekal more for work and skilled workers. Programming is not s/t that one can just throw more monkeys at to get done. Often as not that creates more problems.
The cheap labor countries' professionals should also realize that they are cutting their own throats and that they could get just as much as workers in so-called 'mature' markets. There is more than enough ABAP work to be done, both in old and new portions of ABAP.
Regarding retraining or training, if one chooses to train at night that is a choice, but should not be seen as a necessity. Especially in GOOD programming it is necessary to often simply walk away from coding to give your thoughts a pause. Most humans are not meant to be 'on' all the time and like muscle training too much wrecks you.
Lastly, the Mini-SAP installation is after more than seven years still a joke and often as not does not work. I have had it install easily many times, but mostly it is one pain to install and takes a lot of tweaking to get it installed. Then it expires after three months! To me it really does not bring that much. Excepting for those of course who have no access whatsoever.
You have have hit the nail on its head. a lot of SAP folks started treating the technology as mainframe skills where things don't really change in one person's entire career, but with internet and smartphones driving the IT i don't see how a skilled developer can stay on top of its game without nibbling at Objective-C or javascript.
being no developer, i will still check the books you have recommended, too.
i've encountered all abapers described here.
I confirm that "Abap next generation development" is the best Sap Press book i have never read,i'm waiting for the 2nd edition!
Take care,
Stephen
as you already know this is one of my pet subjects and it's great to see others blogging about it.
I regularly rant about this subject and the more I think about it the more I believe that you are talking about lazy people. They are too lazy to foster a personal culture of lifelong learning. Too lazy to drive self-improvement rather than have it handed to them. Too lazy to be self-motivated.
I don't want to work with lazy people - and I am sure no one else does either.
Last word to Hugh. http://www.gapingvoidgallery.com/product_info.php?products_id=1718
Cheers
Graham Robbo
I was thoroughly enjoying the discussion within John's blog until I got to yours. That's quite a broad brush you are using to paint ALL of us who have not yet attained certain skills as "lazy people". I happen to be one of the "gray haired" ABAPers around which this discussion centers and I take pride in both my work and my EFFORT.
My particular role includes ABAP development, HR/CATS configuration, and project management. Since I have IMPORTANT work to do, I won't take the time to list all the valid reasons why some of us are more in the "Jack of all trades" category than the whiz-bang state-of-the-art technical specialist with whom you would prefer to work.
BTW..."We" don't want to work with narrow-minded people.
Have a great day!
thanks very much for your comment. I understand and appreciate where it came from.
Just to clarify my position - I suggest that people who are not prepared to be self-motivated to learn and expand their horizons are lazy.
I do not think people who have not attained a certain level of skills are lazy.
Skill sets are one thing - attitude is completely another.
Cheers
Graham Robbo
Great post. One close to my heart as well. I interview a lot of ABAPers and am constantly disappointed in their lack of up to date skills.
Recent examples I have seen:
- not knowing the difference between instance and class methods
- not understanding encapsulation
- not understanding regex
Web Dynpro should now be considered minimum level skill. ADOBE Interactive Forms is the new UI skillset to be looking out for.
I have an extensive list of questions for ABAP interviews and have high expectations. Sadly I have had to accept that not everyone has that pro-active approach to upskilling or adopting latest technologies as I would like. Those that are stand out. Good programmers are *many* times better than average programmers. Worth paying more for 1 good programmer over 2 average ones I think.
Regards,
Jason
I can tell you from my REAL experience that ADOBE Interactive forms are a mistake -- unless you are talking about OFFLINE processing.
I have replaced more than one poor looking and POOR PERFORMING Adbobe form with Native Webdypro ABAP at this point.
If you are building an online application, ABOBE forms is FAR inferior to WDA.
- Tim
Its a wonderful blog, its very much important for every abaper to learn new syntaxes and to learn new debugging skills with new debugger for troubleshooting.
If you are a magician, you must do magic’s, you can’t show your CV 🙂
😉
The points mentioned in this blog are the reason no less then 90% of our NetWeaver developer applicants are rejected. All points are very recognizable. People who qualify themselves as senior often have never written any piece of ABAP OO and generally do not know what the NetWeaver architecture/portfolio looks like. Granted it has become a lot more complex over the past years but you cannot hold on to the little island called ABAP forever. You should grasp the bigger picture and continue to learn and improve your skills. Standing still is no option in this time of rapidly changing and improving techniques.
Cheers, Roel
liked your post very much. I myself are a real ABAPer working for seven years now for different companies as internal ABAP application developer and as an external consultant/developer.
Up to now there never was a reason for customers to hop on to new technologies like ABAP-OO development. The expectations always were "don't waste your time with new development stuff" or "the application has to run quickly and stable - no matter how".
I tried to keep up with refreshening my skills doing some WD4A Development, keeping up with blogs like yours and trying to get as much knowhow as possible from events like virtual teched, but if you're not working with the new technologies day by day it's hard to improve your skills and obtain project experience a customer or employer would rely on.
As a matter of fact I recently had a customer that urgently needed my skills as a SAP Business Connector Developer and another customer that required a SAPscript guy - as we all know not the real new technlogies in the SAP world.
So unless there still are so many customers out there that are not heavily demanding for up-to-date development techniques, I still have to keep up with my work as an old-fashioned (soon-to-be-greyhaired) ABAPer 😉
Regards,
Alex
your critic is very vehement and not objective - I think. You're defending many experienced abapers, who do not know the newest stuff, but who can not simply be replaced by young "technos"!
You've eliminated one important section: it's not important to know many technologies but it's important to know and understand the business processes and the transactions and doings in the department! and to have practical experienc in FI or HR, etc.
So I'd prefer an greyhaired abaper with HR-knowledge and nothing in WDA before a WDA- or OO-abaper with no practical experience!
2. One previous writer said it already:
In many companies and depts WDA/OO is unwanted.
WDA will not be used seriously in germany except for travel costs or holiday planing in HCM.
But it's demanded in many job descriptions. That's a contradiction! Why? Becaus many recruiters ruled "copy and paste" but they do not know the desires and requirements of their clients...
3. And when I learn new staff (I'd learnt PI-developing this year)and have no REAL practise. For what is this stuff useful in 12 months???
greetings
Andreas
Thanks for your thoughts. Actually you do make a very good point. First and foremost, understanding of business processes, transactions and functional modules is important. I guess what I should have mentioned in the blog is that this is assumed ... simply because there not so much difficulty in sourcing these competencies. So the blog was not about old versus young (I fall in the latter category!), but really about a divergence in attitudes to self-learning.
What organisations I believe should really be after is ABAP developers with not just the business and functional experience, but also a well-rounded understanding of all the technology options available to them. And these people DO exist (and they are fantastic).
Here is an example scenario .... if I ask for a transactional ALV report to be made available to users via a browser (eg, through portal), I don't necessarily want the developer to code an executable program exposed via ITS. I might actually want a Web Dynpro with ALV, or even a POWL. I want the developer to have the skills and understanding of the pros and cons of each approach.
I was interested in your comment that in many companies WDA/OO is unwanted. It would be an interesting study about why this is. From my perspective it is unavoidable to take on these technologies. For instance, SAP is migrating WDJ ESS applications to WDA (as from Ehp5). Consequently it makes sense that if you are creating new custom ESS scenarios, you might consider writing them in WDA right NOW so you don't need to port them from WDJ when you take on the future enhancement pack.
The use of OO is unavoidable. Current and future techniques that SAP provides require this. Examples (other than BAdI) include custom HTTP handlers, custom SICF service login screens, Forward Error Handling implementations. In fact standard executable programs (for instance) can be written using local classes and methods to provide encapsulation.
But yes, I do agree that business and functional experience in the world of SAP is essential. As a colleague once told me ... "... in SAP you are coding around an existing application".
I think you may have slightly missed the point John was trying to convey.
The point being made is that all too often developers don't feel the need or the desire to take a look at new emerging technologies and skill up on them.
Whilst I fully agree with you that good strong knowledge of the business is a very important part of the skill set but it’s not necessarily the be all and end all.
Also, with regards to companies not willing to use technologies such as WDA or programming paradigms such as OO. Granted, that is the case is some companies, narrow minded ones mind you, but that should not stop the developer from downloading the ABAP 7.01 trial system and trying this stuff out for themselves.
This day and age you are rarely with the same company for the length of your entire career so adding a few feathers to ones cap is always a good idea given the amount of competition out there these days.
In closing I have grey hair, I have been around for a while and I still have the passion and drive to learn new technologies.
If I was too loose that passion then it would be time for me to be put out to pasture.
Cheers,
Neil.
I have updated the blog to include the Addendum. This is after considering the comments of Andreas. I do agree that business and functional experience in the world of SAP is essential. As a colleague once told me ... "... in SAP you are coding around an existing application". However the intent of the blog was a call for these same experienced developers to ensure they keep renewing their skills and approaches.
I agree with you that ABAP developers should pursue the latest and greatest technologies, but have also been given quite the runaround with SAP not making up their mind about which technologies to choose and stick to. Let’s take for example the whole move from SAP Script to Smart Forms, along the line dabbling with Crystal Reports and then finally partnering with Adobe. Also, on their way to web dynpro for ABAP, there was ITS, BSP and web dynpro for Java. Many clients are confused as to which direction SAP has taken and which technologies they’ll finally settle with for more than let's say a 2 year period. I’ve tried to keep up, but it’s quite difficult. And yes I do have quite an assortment of pricy sap-press books which I’ve read, but never get the opportunity to gain experience in. Many of these skills cannot be acquired unless you have a full blown integrated environment to practice in. Let’s take for example the Adobe environment. I was fortunate to gain a bit of experience a month in Europe. But most environments in South Africa do not have ADS installed and mini was/sap does not cut it. Neither does mini was/sap cut it for web dynpro for ABAP.
So, to some up; it seems like SAP is finally sticking to the technologies they chose and all developers should learn Adobe Print Forms, Adobe Interactive Forms and web dynpro for ABAP.
But the test environments/playpens are scarce and remain a challenge for a developer’s practical experience. I’m at the point where I’m willing to pay for a hosted test environment where I can work through practical examples. And don’t get me wrong, I’ve actually been on the SAP course, but these courses are way too short to gain an in-depth experience.
Best regards,
Adrian Bruwer
South Africa
You do raise some very good points which I fully agree with. And whether you end up in an project environment which has the relevant software is a matter of luck.
But what I personally rate highly is developers who are proactive in doing their best to keep up with the technology in spite of their circumstances. It sounds like you are one of those.
Where I am disappointed is when I meet so many developers who have never given it a thought to install a miniWAS and try out a few technologies, or even don't know that this is possible.
A timely piece, and to the point.
I just wanted to celebrate the fact that I never thought the day would come in the SAP world where requiring knowledge of regular expressions was almost a hard requirement.
If nothing else, this reflects how far SAP tech has come.
Finally!
For someone with grey hair, who has been in a relationship with ABAP since around 1989 (yes, before even ABAP/4, let alone ABAP OO) this has made my day 🙂
dj
Very good article and many points to consider. As being a team lead, I have had to gone thru the hiring practice of new employees and bringing on contractors for support and project work. I have had many times where I read a skill set or work experience on a resume and then asked them point blank during the interview to qualify or expand on that skill set. Their response was either vague or admitted they were not experienced in that area. I agree with your due diligence to make sure what you see on paper is what you will be getting when they show up for work.
Jerry
Congratulations!
Fabrício Alves Vieira
Systems Analyst
But even then I still find a decent number of experienced developers who have not sought to even try to understand the NetWeaver ABAP technologies. If you have taken the time to purchase and read some SAP Press books I think (based on my observations) that places you in the top 10% of resources on a scale of 'willingness to learn'. But yes I agree the practical experience component becomes more challenging as you take on more senior roles in your career. Something many of us have to deal with.
Thanks for a great blog.
Cheers,
Nigel
(See you at Mastering SAP in March '11?)
PS. Yes I will be presenting at Mastering SAP Technologies in March 2011.
Still, it's not easy as SAP launches technologies steadily. So, I think it's wise to pick only some of them - not necessarily all - that are of your interest and try.
Moreover, understanding of business process is essential to make a great developer as well, but this is more likely to be gained from real work.
Cheers,
Anirut W.
Also many developers are too quick to ask other for assistance instead of attempting to learn the new technology or feature themselves. While there is nothing wrong with asking for help, do so only after your have made a serious effort to try to figure it out yourself. Nothing reinforces knowledge more than self-discovery. Also while searching for an answer you may expose yourself to other things that while not applicable to the current problem, may help you with future issues.
Don’t limit your self-education to just new ABAP features. Expand your knowledge to learn proper programming techniques. Learning ABAP Objects is well and good, but if you don’t know proper Object Orientated programming techniques and practices, you may not be modeling your classes correctly. Learn design patterns and UML modeling as well to learn how to create more usable and expandable designs. For Web Dynpro, don’t just learn what UI elements, layout, or hook methods are available. Learn HTML, CSS and proper Web Standards as well. Knowledge of these topics can help you design better Web Dynpro components since will be able to understand what they are being converted into and how they should be laid out to create efficient and flexible designs.
Remember that you are the master of your own destiny and how you limit or expand yourself will effect your career for years to come.
I don't care abap anymore !
I'm 47 and I've been programming in ABAP for 15 years.
- In the real world, most developments are not done with OO. Too complicated the company says.
- In the real world, I've asked around my friends and coworkers and nobody ever heard of ABAP minisap environment. Maybe SAP's sales rep are not doing a good job ?
- In the real world, most companies want to keep the cost down and since SAP encourages them to keep their systems as "vanilla" as possible, not much WEB Dynpro development is being done. Almost no ABAP Dynpro development is being done either.
So, in the real world, your examples are not so extreme after all.
As for doing our part and keeping up to date, I have a life to live outside work (don't wait for your retirement to start to live. Do it NOW). If the company cannot set aside some time, during work hours, for us to improve ourselves, I won't do it on my precious free time. And, don't misunderstand me, I like learning a lot. It's the thing that motivates me the most.
That's why I moved to BW. I can use my ABAP skills to improve performance in our data extractors (and I mean BIG improvements). And I develop lots of necessary tools that SAP hasn't developed yet. And my main learning area these days is trying to understand the functional side of this business (I changed company because the last one moved it's headquarters from Montréal to Toronto and sended ABAP and BW jobs in India).
So there are other ways to keep up to date. The functional side is one, learning new tools (BW) is another one. I also learned some BASIS skills a long time ago. The BASIS job changed a lot since then but what I know helps me troubleshoot problems and keep the BASIS team on their toes.
Have a good life. Live it NOW.
Guy Lamoureux
I'm 45 also with grey hairs and I've been programming in ABAP for 20 years but I have another point of view.
I like to learn the relevant stuff, and now it means Web Dynpro ABAP wit FPM and POWL but also maybe a bit of REST and Flex and QR Codes and Augmented Reality.
Then instead of work all the day along in SE80 I like to meet customers, get their requirements and address new solutions. Then I provide the required training to the fantastic people that work in the team I lead.
At the end, the team is performing very well and customers are happy with the new kind of solutions I designed for them.
For sure, alone is pretty difficult...
Sergio
By now this blog is not only educational, but also entertaining! The reality is that you can grow up to a point technically and then you might have to consider alternatives e.g. Management, BI, cross over to functional or Basis etc. But to simply study the latest and greatest just because you feel compelled to stay up to date… that’s not a good idea. You’ll be wasting your time and money. Your environment must be leaning towards the technologies you study. For instance if your company is still happy in the 4.7 environment and you’re settled in your company, it makes little or no sense to study the “new stuff”. It HAS to be relevant. On the other hand, if you’re not keeping up with your companies technical environment and demands, you simply shouldn’t be in IT.
Adrian
What helps, some times, is to introduce new ways of doing the work. Try out the new technology, write up a small how-to, and present it to your co-workers. You'd be amazed at how easy and reqarding this can be at times, and it's fun, too. Using the BCS framework to send e-mails, using shared memory objects, how to implement an ALV report in OO-ABAP...
Btw, another book I've found very useful is the Design Pattern book by Igor Barbarich, also on SAP Press. And, there are also nice books issued outside the realm of SAP Press, believe it or not.
As a direct reply to Guy: I've also been surprised about the ignorance of SDN or the Sneak Previews (miniSAP) among SAP consultants, but found this to be more of a language issue. In general, there seems to be a lot more lack of info about these tools in the non-English regions of the world.
I'm not advocating language imperialism here, but to mee it's all to obvious that English is the Lingua Franca (sic) of the IT world, and non-English speakers just have to cope with that. The sad fact is that NONE of my French colleagues (present or past) have known about neither miniSAP, SDN, or SAP Press, or other initiatives like SAPlink.org or the SDN code exchange... I believe it simply says a lot about the reluctance among some linguistic groups to accept that the world of IT is primarily written in English (comments in pre-netweaver ABAP code aside 🙂
I'm also in my 40s, have a family, but still try to find time to expand my knowledge. Then again, I probably spend as much time in SE80 on my miniSAP as my wife does watching TV (or my kids do watching youtube or playing silly games on facebook).
Some times there's even more fun in the virtual world 🙂
I agree with the points in your blog; however, I'd like to illustrate some of the issues I'm facing and get some feedback/recommendations.
First, our ABAP team supports all modules/areas of SAP. Unfortunately, we aren't aligned to a specific module as our clients are, so we have a constant challenge of just trying to understand the tables involved, fields used, etc. Going from FI to HR and back again is a constant challenge with learning.
Second, while I myself would love to try to stay ahead of the curve learning new technologies, I don't know where to begin. There are so many acronyms and technologies out there that I'm completely clueless as to what I *should* be looking at, and there's nobody internally who has that vision to say, "Okay, these are some things you should look at."
Third, there's absolutely no time allotted during the day for learning, and it's been my experience that you can do all the learning you want, but if you don't actually work with it, you're not going to retain it and you'll just forget it. I understand the concept of learning outside of work on our own time, but as one person said earlier, some of us have busy lives outside the workplace. As a husband and father, that free time is very limited. If I were single and living the consultant life, things would be much different. But this is my reality.
I do try to learn some of the technologies we use in-house that we know little about. Most of our work is straight-up ABAP with ALV reports, some interfaces, etc. We have SAPscript and Smart Forms out there, and I'm trying to learn more about the latter. Just this week, I opened up Adobe forms and starting looking at that as well.
But all this WebDynpro stuff and other technologies? No idea. And I've found that SAP is just way too huge to try to understand all of it. At 40 years old, I just don't pick things up and understand them as quickly as I did at 20. It is so easy to get overwhelmed by just how huge the SAP world is, and when you don't have any sort of a compass pointing you in the right direction, coupled with all the challenges I illustrated above, it's very difficult and discouraging. Honestly, it makes me long for the COBOL days when things were so much simpler.
So, in essence, for me it's not a question of wanting to learn, but more of this: I want to learn, but I have no idea where to start, what I should be learning, and how best to learn it given the challenges above.
And this is where I would be VERY grateful for suggestions/feedback, as I often feel overwhelmed and discourage by all this. I could use all the help I can get.
Thanks,
Dave
I appreciate your response. In particular I agree with your comment 'SAP is just way too huge to try to understand all of it'.
There are many avenues you could pursue, but as a starting point my recommendation would be to purchase the 2nd edition of 'Next Generation ABAP Development' by Thomas Jung and Rich Heilman from SAP Press when it becomes available early next year. This will not make you an expert in the technologies (as it covers many, or the earlier edition did anyway), but it will open your eyes to the possibilities, and then you can choose from there what areas you wish to build practical experience in through various channels (eg. SDN, help.sap.com, training etc). This is the same advice someone else gave me years ago, and it was very good advice.
If you want to understand ABAP Objects better, I also can recommend the excellent 'ABAP Objects' by Horst Keller and Sascha Kruger. I liked it so much (mainly as a reference) that I bought the first edition and then the second edition when that was released (all 1059 pages of it!).
Good luck!
John
Some time ago, I was panicing about my ABAP career. There were rumours about ABAP being replaced by JAVA. Web based development was the direction. I knew nothing about BW, ITS, etc. Several years later am relaxed and confident in the fact that I can still have a productive and satisfying career in ABAP for some time to come. Have I stopped learning? No, certainly not - I am always taking advantage of opportunities to learn and grow my skills.
The thing is this, much of what I am learning are components and features of the "traditional" workbench. What surprises me most is that much of it has been around for some time. What is important here is to know that it is not just about learning what is new in SAP, but also about learning what is new to you.
I am continously exposed custom solutions developed by a vast array of technical and functional resources. All too often, there is a common thread of poor design and careless execution. Some if it stems from a lack of techincal of functional knowledge, but in my opinion, most if it is the result of a lack of core developer skills and attention to detail. If you apply these core skills and attention to both the analysis and execution stages, then you can build just about anything with just about anything. After all, in the end, we are not really "ABAPers", we are developers who happen to use ABAP as one of our tools.
Like any profession, it is not so much about the tools, but the professional who uses them. An expert craftsman can still produce fine furniture with crude tools, and a professional hockey player can still score goals with a wooden hockey stick. And so it is with programming. When it comes to traditional forms output, I suspect you can do just about anything with Sapscript that could otherwise be accomplished in Smartforms or Adobe forms (not talking about interactive forms here). That is not to say that you can't score a few more goals if you use a graphite hockey stick. But if you can't skate and don't have the skills to flick a puck into the top corners of a net in the first place, a titanium stick with a laser isn't going to help.
As a developer, your greatest tools are your ability to communicate, perform detailed analysis, and design effective, efficent, and SUSTAINABLE solutions. Only after you have mastered those will technology be of any real value.
Learning Java for the sake of learning Java is a waste of time. As a technology manager, implementing the latest technology just because it is new is foolish and counter productive. The more homogenous an environnment, the better. Each new platform you introduce will only add to your cost of technology ownership and support. Those companies that make concious decisions to avoid new technologies are not necessary making a mistake, particularly if there is no cost-benefit. And neither are you, if you don't have a foreseeable need. I don't have an iphone or blackberry, but I don't need one either, so I'm not going to waste my time and money buying the hardware, muddying up my PC "landscape", and burning cycles trying to figure out if I can get any use out of it.
So, my advice is to relax a little about all the latest buzz words and just be diligent about making sure your core skills are in top shape, be aware of what's going on around you, and keep your eyes open for, and take advantage of, opportunities to learn something relevant and useful.
Thank you for a very articulate addition to the discussion! I especially agree with your comment ... 'in the end, we are not really "ABAPers", we are developers who happen to use ABAP as one of our tools'.
The only area where I might disagree is the ascertion that learning a new technology requires a new platform (as it did with WDJ). If ABAPers want to confine themselves to the ABAP stack, there is still plenty to learn there without a new installation. XLST, BSP + HTML/CSS/Javascript, Web Dynpro etc.
Cheers
John
Firstly, just to set the record straight ... As the author of the blog I also consider myself also a "grey haired" ABAPer (even though my blog post doesn't show any grey in the photo!). I am in my 40s, and like many who responded I have to balance the challenges of family, children, and a busy life. I commenced my programming career in the early 90s as an ADABAS/Natural developer and then moved to SAP in the mid-90s. The term "grey haired" was taken from the fact that I am seeing this in SAP presentations now (eg. relating to Gateway), so it is not an original term that I invented. And if anyone thought through my blog that I consider myself an expert ABAPer, I am not. Having worked with and seen the capabilities of people like Alisdair Templeton (who along with Matt Harding recently won the Las Vegas demo jam at Tech Ed), I could never consider myself an expert.
My interpretation of the last decade is that SAP sought to establish the ABAP technology as a development platform in it's own right, and to extend it's reach outside of SAPGUI to the browser and beyond. And with ABAP you don't even need another server to do it, you can harness the ICM and accomplish many great things (for instance the TechEd Demo Jam winners at Las Vegas did precisely that). I did mention Web Dynpro in the blog, but that is just one example. I have worked in organisations where the SAPGUI user licenses were a fraction of the NetWeaver licenses (since professional SAPGUI licenses are much more expensive). So consequently in that environment an ABAPer who can harness the web channel can have a reach substantially more than one who can only code for SAPGUI, and therefore in my mind is more valuable (all OTHER things being equal).
On the topic of learning other technologies (eg. HTML/CCS/Javascript, Flex etc), I strongly believe there is value to be gained in this. The world of ABAPers in the 90’s was very closed and inward looking (you worked within the confines of SAPGUI and the application and there was a clearer boundary from a UI perspective). The last decade brought about the opportunity for ABAP developers to integrate with other technology groups in the organisation (eg. the web team). If you can work with these people and SPEAK THEIR LANGUAGE, the opportunities to collaborate are significantly enhanced and you find they will respect you more, and that you can build things together that you may not have even considered.
When it comes to things like ABAP Objects, I disagree that it should be ignored. There are many features of SAP that can only be accomplished using ABAP objects (Web Dynpro, Forward Error Handling, POWL, Service proxies, Custom SICF login screens, and many more ...). Maybe you might not see this if you are in an old environment, but when you upgrade you will. And this is even before considering the natural benefits of OO.
Those of you who raised the importance of experience, I agree with you 100%. Underneath the lingo, it is experience that really delivers. My blog was much more a rant about the complacency or disinterest that I see in some ABAPers when it comes to reskilling or taking at least some responsibility for their own future. I do firmly believe that in the world we live in now, with razer thin training budgets and cost cutting, we cannot expect the organisation to take responsibility for our own training.
I am very passionate about is the SAP community making the most of the opportunities in the technology, and also for ABAPers (including myself) to NOT be consigned to 'commodity' status.
Finally, thanks to all of you who have responded to the blog. If it has inspired at least one ABAPer to at least go and learn something new in the ABAP world, it would have been worth it.
I got myself a role as the "ABAP guy" in a company, who required about 2 days a week, doing the ABAP on the BI/BW platform. I'm pretty much able to define how things are done, and so started doing things the object oriented way. ( I'd already learned Java while on a contract away from home, so i applied what I learned from that to ABAP Objects ). In the five years of doing this, I've developed a number of different frameworks which readily allow reuse of code. While my colleagues understand ABAP reasonably well, they're not programmers, and do sometimes find following what I've written quite difficult - though it is well modularised, encapsulated, and commented. But they do appreciate that when a new, but similar requirement comes along, I've got the framework there, and can rapidly produce what they need. It's very gratifying to be able to just quickly subclass a class, or make a new implementation of an interface, and produce some valuable new business functionality.
It is VERY hard to do that outside of an OO context. So when I hear "It's too complicated", I know that that is incorrect. OO development may initially have an overhead, but in the long term it will save companies money. Especially in the maintenance stage of a development. I think OO programming requires a discipline and understanding of program design that is greatly lacking in a market place that views ABAP developers as commodities - "one size fits all".
Most of the stuff I do is back-end, so not much scope for Web Dynpro. But I've had a few opportunities, and we now have a nice UI, that allows users to select a file, upload it to the appserver, and then launch a process chain that uses that file. The users love it. Nice and simple.
The fact is, however, that I'm in a very good place, which has relatively new technology, and I get to do interesting things. For your average ABAPper, churning out a new report from MARA, there's little opportunity to apply new knowledge. And in my fifteen years, dynpro/web dynpro/bsp requirements have been fairly rare.
First of all, I like it that you brought this up. Just like some other topics (ABAP v Java, Certification, off shoring, etc), it's one of the "hot potatoes".
I like it that you aim to "keep it real" when it comes to the vastness of a SAP developer skillset these days. It's pretty much what I try to convey in conversations with colleagues and customers. And you know what? They like that sort of respect for the ecosystem and skills!
However, I do think the title of your blog was unfortunate though. I personally know some seasoned ABAPers who don't want to become immersed into new technologies such as WDA, Flex and SOA. I think that has to be respected, too. Just like there are good and bad builders in the trade, there are good and bad ABAPers. I think this also has a lot to do with ambition and most importantly it should be everyone's choice to pursue the new skills everyone is keen to get under his belt. Let those developers work that out for themselves.
I was lucky enough (or maybe not) to become involved into ITS and eCommerce SAP topics at an early stage of my SAP development career and was keen to learn JS, CSS, BSP, WDA and later on Flex. I've dabbled a little in iOS development, but all of this was my own choice and interest. You can't demand this per se from others. If such a person lets the team down then it's a different matter, but let's not generalise.
One final point I'd also like to make is that a lot of programmers I've come across in my 16+ year career in IT simply can't communicate. They can produce the best WDA or Flex app, but are struggling when running a workshop or requirements gathering. Or they can't communicate effectively with managers when it comes to working out estimates ("well, it takes as long as it takes!", ever heard that?). To my mind, I think a team needs a good mix of people with some that might not be as skilled but good communicators on the one hand and the gurus with a lack or less of the latter. You have to be VERY lucky to find people that combine both (and they usually come at a price!).
Overall, thanks for a sparking off a lively discussion!
Michael
Thanks for your comments. The more I think about it, the more it seems that the software is evolving at a faster pace than many developers can keep up with it. To put it another way, it seems there is an increasing divergence between the capabilities of many developers and the capabilities of the SAP technology.
At a strategic level, I wonder how SAP feels about that. After all, there is no point having great capabilities built into the software if not enough people are taking advantage of it. In the battleground that SAP plays, taking on other software giants such as Oracle, this should be a consideration for them. Maybe that explains things like Gateway where SAP has slides that show that the 'long haired' developers will work on the UI layer, with whatever cool new technology they like, while the 'grey haired' developers remain to do the server-side work.
At the individual developer's level, I think the skills issue is a difficult one. Many of us older developers now have families and other commitments on our time. At the same time there is an increasing trend towards outsourcing or offshoring (sad reflection of the commoditization of the ABAP developer). My view towards avoiding commoditization is to keep up with the new technologies and approaches as best as possible, but certainly it is not always easy.
The difference between Object Oriented programming and procedural seems to be a big problem for many developers - they simply seem unable to make the switch to the new paradigm. In the Microsoft world there is, apparently, a similar problem with VB programmers moving to .net. Finger in the air, I'd say 10% of developers will be able to use OO concepts well, 30% will be able to adapt, 30% will struggle and 30% just won't be able to do it.
GOOD WORK
Top content John - even in the new SCN. It is a challenge to stay current but it is critical to continually sharpen the saw.
Cheers,
Nigel
And now, after 2 years since John's blog was written... what new skills have I acquired?
Good question K L. What skills have you acquired - and how did you acquire them?
Well Graham... Experience is the best teacher... and time.. is the worst beautician... I have fewer grey hair, because I have fewer hair now after 2 years.
For the past 2 years, I was not able to acquire new skills, but was able to further my current skills. Don't get me wrong, I was not being lazy, I just did not have the opportunity to learn new skills. So rather be a "Jack of all Trades and a Master of None" kind of person... I went and master what I have.
I have fewer hair but still more grey hair - doesn't seem fair to me.
C'est la vie...
And thanks for your blog "A call to arms for ABAP Developers"
Seems like a good excuse to cross post to it. 😉
A Call to Arms for ABAP Developers
Thanks K L.
Hi Graham,
I found your post last year and this post just recently. I was frustrated that many IT in my area do not follow this. They come from other professions and look forward only to the weekend, payday, and retirement. It can be frustrating to have no one to talk to in a crowd.
Mike
Come to SDN - you are sure to find someone to talk to. 😉
Try bald...... 😆
Hello John,
I too agree with you, ABAP Developers hardly make use of Object Oriented Concepts.
They now how to make classi.e Syntax and how to use T codr 24 but donot know why and when to make the class.
Even I face difficulty to gain Information relating to new happenings in ABAP world.
I perosnally believe that one must study other frameworks too.
I will be very thankful to you if you can throw some light on new technolgies integrated into SAP.
Also let me know about ABAP WAS trial version.
Thanks
Sandeep
John,
great article, I find it a bit odd that nobody has mentioned the challenges that the adoption of HANA will bring for ABAP developers.
Is HANA not yet on your timeline, or do you think it's too big a jump for somebody to make from ABAP to SQLScript? I think there are a few very talented developers around that will be able to make good use of the new technology, on the other hand I fear that for many this will be impossible to master.
Albrecht
Hi Albrecht,
Thanks for your comment. I think the reason why the challenges of HANA was not mentioned is that this blog was written in 2010, when HANA did not have as high a profile as it does now.
I talked to Thomas Jung about his learnings about ABAP on HANA last year. The first thing he said was he needed to buy a book on SQL to re-acquaint himself with it. The second thing that I found interesting is that much of what we learn about good programming practices in ABAP by removing load from the persistence layer can turn on its head when using HANA. So I agree this will be another challenge facing ABAPers. In fact Graham Robinson alludes to this in his more recent post ... http://scn.sap.com/community/career-center/blog/2012/10/24/a-call-to-arms-for-abap-developers. Hope you pick up on his reference to "Huge Absence of Nifty ABAPers".
Regards
John
Hi John,
Its really a nice blog,Although I am a bit late as I entered into SAP world in 2011 but during my certification I learnt WDA.I had worked a lot in WDA and I personelly enjoy working on WDA but still I feel I am just a beginner.Also as you said to update your skills I totally agree with this as even I am feeling the same.After reading your blog I felt now its time to upgrade my skills. I have been as a abaper for quite a long time and also started working into SRM technical.Moreover regarding skills update how to go for it as your company is still working on old version and old technologies.Even if you provide a suggestion to work on new technology and you are pretty sure that you can handle still your boss feels old is gold and work on old technologies.When I was in my previous company atleast few people knew about WDA but when I changed my company I think a made a big mistake as I have enter into old era were people still working on old abap version and when I see the screen I feel like to sleep.Also WDA is new to them as its quite a long time WDA has hit the market.
Regarding new technologies in abap where to learn from and come to know about these technologies.I also have a lookup in sap press but unfortunately books are not delivered in my place 🙁 . So I can't even buy and read those books 🙁 .
Last thing your blog will always encourage to new abapers that certification is not only the last step still more is left 🙂 .
Thanks
Gaurav Gautam
Hi Gaurav,
Thanks for your response. I think that since I wrote that blog, in more recent times I've felt that the SAP ecosystem is at a crucial fork in the road. And its not simply about ABAP developers. What you said ...
... and ...
. Your story is not uncommon. I just hope that enough of the ecosystem helps to drive SAP forward, because truth be told there are now some next-gen cloud-based providers innovating fast (eg. SalesForce, Workday), meaning it is now more important than ever that SAP on-premise organisations try to keep up.
Cheers
John
This is an interesting blog that obviously triggers a lot of response.
Too many to read, really...
Here are a few of my thoughts:
SAP is big, REALLY big. There is a lot to learn.
A development consultant can try to learn a bit of everything and then talk about all the things he knows. But in all honesty, that usually means that he talks about all the things he KNEW.
A good developer will know how to solve issues he does NOT know about. He will be clever enough to search for the answer, find it and implement it (properly).
When in a job interview, it is often asked what you will do when you do not know the answer. I have had this question before. My answer? Google and SCN. There is a good chance that you will get a smile and an understanding look.
Another question is: Are you a good programmer? My answer? A careful and hesitating 'Yeeeeees'. I explain the hesitation by stating that the more you learn, the more you realize that there is a lot more that you DO NOT KNOW. That however, is usually not the problem.
Truth is, I have less to no faith in a programmer who will confidently state he knows everything.
I originally commented back in late 2010, almost 6 years ago. I have more grey hair, but predictably less hair overall. I'm an old dog, but still learning new tricks. Just picked up something today.
I have just come across the class CL_DD_DOCUMENT (see package SDYNAMICDOCUMENTS for examples). I had added a text box (CL_GUI_TEXTEDIT) to a popup screen I created (as a drill down from COOIS). The customer asked if I could change the background colour and/or font. I was pretty sure I couldn't - I knew I'd looked into this before. Still, I decided to pursue again anyway. Sure enough, I come across this new class and my mind immediately started spinning about all the new possibilities for creating useful content for my users.
Further to my thoughts on learning what is "new to you", all this came up through a customer who is on a very current release of SAP. I just logged on to another customer's system who are still on 4.6C, and sure enough, that class is there, too! More proof that there's always something new to learn. What's important here is that I am taking the time to really pick this apart now while I have a requirement that can use it so that I understand it enough to use it well and will remember it as another tool in my toolbox.
Further to my thoughts on developer soft skills like communication, I caught myself initially saying "no" to my customer when the asked for something different, but realized I really should check again. This is what lead me to this new-to-me functionality and I will now be able to deliver what they wanted and they will be very happy. And that is our ultimate objective.
A side note on the progression of technology, it occurs to me that, although this dymanic document class has been available since 4.6C, I have rarely seen it employed anywhere - perhaps part of the reason it's taken me so long to come across it. It is clearly more labour intensive to use than some of the more traditional tools. Is this the reason it is not as pervasive? I just recently learned how to apply different ALV cell styles, too - bold, italic, etc. This also provides alternatives for building a much more user friendly application. Which brings me to SAP's lastest thrust - Fiori.
I am currently taking the "build-your-first-Fiori-app" OPENSAP course. This is the latest toolset offering from SAP for building, amongst other things, web-enabled applications. This one looks like it might endure more than past offerings. It seems quite robust, including being geared for multi-platform development (tablets, etc.). That said, there are two points that stand out to me.
1. It seems yet again, there is a high level of complexity involved if you really want to develop useful robust applications. In depth learning will be the key here, but with all the added flexiblity, design becomes all that much more important (and so the availability of additional prototyping tools). But it must be remembered that design starts with communication - listening to the customer, understanding their needs, and presenting back options with pros and cons around complexity, sustainability, and of course, cost. On the point of cost, how long will it take to build useful custom applications? Will this be something that can take off in the world of non-SAP-internal developers, such as myself?
2. The message I am getting at this point is that SAP intends to replace all front-ends with Fiori. If I understand correctly, that includes eventually eliminating the Netweaver Business Client (SAPGui). If that is true, this is a mistake - a clear example of forcing technology for technology's sake. Given the effort involved, will we end up with a myriad of mediocre applications?
I am looking forward to seeing where Fiori takes us and am going to invest some time ramping up my skills in that, but in the mean time, I am still going to take advantage of whatever I can find in the "old-school" to deliver useful functionality.
Great posting, Kelly! As you can see above, I too commented on this thread in late 2010. I guess I've always kept alerts going on this thread, so it was a surprise to get an email announcing an update to the thread!
After 11 years of working as a Developer in SAP, I still feel like there's so much out there I don't know. I've made peace with the fact that I'll never be able to learn it all -- SAP is just too wide and too deep for that to be practical. And as a true grey (in some places, white) haired ABAPer, I don't learn things quite as easily or as quickly as I did, say, 20 years ago. That makes a big difference when you're trying to learn and grasp new technologies, especially when they're radically different from what you were taught and have used in practice for almost 30 years.
A good example is FQEVENTS. I was Googling for a solution to a customer's project and came across FQEVENTS as a place to insert some customer modifications. I'd never even *heard* of FQEVENTS until last year. So there was yet another place, another technology, that SAP had come up with allowing for users to put customer modifications.
A couple weeks ago, I was in a Maximo administration fundamentals class, and I was absolutely amazed at how quickly and easily the trainer was able to make configurations that allowed for customization to the database, to screens, etc. I realize Maximo is certainly not SAP, but I found myself wishing SAP was even a tenth as easy as what I was seeing.
There's interest here in Fiori and mobile. We're not quite at a place yet where we can run Fiori and we don't have HANA yet, either, so I'm not sure how that would play out. I don't think customers are going to be happy with standard SAP response times on mobile apps until HANA is in place to deliver the speed and response times they expect. Until then, I just try to keep my head above water and learn what I can. Getting Web Dynpro for ABAP under my belt has probably been the single largest thing I've added to my toolbelt of skills, but when you come from a background of procedural programming all your life, some of that took some real effort and time to understand.
My biggest frustration with SAP is that there's so many different paths to accomplish the same end goal. SAPscript, Smart Forms, Adobe Forms. User exits, BADIs, FQEVENTs. It goes on and on. I get that it's the nature of the beast when it comes to IT; technology just evolves and changes so fast. But it *is* hard to keep up. You've got your daily job to do. At the end of the day, it's difficult to go home and spend several hours trying to learn something new when you're tired, you've got a family that you want to spend time with, etc. And even if you learn it but don't use it, well, it doesn't stick. So it's definitely a challenge trying to stay abreast of the latest things going on with SAP.
Personally, myself, I'm exploring general web development as my professional development. I've just completed a C# course and will be learning HTML, CSS, JavaScript, and ASP.NET MVC. I think some of those skills will cross over to the SAP side by the time we get to Fiori, but given the extremely dynamic nature of SAP and the challenges that brings, I'm keeping my learning options open. Luckily, I work for a great organization and a wonderful boss that allow and encourage me to do just that. Because at the end of the day, I have to look at where I am and think, "Can I do this for another 15 or 20 years?" 11 years in SAP feels more like 20 years to me. Developers are expected to continue learning new things, and I get that and accept that. I do enjoy continuous learning! But can I realistically learn and keep up with new SAP technologies, or is it time to look at something else that will keep me invigorated and excited about IT? So that's where I am, personally.
Again, great post, Kelly -- thank you for sharing! It's always nice to hear from other SAP developers and their thoughts. 🙂
Dave
Hi, Dave. Thanks for the comments and sharing your thoughts, too. I can particularly relate to your question "Can I do this for another 15 or 20 years?". I often ask myself that very question - somewhat reassuring to know others are, too. In the IT world, I think SAP can keep me engaged and interested, but for me, the bigger question is how long will I stay interested in IT? (in whatever capacity) I've been involved in some form or another since I was 19 and application programming since about 22 or 23. (I started out in COBOL, too.) I am happy to say that I still really enjoy my work for the most part, but do worry about staying relevant and I also sometimes daydream about other things...... I guess that's just the way it goes for anyone who's been working this long, no matter what they do. For now, my mortgage will be my motivator!
Hi Kelly & Dave,
loving your insights. It would be great to see you guys collaborate on your own blog around these issues. 😏
Cheers
Graham Robbo
As a moderator, I can only say "yes please!"
I'll see your 11 years and raise you a 19 years. I learned only a week or so ago, through this very site, that SELECT ... APPENDING INTO TABLE ... works with HASHED and SORTED tables.
I'm currently beginning my Fiori journey - I'm with the same client as I wrote about above, six years ago. Since then I've done a lot of web dynpro, but now I've the opportunity to take the app described there and redevelop for Fiori, as PoC. I like my client. 🙂
While I may have picked things up more quickly 20 years ago, I find I'm still capable of learning very effectively. The thing is, as you get older, you become (for want of a better word) "wiser". That is the new knowledge is fitted into your knowledge framework. Much of anything "new" is really a rehash of what you already know. Once you've got up that first learning step (I call it a step because it often seems vertical, rather than a curve), you find that you've already done something similar to this in the past. There is nothing really new under the IT sun.
I have used CL_DD_DOCUMENT at least one. I had developed an application using a SALV table - and then discovered it was needed for a release earlier than that. I had a pretty header (I think perhaps SALV uses CL_DD_DOCUMENT), but lost that having to redevelop for a standard ALV control. I used CL_DD_DOCUMENT to get it back.
I knew about it because I remembered reading an article years ago in the SAP Professional Journal.
I too am a greyed hair Abaper with a widening forehead. They call it receding hairline, I call it increasing wisdom.
I am on bench now, not that my skills are not updated but that, there are cheaper options out there, offshore out there.
Being on bench makes me cower in fetal position, because of the thought that my company might let me go and then I have to go through the process of applying for a job and being interviewed, being asked by young IT managers about new technologies, maybe to measure how old-school I am. Lucky if I get an interview, some companies will call international.
Because of this thought and while I still have resources available to me, I went ahead and started learning new technologies (relatively) e.g. I am now doing ABAP in Eclipse, learned about ABAP in HANA (Code to Data Paradigm) and now I am moving on to Gateway, SAPUI5 to Fiori (all thanks to openSAP). (I am also learning how to become a real estate agent - just in case)
At my current situation, all of these new stuff are just "theoretical" until I'll have a new project that needs them or an environment that allows me to apply them. I could not even put them down in my resume, I'm not that sort of guy. Hopefully though, they will stay in my head for a fair bit until required.
I usually tell myself that "Everything can be learned, I just need time". And with the hustle and bustle of daily life and of a mid-life crisis, being on bench has it benefits... but being on bench is a good thing that makes you wish that it will not last long.
You bring up some great points, K L. I can empathize with the bench blues as I spent a number of years with a few different consulting firms. It can be daunting, but I say taking the opportunities to learn is a good thing. Still, I understand the theory-vs.-practical situation - it makes it hard to know what to focus on, what's really useful, etc. I fought that battle myself when learning for the sake of learning just to fill some bench time. All of that said, I would suggest that you offer more value than you think.
On the employment front, I know the fears that come with working for a company as an employee and the notion of possibly having to find new employment. I eventually (and thankfully) managed to transition to independent contracting many years ago and, knock-on-wood, have been gainfully employed ever since with a few long term customers. I always did well in my cube-farm days, but never really liked being part of "the machine", always under someone else's thumb. That's not to say there's no pressure as an independent, but it's a different kind of pressure that, for me, is way easier to force my way through. It would be next to impossible for me to go back now, largely in part to the very fears you expressed about conveying my value on a sheet of paper and, if lucky, during a 30 minute interview. I actually had those very fears realized recently. I was contacted by a head hunter for an assignment related to a Fiori-centered project - I thought for developing supporting back end functionality. I knew it probably wasn't a great fit, but I handed in my cv anyway. They sent me out on for an interview - the first I'd been on in years. I wasn't nervous in any way, but I also knew I wasn't doing a great job selling myself. I knew it was over though when I was asked what I thought of global variables. Well, I happen to like global variables and, like a big dummy, I said so. That was the end of that - it was written all over my interviewer's face. It definitely bruised my ego a bit.
Right around that time, I got another assigment that was a much better fit (the customer referenced above) and they have been super pleased with my results. While the failed interview shook me a little, I regained my confidence through the successes of this most recent assignment. The real story of my success here was my ability to interpret the requirements quickly and add some savvy of my own to deliver useful deliverables. Nothing fancy as far as technology goes - just reports and a couple of screens - I actually ended up developing one report using classic ABAP list! For that list report, it was the right solution in that case, and I made more useful with colour and drill-downs. On the communication front, I fought an uphill battle to learn a functional area of SAP I had no previous exposure to, but was persistent with the functional consultants I was working with (who, fortunately, were great). All this was done remotely (and while supporting 2-3 other customers - speaking of pressure). I never met a soul on the project in person until 7 months later, when I was asked to be on site for go-live. All communication was done via phone, skype, and email.
You really must not fear off-shore. "Cheap" is relative. This assignment referenced above came about when the customer bailed on their initial implementor - a large big-name consulting firm that used off-shore development. I saw first hand what they produced and, let's just say it wasn't great. It certainly did not meet the customer's requirements and it took them a long time to build it. All of my assignments were to address "defects" raised during testing of said deliverables. I quickly realized I could not salvage any of what was there and made reasonable arguments for rebuilding, which included spending less time than trying to repair. In the end, I was able to produce better deliverables in much less time. While my hourly rate is likely much higher than an off-shore resource, the overall cost ends up being less because I spent a lot less time developing much better solutions. That value increased when changes inevitably came down and I was able to react quickly with limited effort thanks to the basics of structured design and clean code. And despite (or perhaps because of ?) me liking global variables!
I would encourage you to look at the independent option. I am guessing you have worked on many sites over the years, hopefully adding some contacts to your phone book along the way. I would suggest your communication skills are more valuable than you think. Call around - direct to former customers if you can, see if anyone needs a report or something, and tackle it on the side. That's the beauty of remote work - nobody expects to see you in front of your keyboard from 9 to 5, nor do they care. They just want their report or whatever done by when you say you can get it. If you can swing that first assignment, then before you know it, you'll be their "guy". Most shops - especially the smaller ones - want to be able to say "I have a guy" (or gal). Off-shore will never fill that need. I hope you can find a way to give that a shot and I wish you much success if you do.
With my moderator hat on, can I suggest, Kelly, that you make the above post the body of a separate blog.
Hi, Matthew. I was actually questioning myself while writing if I was getting too off topic, but really, it very much fits right into the "re-invention" theme. Re-inventing yourself should not be limited to the scope of technology. It can and should also be about leveraging and improving your soft skills and finding new ways to monetize them. When I joined my first consulting company many years back (before the grey kicked in), I was fortunate to be interviewed by and work for a very smart guy who occasionally took the time to informally mentor me with advice. There were two things he told me that I will always remember.
First, he told me I was "bright but clueless". Taken from a Dlibert cartoon, as I recall. It took me a while to really understand what he meant, but I eventually got it: I was smart and productive - bright, but I had no idea just how valuable I was to my employers - clueless. And he was right. He asked me what salary I had negotiated and he explained how much I had jipped myself. Which led to the second thing I will always remember:
You will never be in a better position to raise your salary than when you are changing jobs. I get it all now, but being clueless at the time, it was important for me to hear him explain that the job of the HR department - and any manager, for that matter, is to spend as little as possible on salaries. These bits of wisdom served me well down the road.
The point is, most people, not just folks in our field, tend to underestimate their value. K L unfortunately spoke of cowering while on the bench. Rest assured his management knows that and takes advantage of it. I once had a contract where I joined a few other developers who had been on that assignment for years. The commute for most of them was brutal and the rate was mediocre, but a couple of them in particular were really very good. I took the opportunity to try and pay it forward by letting them know just how good they were and that there was nothing keeping them from reaching out and looking for additional remote work, and at a higher rate. One of them did for sure, and I think another did as well. To my mind, that is as much re-invention as anything else. That's my message to K L and anyone else who is questioning their value. Examine yourself carefully, maybe consult with some trusted co-horts and see if there isn't more there than you are giving yourself credit for.
I do agree, there are a few other threads that could be started - what it takes to start contracting, how to define good communication skills, what good design and customer satisfaction mean, but I've maxed out my blathering for a while. I'm going to go dye what's left of my hair now.
Very well written, sir. I think that what you are describing - picking up the pieces after the cowboys have been kicked off the project - is a very common experience.
It's spookily similar to what I am working on right now.
And generally it's the bald (grey haired) abappers who know how to do their job who pick up the pieces (imho).....
Hi John Moy,
Nice blog!!!!!! Helpful to Come out of the circle...
Regards,
sudarshan
Almost a year later, and I am asking myself the topic of this thread more than ever, although perhaps not unexpectedly. What has changed? HANA, Fiori, the Cloud, S/4. Where is it all headed?
All the points I have made to date are still proving out for me, for now. I have continued to bring real value to my customers with useful applications developed on the 'ol workbench. The world is changing around me more than ever now, though, and it cannot be ignored. One the one hand, I have a customer who has migrated to third party support, meaning they intend to stay on 4.6C indefinitely. Will that even be sustainable? Time will tell, but I suppose there is some comfort in that there should be a place for my skills for the foreseeable future. On the other hand, I have a new customer that is running R/3 on HANA. The last few requirements from them are for some relatively simple ABAP logic that leverages custom Calculation Views that he wrote - something I currently know nothing about. Looking further into the future, the current outlook for R/3 goes to 2025, but that is really only 8 years away - long before I plan to retire.
What, then, does this all mean to me, and the other "grey-haireds" out there asking the same questions?
Scenario 1: Looking "backward", if you will, perhaps the need for "re-invention" is less relevant now. Let's assume that ABAP goes the way of Cobol, or even Assembler, whereby there is a large install base that will not disappear any time soon, but there's also no one out there teaching it anymore, making the skill set more rare. The functionality of the Workbench - even all of R/3, for that matter - is not going to progress any further - SAP is done with it. I know all I need to know about it and, with my experience, I am hoping I will eventually be a very valuable commodity. Is there an increasing threat from off-shoring? I don't think so, not in the long run, as they too will be chasing the latest and greatest.
Scenario 2: Looking forward, where is SAP computing headed? Will there even be a place for custom code developers? I.e. is there anything to even re-invent to? This is a much larger question to which many other threads could be started, but in short, I am increasingly of the opinion that the sort of custom development I, and others like me, have devoted our careers to is headed for a rapid decline, if not extinction. If I may attempt to encapsulate that theory here, the entire notion of S/4 and Cloud computing in general is a response to the perception application technology is now merely perceived as overhead, offering no competitive advantage through an integrated ERP platform. This, I believe, is a testament to the success of SAP in that it has become so pervasive, it no longer represents an advantage – everybody's running it. As such, the focus moves to minimizing operating costs – get it done as cheap as possible. Want a new A/R aging (Fiori) app? Go shop for one on the SAP App Store. No different than Android, Apple, or Windows.
So, where do we go from here? In classic consultant form, I'd say "it depends".
I suppose if your planned retirement date is not too far off - somewhere in the next 8 to 10 years?, scenario 1 is all you need worry about and I think you should be okay. Re-invention is limited to the most creative means of marketing your skills, internally or externally.
What if you plan to work beyond that and scenario 2 is an increasing reality? (If you're that young, are you really grey haired??) This question is what I am struggling with at the moment. I can't ever see myself becoming a low-level commodity coder as part of a massive hive of other SAP developers somewhere building and maintaining Fiori apps. I have taken some Fiori training and I think I could build a skill set there, but that entire platform relies on pre-existing data sources. I have a friend who works in-house for a large outfit and his job is building these data sources and he says it's just a grind. I am having trouble envisioning a situation in this environment where I would ever be responsible for building an end-to-end solution, from data dictionary to gui, as I do today - that requirement simply goes away.
I can empathize with SAP's direction here. Everything is going that way. I find that many users still struggle with extrapolating the most out of what ECC has to offer. Indeed, it has been the driver for most all of that we are asked to build. Are us grey-haireds then the blacksmiths of 21st century? Relegated to seeking out those who can't wrap their heads around these new fangled automobiles and stick with the horse and buggy? If so, how long can it last? Are my predictions of the future even reasonable?
For now, I will endeavour to take advantage of the environment with my HANA customer and try to learn about Calculation Views. In the mean time, I wonder if there are any youngin's who may happen to read this that can set me straight one way or the other on where things are headed.
Your thoughts??