ABAP - The Special Snowflake

[NigelJames180]

ABAP - The Special Snowflake

The other day I poked the bear. Bears for the most part are things that should be left to their own devices as my Canadian friends will attest.

The bear in this case was Dennis Howlett who has been a long time friend in the enterprisey space
I met back as part of the media and influencers team at Sapphire and Teched events around 2006.

Dennis was asking about the new ESME as part of a conversation about Diversity amoungst the SAP Mentors. (That is a blog for another day)

And where is the next #ESME team coming from?

— (((Den Howlett))) (@dahowlett) June 21, 2018

I replied:

#abapgit is the biggest non sap led thing happening in SAP

Cc @LarsHvam

— Nigel James (@njames) June 23, 2018

Now for background #ESME was a Enterprise Social Media Experiment that happened around 2006-7ish and could have been something cool. It became an apache project which was qudos to the people driving it https://esme.apache.org/.

So Den was asking about what the new cool edgy thing was around SAP these days. As I said in my tweet above it is my opinion that that is #AbapGit with a whole lot of whitespace until second.

Then (which is what I was hoping would happen ) Den looked into #AbapGit and dropped the following:

Earlier today I took a look at #abapgit. It is seriously good stuff. The tragedy is that VERY few @SAPMentors or others are committers in the context of the #SAP ecosystem. Shout out to @grahamrobbo for waving the flag as vigorously as possible. cc @njames for poking me on this.

— (((Den Howlett))) (@dahowlett) June 28, 2018

The conversation that followed continued on for days across timezones picking up a whole lot of other voices and opinions on the way through.

My attempt with this blog is to try and bring some of those opinions into one place and simulate the conversation further as to what sort of innovation we are looking for around the SAP technology space. And if you are short on time here is the tl;dr:

1. ABAP has legacy tools


2. ABAP has legacy culture


3. It is stuck there and will never ever move


4. ABAPGit is the best thing that happened to the ABAP ecosystem since ABAPUnit


5. Adoption of both of these toolsets are woefully low (Please see point 2.)


6. These are exactly the tools that we need to create CI/CD platforms for SAP landscapes.

There. If you want to skip to the next blog... go for it but first identify what culture is happening amongst your ABAPers or your offshore team.

If you want to enjoy the rest of the story then fasten your seat belts, return your tray table to the upright position and hold on.

#Disclaimer

Let me provide a disclaimer for those that love ABAP to a fault ( Hi c436ae948d684935a91fce8b976e5aa7, Hi jelena.perfiljeva2 ). Yes, ABAP is awesome and yes is does power half the planet if you believe SAP's marketing department but being great is not enough - all languages need to improve and get better.

Am you saying that ABAP is not doing this? I mean that is a pretty provocative, click-baity title you put on this blog there Nigel.

Yes it is provocative and no - ABAP is innovating ( Hi horst.keller ) There are incredibly talentent people inside and outside SAP pushing to improve the language, toolset and culture to become the best that is can be and when they are finished they will go some more.

The problem is that good ol' ABAP is for all intents closed source prorietory language. My other two favourite languages that include the letter P ( Python and PHP ) are not. They have continually innovated around their core. Just the other day I saw Zeev Suraski one of the co-architects of PHP saying that the next release of PHP would be 4-5 times faster than version 7. This is not bad given that version 7 was twice as fast as version 5.x that preceeded it.

What languages carry with them - more than anything else is legacy baggage. PHP certainly does - and routinely get bagged for it but many companies including Facebook, Slack, and Mailchimp have PHP at the heart of their business and serve many millions of customers. Enterprisey enought for you? ABAP, coming from its FORTRAN and COBOL roots has a very verbose nature and weird keywords. That's why we "love" it right? Many improvements over the years have been welcome and the code we write in ABAP today is not the code we wrote 20 years ago.

What they also bring is toolsets, "tecosystems" ( Thanks @sogrady ) and a culture that grows up around them.

#ABAPGit can shift the ABAP CI landscape

My thesis in this twitter thread that developed was that #ABAPGit could bring new ways of deploying code to the ABAP Ecosystem just as #UI5 has brought innovation to the Front End and HANA has brought innovation to the database.

Mindsets like 'caching' tables to hold monthly summarys that are no longer needed in S4/HANA. If they can innovate around the DB and drop tables why not around CI/CD and ditch STMS? @BoobBoo - your turn to pitch in 🙂

— Nigel James (@njames) June 28, 2018

Other believe the culture needs to come first:

Just quickly chime in here and posit that tooling is not the biggest reason #sap customers don’t deploy multiple times a day. Tooling certainly helps - but the “enterprise” mindset that has formed over 30+ years is really hard to break down

— Graham Robinson (@grahamrobbo) June 28, 2018

Graham is right though. Enterprise mindset is hard to break down.

In other development enviroments the deploy to prod as often as required is commonplace. When I gave a talk about learning #git back at #SAPTeched in 2015 I had a guy from Github in the audience. Thankfully he identifed himself after the talk and told me how they deploy regularly with the record from issue being opened to fix in production being "2 minutes"* (Actual time may vary - but rest assured it was not 6 months)

I have since heard similar stories at Amazon, Facebook, Netflix. Why does the enterprise (read ABAP based platforms ) have to be different?

The toolsets are available

Chris Paine nailed it early on:

The combo of abap unit test, a branch based repo and then bringing in tools to manage automatic migration and testing could have the possibility to pull ABAP based development into the 21st century. But why hammer the round peg into square hole?

— Chris Paine (@wombling) June 28, 2018

And there you have it:

1. Unit Testing


2. Decentralised Branch Based Repository


3. Automatic Migration


4. Branch based deployment

People like @grmpyprogrammer, Chris Hartjes, have been preaching Unit Testing to the PHP Community for years, probably 18 years. The toolsets and workflow are well established and while it has taken people like Chris years and years of banging the drum the message has gotten through.

ABAP Unit has been with us for at least a decade but how many of us unit test our ABAP code? How many of the 'offshore' code factories include ABAP Unit tests as part of their deliverable?

Where is the ABAP Unit culture? Happily there are more voices promoting unit testing recently.

Even in the Java world JUnit and friends have made testing common. Which is why Chris Paine is happy developing extensions in the cloudy world:

Rather than rebuilding the wheel to fit the juggernaut, keep the juggernaut running as standard as possible and apply enhancements outside of it. This is #SaaS enhanced with #PaaS

— Chris Paine (@wombling) June 28, 2018

But to do this he is using unit testing, branched based source control and automatic deployment mechanism. ( Chris may want to chime in and correct me here I dont actually know his workflow I am assuming it based on his tweets. )

Ethan Jewett had some really great comments to add - he joined in with:

No, really not. It’s a PITA, but every other platform in the world handles platform version changes and branches at the same time. Once you have code decoupled from the runtime, then developing and testing on a new patch level is easy peasy.

— Ethan Jewett (@esjewett) July 2, 2018

And unsurprisingly (as Ethan always has great things to say) there is another thread on modern ABAP practices starting here (from 2016) :

Great article by @esjewett
Implementing modern practices in an ABAP development shop https://t.co/1pAkgvc9vb
cc @ABAPCodeRetreat @majcon

— Christian Drumm ?? (@ceedee666) December 30, 2016

and again as Matt Harding pointed out that this conversation has been going on for quite some time pointing back to a tweet from Chris Kernaghan from 2014.

.@njames Being going on for longer than a few days! https://t.co/7YrlRRLV24

— Matt Harding (@mattharding) July 2, 2018

And the kicker which really sums up the ABAP Culture is this:

I have to agree with @BoobBoo. The level to which many ABAPers are convinced that what they are doing is a special snowflake is astounding. Way beyond what I see on other platforms. I think SAP has to take some of the credit for that culture.

— Ethan Jewett (@esjewett) June 29, 2018

Personally - I have never wanted to stay with my own set of tools. I am not an ABAPer. I solve problems that can (sometimes) be solved with a computer program and I am happy to say that over the years I have contributed to many sucessful implementations just as I have contributed to things that have never seen the light of production.

About four years ago I took on a client who was the farthest from SAP as anyone could imagine. They were a content platform startup. Small team using PHP and a little framework called Laravel. Thankfully they didn't let me at the code. I did a more robust data replication proof of concept for them. While I was there I learned a lot about how this team used:

1. Unit Testing


2. Decentralised Branch Based Repository


3. Automatic Migration


4. Branch based deployment

Sound familiar? Every other team and platform does this. Ethan is right. ABAP is a Special Snowflake.

So here is the cultural challenge to all those who are die hard ABAPers. You need to embrace the new tools and new ways of doing things.

I hope this has raised a thought and sparked more conversation.

Let's not be doing something because it is Not Invented Here.

I will leave you with the Knights who say NIH

[and yes I wrote this blog in markdown using Sublime Text 3 and used github to version control it ]

 

Update - 4 July: Dennis has added his thoughts to this conversation and the comments are worth a read.

Update - 6 July: This post caught Hasso's attention and is asking for feedback about what is really needed:

imo scp offers all or most modern code management and deployment options of the cloud world. many of the abap improvements will show up first in the cloud, only there sap can make more radical and incompatible changes because of the separation of standard code and extensions.
- hasso

[UweFetzer_se38]

Hi Jelena,

starting with Unit Tests isn't that hard if you implement new functions.

Here's how I'm doing it (your real world example, but not TDD). I'm using constructor injection, because this possible in all releases:

Create three classes

• the class with the needed function


• the class with all DB accesses (and external dependences like function module calls)


• the mocking class / test double

That's it, no magic.

If you have to extend existing code, I'm always telling the devs to create an "Island of happines" -> do all the new functions in your own class, test them and call this functions from the existing code.

(but I think we are in the wrong thread here to discuss this)

[mmcisme1]

When I do - it will be jumping head first.  So I'm very happy to have some nice water.

[mmcisme1]

So I get to say it again...

I see a very nice blog that you could write up.   It helps the doubters like Jelena and myself.   Plus it adds a nice story.   This is the old code.  This is the change to that code.  This is the "island of happiness" after/during the change.

[UweFetzer_se38]

Stay tuned, give me an hour or so....

[UweFetzer_se38]

Here you are: ABAP Unit Tests: real world example for Jelena and Michelle

[miguel_peredozurcher]

For me the best thing about the ABAP platform is the transport system. Do not forget about it in any conversation or plans 😉

 

[NigelJames180]

Hey miguel.peredozurcher

Thanks for chipping in. Perhaps you can detail the strengths in a blog of your own.

For me I am regularly frustrated by locks on an object which are not released until a transport reaches production.

But perhaps I am just "holding it wrong" I would love nothing more that someone to show me how I can have multiple streams of development and production hot-fixes.

A branch based code repository makes this easy.

 

Cheers,

Nigel

[Jelena_Perfiljeva]

AFAIK lock is released as soon as the transport is released. Why are you saying the objects are not released until a transport is in PRD? Is this some CHARM thing? Or a company policy?

[Jelena_Perfiljeva]

Completely agree with you. ABAP is simply not like other languages. It does some things better, some things worse. Just like any other language. So yes, ABAP is a snowflake but not in the negative meaning which this word seems to have acquired lately, e.g. when referring to the annoying entitled Millennials on Twitter.

 

[Jelena_Perfiljeva]

Thought this Reddit post is rather relevant here: JavaScript is getting real tired of your jokes 🙂

 

[DouglasCezar]

One of the most interesting conversations I've read on the SAP Community so far. Congratulations to all of you who comment here and wherever else this conversation has been taking place on the last few days. I spent a fair time now reading and pondering how this reflects on our future as technologists in the SAP world.

After eight years working as an ABAP and Workflow developer, I began to explore SAP Screen Personas and a little bit later I did the same with SAPUI5. These two things opened my eyes on how to add new valuable tools to my skillset.

If you are an ABAP developer it is definitely not easy to learn SAP UI5 and everything that comes with it. I like to say that it is almost as hard as learning to speak German if you only speak Portuguese (or vice-versa). It certainly makes lots of people to avoid or stop the (huge) learning effort that is needed.

My opinion on the "cultural legacy" is that people are afraid of change because change usually means a lot of additional (and often unpaid) effort. Once you are OK with the idea that you are an expert on something (ABAP) and a complete novice in another thing (let's say UI5), it will not be hard to put the effort and, in a few weeks, you will have something new and extremely worthwhile.

For an ABAP developer trying to go out of the "special snowflake" mindset, I strongly suggest giving a try to SAP Screen Personas before going to SAPUI5. It is because it is a powerful tool to do an extreme make-over on the SAP UX while you can use both ABAP and JavaScript to achieve more powerful and complex things (making everything more simple for the end-users). SAP is clear that Screen Personas is evolving (it has a team on SAP Labs Palo Alto) and it is extremely valuable to both ECC and S/4HANA customers.

[NigelJames180]

It may be a charm thing - or may be policy.

In either case it is hard to do a hot fix on prod if you have already moved dev forward. This usually means a two stream landscape which is effectively "the branch". one of the other alternatives is winding dev back.

Maybe because of the culture and knowing how the tools work this may not happen often.  Now working in a UI5 environment when you can branch to start the new feature without interrupting testing I struggle when my ABAP colleagues say they wont start a new feature because we need to ensure that the previous piece is promoted past UAT.

[joachimrees1]

Nice read, thanks for starting this discussion (an special thanks for bringing it here to SAP Community!)

One thought on:

Even in the Java world JUnit and friends have made testing common.

To my understanding, JUnit was what unit testing started with, so I can’t understand the astonishment I think i read out of this sentence ("Even in the Java Word") !?

best
Joachim

 

[joachimrees1]

There is a though I just recently had:

It would be nice if I could have a clean, “use once, then throw-away” SAP instance (probably from the Cloud).

 

I'd say I need like SAP_BASIS 7.50 + SAP_APPL 618.

order.  (probabaly wait a littel time 'til it's there).

I'd the install my AddOn to it, and let a few eCatts run.

-> Get/Save the protocolls and throw away the system.

 

(Next day/week/?, when I improved my AddOn , I'll do it again).

 

I can imagine this is technically possible (why shouldn't it be?), but I'm not sure if someone is actually offering such a thing.

[NigelJames180]

Haha - yes you are right. Most xUnits are based on Junit as it kicked this all off.

The (fake) incredulity comes from trying to point out that ABAP is not the center of the universe around which everything else rotates.

"What they do this in java too? Maybe I should add this to my ABAP"

Thanks for your comment.

cheers,

Nigel

[joao_sousa2]

A competitor in the cloud space that SAP declared recently as a "nemesis" is doing it. Can't SAP do it too? 😉

Surely they can 🙂

[joao_sousa2]

 

As someone who works for a major consultancy at the management level, I can say I disagree with that we are fighting against it.

It is true that customers are not willing to pay for quality work, and that’s the main issue. Customers need to be demanding, they need to either pay more for quality work, or stop hiring cheap workers who do lousy work.

When you have the customer fighting to save every single hour of development, you just can’t afford to do things the right way. I recently had a customer questioning 80 hours of development, when you had to use these 80 hours to:

• Do workshop to get the requirements;


• Create the functional specification;


• Develop the solution, which involves ABAP, BRF, two systems (S4 and CRM) and SOAP Interfaces;


• Run unit, integration and acceptance testing (twice);


• Deploy to production.

6 hours alone were spent in workshops, because people talk about everything except the topic at hand for most of the time.

This is the problem. Not wanting to pay the time it takes to properly develop, even though the extra time will save tons of money in the long run.

It’s against our best interest to write troublesome code. Best case it harms our corporate image, but mostly likely will hurt us financially too. The race to the bottom doesn't help anyone except the guy at procurement.

[joao_sousa2]

And here you go, my success story. ?

c436ae948d684935a91fce8b976e5aa7 and jelena.perfiljeva2

 

[Patrick_vN]

Hard is relative I'd say. There are different ways to deal with maintaining productive applications, at the same time as developing new features for the same applications. At the same time, it depends of course on what it is that has to be done.

But I can see the fun when you're working with several developers on a project and they all start branching out 🙂

Some examples I've encountered in the past:

• Separate environments for maintenace & new developments (though the retrofix part isn't fun)


• A separate version of (a part of) the application (ex. via enheritence)


• 'Hide' new functionalities behind a flag (might require some level of refactoring after)


• Use the ABAP versioning

But I guess in the end a lot depends on the willingness to find a way to do something. Often we're tempted to use the easy 'why not' excuses.

[Patrick_vN]

All that is true. But then there are also tools like custom code management, where one can actually see an inventory of the custom objects you have.. and use. And during a dbase migration to SAP HANA, all the legacy code needs to be reviewed and modified. An excellent time to clean house (and dump the code you wish to keep in case of in a separate package > nugget (or abapGit).

Also, if you consider the cloud solutions, then I presume that in the future, business processes will aligned with SAP, and not the other way around.

[mmcisme1]

Oh - I agree so much with this response.   It's sad but normal.  Workshop's to get the requirements.  I do get a GENERAL idea from them.

Then I am expected to make up the rest.  HA!  That's doesn't happen.   So it takes more time bothering them at different points to get the answer.

Oops - I just gave a reason for unit tests.

Michelle

 

[mmcisme1]

And that is the problem.  How do you get them to support it?   My challenge to everyone and Jelena's challenge was to give an example in a blog.

Could you do that?  I've seen some really good ones and would love to see more.  I'm sure there are more.  I just am struggling to keep up with the community lately.

Michelle

ABAP Unit tests - Freedom!

ABAP Unit Tests a real world example for Jelena and Michelle and everyone - really

[mmcisme1]

All of it was looked at and considered.

Did we look at the on-cloud version? Yes.

"Also, if you consider the cloud solutions, then I presume that in the future, business processes will aligned with SAP, and not the other way around."

And that was one of the many reason on-premise looked so inviting.  SAP does not and can never duplicate all business processes.  All the little ways that makes your business run smoother and more efficient.  Why? Because every business is different.  In general you can say, yes it meets our needs 80/20 with configuration.  But it is that 20% that helps save processing time.  That means money, it could mean a lot of money.

So you say - no big deal have SAP program it.  For how much money?  A lot more expensive than the 3 programmers we have.  (Smallish company)

On no - I didn't want to debate on-premise and in the cloud.  They both have great benefits and you really should look at both.

So yes, we drug (dragged) the code with us that made sense.  Oh by the way - each module you add is more money.  And perhaps you only use 5% of it.  Custom code was the way to go.

Michelle

[mmcisme1]

Thank you!  Loved the blog.

[mmcisme1]

SO now I know my problem.  I couldn't possibly find the right language as there wasn't one.

[mmcisme1]

Sigh.  Sometimes you have to jump head first into the water.  Learning new things in advanced is very helpful.  I had a free class in  opensap.com.   It was very good.  It was on the S/4 Hana Migration toolset.   It was very good.  AND it helped a lot.   If I hadn't taken it earlier I would have been lost.

So my advice, try some of the free courses when you can.  Get the basics in case you need them.  If you don't not a problem, you still learned something new.

Michelle

[Patrick_vN]

I agree(d) completely c436ae948d684935a91fce8b976e5aa7

But then there is the SAP SuccessFactors story, where I see more than a few of our customers move towards cloud-based solutions. And if it can work in that domain,.. etc.

[mmcisme1]

Smile.  There are pros and cons on both sides.  No one straight path to take. 😉

 

[Patrick_vN]

I just makes me wonder about the future of the "ABAP Developer". Or let me rephrase that: it makes me wonder what the required/preferred/ideal skill set of that developer would be.

[mmcisme1]

Very true.  It's always a good idea to update your skills.  And if everyone is flocking to the cloud.  (really?) then you would have to update them or work for SAP.   However, I'm going back to last Teched - they say ABAP is still a usable language on the cloud.

Companies have invested heavily just to get us all up to speed on ABAP.  It's not something they want to completely lose.

When I get some time, I have the advantage of sitting with some consultants to learn new things.  OK and I'm jumping head first into others.   Someday I'll write a blog.  Someday...

Great conversation in this one!

[noboruota]

nigel.james

This is a great blog! Thank you.

It reminded me of one of the (perhaps) ealiest documented and publicly available account of an agile ABAP development project back from 2007 based on NW 2004s: http://xunitpatterns.com/~gerard/agile2007-erp-paper.pdf

It is refreshing to read this first-hand account of struggles against the "ABAPer culture" that you blog and discussions capture well.

One of the biggest and highest impact surprises we
encountered early in the project was that ABAP
development in SAP is server based. Developers run
the SAP GUI on their own PCs but all the ABAP code
is stored and executed on the development server.

Perhaps there is something the community could learn from their experience and how they overcame (partially) some of the cultural and technical hurdles.

In the end they had this to say:

Assuming one has decided to do the custom
development in ABAP, is it worth doing it in Agile?
We would answer with a resounding YES!
Implementing agile development of an application in a
server-based ERP system definitely has some
challenges but it can be done and the benefits of
increased business involvement, buy-in and
satisfaction are huge.

[Former Member]

Very interesting discussion! I'm a little bit late to the party, but still want to add some information.

Since last year in July several SAP customers joined forces and are discussing DevOps methods / practices in ABAP landscapes in a dedicated DSAG (german speaking sap user group) working group. At the beginning it was mostly a self-help group to discuss the issues and pains, but also the success of the specific companies in several areas. Over time the group got bigger and now includes SAP employees and ababGit contributors as well.

We created an overview for the DSAG Tech Days in February 2018, which you can find here: https://t.co/sxfAKNnRRh.

At the moment we are discussing how to spread our insights in more detail. A SAP Community post will probably follow soon! 😉

The next meetups are planned for August (knowledge exchange with SAP IT) and September (ababGit), stay tuned.

Cheers,
Sascha

[joachimrees1]

If you want to read a lot of words about how I wrote 1 (or two) unit tests (covering real code!) you can do that now; https://blogs.sap.com/2018/07/25/my-experience-with-real-world-unit-testing-abap-unit/

[Jelena_Perfiljeva]

I think we may need to start a Wiki page or something to keep track of all this stuff. 🙂

 

[joachimrees1]

I think we may need to start a Wiki page

Wait, there's a Tag for that! 🙂

But I agree: if everyone uses her own choice, it doesn’t help so much!
(Maybe that Wiki page could list the user-tags? 😉  )

I went for using user-tag https://blogs.sap.com/tag/unit-testing/  (within primary tag ABAP Development, so it should (some day) be possible to filter out Non-ABAP-Unit-Test-Blogs! )

[Jelena_Perfiljeva]

I'd be very interested in your work and can help with PR. Please get in touch with me - email is in the profile.

Thank you!

 

[rolf_paulsen]

You nail it down to the point. It is not the language, it is the integrated platform that is a too large impediment for really effective usage of TDD, CI/CD, and non-linear development processes. Whoever read the famous books Clean Code and The Clean Coder knows that TDD plays out its strength together with iterative development and refactoring. Who wants to learn the “language” TDD should visit the “native speakers” in (mostly) Java and not expect to really learn in the “basic school” ABAP platform. Refactoring is just not supported on the ABAP platform so one of the most important tools is not available.

“The toolset is available” – if we look at the support on other platforms we get a realistic impression about the level reached. This level is low.

The ABAP platform (not the language) is more than a decade behind. Because there is no real market driving such an enormous transformation to get the code out of the platform and to break up the monolith and because few young developers will invest their best years into this platform, it will not catch up to other platforms, but the distance is increasing - e.g. look at Docker etc. - and will keep increasing in the future.

The ABAP platform and runtime is designed for small extensions, it is not competitive and future proof for large development projects in the long run

[former_member578824]

"So if there are 200,000 companies with SAP development departments, that means that 200,000 different custom Z logging frameworks have been developed, all wrapping the standard BAL function modules in some way. In fact there may be more, with different developers in the same company creating their own Z logging frameworks."

Spot on!

Having got stuck into Node more recently (and loving it) I'd love to see NPM for ABAP (APM).