Hacker News Reader

Comment by _glass | Hacker News Reader

I am an SAP developer since kind of forever, my first job after university (since 2009). First I hated it, but the deeper I am entrenched, the more I see why you choose SAP: Because there really is no alternative. The data model is so complex because it is growing iteratively since the 80s. Hacker News is valuing businesses that adjust to the customer instead of going for some kind of purity. Another complexity especially now is the different paradigm changes in between. ABAP, the programming language of SAP, is quite nice nowadays. CDSViews are a great invention, and so on. There's really a lot of innovation buried in the bad documentation, it's getting better. In summary as bad as it is, I don't see an alternative for all of the backoffice work. SAP is really flexible and supports a lot of different processes. A thing that makes it so costly is a lot of time culture, no small releases, MVP, and so on. But you can be agile with SAP, especially if you move to the cloud.

View on HN

Speaking of purity, the first thing Hacker News would do is try to run SAP on a Kubernetes cluster, refactor crucial bits in Rust and shard the database into sqlite3.db files on per user basis. We'd also recommend you restructure your office for a more open space, bring down the cubicles and make sure the conference rooms are glasswalled and have funny names. Bringing pets to work is mandatory.

And ironically, the end result would be worse and more complicated, but the people that worked on it would get to write a blog and put it on their CV about it, and move on elsewhere without having to live with their own decisions.

Declare victory and move on...

Way better than declaring victory and staying for sure.

:D You can run SAP in the cloud on Kubernetes: https://cap.cloud.sap/docs/guides/deployment/deploy-to-kyma

Also you can re-write everything in Rust https://blogs.sap.com/2020/07/23/learning-rust-with-cap-part...

Ah, that's my blog post :)

It's some years ago, did you succeed rewriting CAP in Rust :P Thanks for being a hipster SAP developer, and I mean it :)

Thanks! There's also Part 2 of that blog post (which doesn't involve CAP): https://blogs.sap.com/2020/08/17/learning-rust-with-cap-part...

But other than that, I haven't found time to continue with that project. But you can check out my YouTube channel for future endeavours: https://www.youtube.com/channel/UCFU7a7OMYfcpjtIpu2j47_Q

Wow, impressive CV. 1.0 at KIT! Grüße nach Karlsruhe.

Vielen Dank! :)

I'm no fan of CAP but I love your YouTube videos - greetings from another NeoVIM fan :)

Thanks a lot, always great to see viewers showing up in various places!

Greetings to a NeoVIM user from an Emacs/evil user. There are at least two users at the same company who dislike VSCode with some passion :)

Emacs and (Neo)vim users, unite!

We did!

https://github.com/NTBBloodBath/doom-nvim

https://spacevim.org/

Almost right. The conference rooms would be glasswalled and have funny names, but no one would be there because everyone is working from home.

> We'd also recommend you restructure your office for a more open space, bring down the cubicles and make sure the conference rooms are glasswalled and have funny names.

Already happening: https://apphaus.sap.com/location/heidelberg

This is so true! As the author of a (small) ERP/MRP SaaS, I am often amused when I read HN and observe the thundering herds of fashion followers — today it's Kubernetes and Rust, Postgres and sqlite have a longer lifespan, but tomorrow it's going to be something else entirely, and you necessarily need to use those :-)

I am always thinking about Vinge's "A Deepness in the Sky" and computer archeology: there is an accumulation of the code base and at some point most code will be some kind of legacy.

It is not feasible to rewrite it in the fancy language/technology du jour - huge waste of resources for things which already work fine and at the moment you are done you have to start again, since the IT-pendulum is traveling in the opposite direction.

We, as an industry are really bad at working with legacy code, but for a lot of us it may be the main task if we endure this line of work for some decades more.

I absolutely loved that aspect of the book and how it eventually affects the plot

Same here, all the hip trends of the day, and then back to the same Java, .NET and C++ that I have been touching for several decades, Boring Technology™.

Meanwhile people are spinning up profitable SaaS based on PHP and making it to the bank.

Yep. If I ever read an article/post about my competition using Kubernetes to run microservices, I'll be quite happy, because it will mean I don't have to worry about them.

I think there's a bigger issue at play that at some point I want to write on.

Small problems benefit from small tools. Large problems benefit from large tools. However, small problems grow and your bet as a small problem is that your tools will grow with you.

In practice, they usually do. If they don't, you end up extending the tool or rewriting it in a larger tool.

So, our tools start small, and small companies use small tools, and the ecosystems grow together. Then, the successful ecosystems end up the next large problem toolkit.

As you're a small ERP SaaS, you're banking on growing with your customers, I presume. And you can make an argument to start on the large tools at the cost of initial velocity, but that's your tradeoff.

I really think the innovation that needs to happen is a system that has a prescribed growth path. Retool/Excel/similar that can compile to a simple app that can adapt to more complex patterns as the need comes.

And apply to YC

And then plan fails due to insufficient foozball table count

Someone would claim to implement sap over a weekend !

> refactor crucial bits in Rust

on't forget rewriting all the scripts in Zig of course.

This is a genuine question, I don't mean to rip on you: Why is everything SAP I've used terrible? From payroll, employee/student management to industrial control systems - the UX is horrible and it seems so brittle that you're happy if you're out of there as quickly as possible. I've had to reach out to my school's IT multiple times over the years since random parts of the SAP tool they used break.

I think it's mostly the culture surrounding SAP. SAP developers are a lot of times slow to adapt to new technology. For the UI you can use react components https://sap.github.io/ui5-webcomponents-react/?path=/story/g... or you can just generate OData services from CDS Views that are then integrated into your frontend https://blogs.sap.com/2022/02/24/sap-cds-for-new-and-experie.... The problem is that a lot of people use SAP as a front end, which is wrong in my experience.

SAP can be quite innovative.

I remember SAP circa 2003. The only think that used XMLHttpRequest (AJAX aka dynamic html) was Outlook web frontend, and SAP web UI. GMail that widely popularized dynamic html did not even existed yet.

AJAX and DHTML are not synonyms: The latter predates the former and refers to interactivity via client-side scripting.

Did the WebGUI really use AJAX in 2003? IIRC the early versions still used the old standalone (AGate/WGate) ITS, not even the integrated version.

"SAP developers" can mean two different groups of people. The developers who build SAP, and the developers who build the custom stuff that clients need. The former can be quite innovative, but the situation with the latter is pretty damn grim (and I say this having worked in the industry, and my dad still works on it)

Answer from former SAP employee (may have changed in the last 15 years):

Two main reasons:

- It's actually terminal software, that's translated into a GUI from a text interface on the fly.

- The people that buy SAP never have to use SAP. Its interface is not a selling point.

> It's actually terminal software, that's translated into a GUI from a text interface on the fly

I am intrigued - you mean terminal output is actually parsed, and a GUI view is then generated from it?

E: this would certainly explain the issue of listboxes only having the currently shown items loaded (described by another commenter) - everytime you scroll, the terminal output has to be produced + parsed again

Historically, yes. It was basically like translating an ncurses (semi-GUI command line thing) into a UI. There were attempts to move away from that model, but at least when I worked for SAP, most actual deployments were still text-to-UI. It was basically a way of slapping some varnish on what was fundamentally an old-school mainframe system.

at least DIAG is relatively small on the network, probably as a result

It's the same today - S/4HANA is still accessible from the GUI and DIAG is still used. Web applications (which SAP is pushing customers towards) are freed from this, of course (they talk native http to the SAP application server).

Remember that back in the late 90s SAP had a native GUI that ran on Windows, OS/2 and Unix (Motif-based) and each had their own native controls (a native Windows listbox is implemented differently from a Motif one, for example). Developers would develop a UI in ABAP with platform-independent controls and that UI would be sent over the wire to the client as DIAG and the client would translate that into the native control and data, etc for the end user.

and experienced users can move very quickly through screens like a terminal but Fiori UI5 is the root of all evil

Agreed! SAP's GUI is generally terrible for occasional users (luckily most have now been moved to web-based applications, of varying levels of user friendliness), but in the hands of experienced back office staff it works well. Not pretty, but very functional and with shortcuts for everything.

> the issue of listboxes only having the currently shown items loaded

I challenged this design decision when Fiori was introduced and the thing is that statistically the lists are either small or huge. When they're huge, they got touched in less than 10% cases, so by not loading the whole content you save a lot.

The article says you should reserve 17% of your project budget in training. Couldn't good UX help with that?

I'm not actually sure, because I feel like most of the things people do with SAP are very repetitive. Their UIs are mind-bendingly bad, but you mostly learn to do the 3 things you have to do all of the time, and then do them over and over again. I'm not sure how much having a nicer UI would make that easier.

It's absolutely not something you just randomly explore. I think that's a more interesting question: what sort of empowerment of employees could you create if the UI wasn't so terrible?

But SAP's moat is elsewhere. You put up with its terribleness because nothing else can do what it does. Beating SAP would require you to reach that, and do something else, part of which could be a nicer UI.

No, because the training is about the core functionalities of those ERP systems, what action triggers what and so on. Training is not about how the UI works, this knowledge is gained on the job.

Every business software is at least as complex as the business process it models. That's the thing you training for.

Every detail of the business process is now explicit. Employees have to be forced to work according to actual process. You need quite a bunch training for that. Then employees will find shortcuts to make their own job a bit faster/easier, which will fuck up some cases. You need even more training for that and possibly some redesigns. And all you get from that is depression

I wish we were actually allowed to use the text interface but all we get is some halfway reasonable, halfway terrible web ui.

The UX is horrible because:

a) Engineering: Nobody will rewrite 20 year old views just to improve the UX. In many cases, nobody even dares to touch the 20 years old spaghetti code.

b) Sales: The buyer is not the user. The buyer (playing golf with a sales rep) doesn't give a damn about the actual productivity of what he is buying.

c) Management: There is a solid economical rationale in not giving a fcuk about UX. Over the years, SAP outcompeted and absorbed many competitors that were more interested in UX than golf. Golf won every single time. Nobody at the top understands or cares about UX because it does not bring more revenue, it is a cost.

Source: I am an ex SAP.

I hate how bad UX has become the standard due to management/executive negligence, and there is so little the actual users can do about it. Even small players tend to neglect UX because of the financial incentives.

I find smaller companies can have a more direct connection to their users, so the outcome is usually better UX. The disconnect from the user in enterprise software regularly results in poor UX, and the incentives to improve it just don't make their way to the people who need to hear them.

I hate it how UX is so much more important than actual funtionality. I blame Instagram, Apple and consumer apps in general for that.

I don't see why you'd split the two. Actual good functionality is UX. Lack of good functionality implies the user has a bad experience given the intended goal.

Big players tend to do the minimum, either attracting with shiny red herrings or barely doing anything at all. Both are bad UX.

From talking to actual end users though I am convinced there is no universally good UX. Someone will not understand it no matter how perfect you think it is.

Now I favor ugly but robust UX for business applications. The user doesn't have to love it, it's their job to use it. It just has to be efficient and comprehensive, not pretty

UX has onot little to do with the prettiness of a UI.

> The buyer is not the user. The buyer (playing golf with a sales rep) doesn't give a damn about the actual productivity of what he is buying

I see this trotted out a lot but are all large companies really that oblivious? Do none of the decision makers talk with the people that work for them? Surely those executives aren't so divorced from reality and common sense that they don't see a problem when people complain that things don't work or if they do, it takes an order of magnitude more time and effort?

Surely there must be some other explanation for the proliferation of these systems other than "execs dumb and bad"?

It’s not “execs dumb and bad,” it’s that execs have different priorities than you think they do, which I think is partially dandare’s point.

Executives at a large company are divorced from your reality at your level of the job.

Incidentally, that’s part of the fun of working at smaller companies, though the variance is higher there’s also the potential to work more closely with good earnest executives who also want the company to succeed.

ERP guy here

>people complain that things don't work

that's a problem and we're going to have to fix it

>it takes an order of magnitude more time and effort

that's not a problem

the fact that Jane the accounting drone has to do twice the amount of work, or has to hire an intern to help her out, or even wants to quit because the job is so awful now is not a problem

it's a rounding error in the overall cost of implementing an ERP system

a new screen with some new data to show for the exec is worth 20 Jane's and her opinions on the new system

you can't even call the new system unethical or fraudulent because 10 people other then Jane can now stop using broken excel sheets to organize their work

basically Jane is collateral damage

IT guy for ERP customer here.

This sounds about right to me. In particular, it tends to partiton the organization into (A) the people whose job it is to plug away at the ERP system (orders, invoices, tickets, etc), and (B) the people who actually do whatever it is that the company does.

Then you hope (and work to ensure) that the benefit achieved for B, by having consistent org-wide information systems to work from, is enough to cover the overheads of A and C.

> Do none of the decision makers talk with the people that work for them?

In many cases, no. In part because the people that do the operational work aren't the same people who work for the decision maker.

The simplest explanation is a mis-alignment in incentives.

Executives want to have successful projects to show to their value to an organization. But usually the board members are unable to comprehend the details of a project. So the herd mentality kicks in. The CTO will seek approval for SAP and provide Gartner magic quadrant BS to give the board a level of comfort.

Now whether SAP is the right tool, or if it inconveniences users doesn't matter a whit to the CTO. All that matters is budget and timeline. The CTO wants to be able to speak to the board and say that the project timeline was met and under budget. All else is a complete non-factor.

This.

The third point is plain old corruption, so there's no reason for anybody to be surprised that the second point is incompetence.

I am so thankful to be working in an organisation which is reshaping its delivery teams into product teams. Our users are customers and if they want a better UX, they get a better UX.

Golf is really the key here, much nicer to play a few rounds of golf with Dietmar in his Club than think too hard about ERP processes.

> Sales: The buyer is not the user. The buyer (playing golf with a sales rep) doesn't give a damn about the actual productivity of what he is buying.

This is the crux of why enterprise software sucks: the user is not the buyer.

They wrote you can be agile if you move to the cloud. Did you try that?

I jest. But that's kind of the point. SAP is terrible by the nature of the beast. It's a closed off system with specialised developers who require all sorts of expensive certifications. That doesn't make for good developers, that makes for pigeon-holed developers who don't have a lot of competition.

A terrible SAP developer with all the certifications to their name would probably still find plenty of work, because the expectations are low to begin with, as proven by SAP being held in low regard across the industry.

To me, needing expensive certifications to prove your worth (as if...) is a big red flag. I'm a developer who has 20+ years of experience, I recently worked for Apple and other Fortune top 50 companies, I went from startups to enormous companies.

Nowhere did I need certifications. And my past experience was never enough to land a job. I'd have to prove myself in every job application. That's tiresome and feels extremely unnecessary, but it requires me (and my peers) to stay sharp.

Of course, none of the above is very black and white. There are certified developers who are amazing, and there are open-source developers who keep themselves relevant who actually suck at what they do.

But I'd argue that the SAP group of developers have far more developers who aren't very good and grow complacent, oftentimes because of their certifications. That, combined with a closed-off system, bad documentation, a lack of online support, and a much smaller community, will MORE often lead to software that is of lower quality.

I think you don't see the full picture here. The developers working for SAP usually don't need any certifications. They are regular computer scientists/physicists/mathematicians etc. who write code / design systems.

There are of course the certified consultants that work for clients of SAP. I can however understand why they need certifications. It's probably impossible to configure these systems without some kind of special education in them.

And as for the quality of SAP devs.. I work for SAP and I have met many very qualified developers at the company. Far more than I anticipated before joining the company. Quite a few have been poached by Google et al but that is another topic.

I think they were talking about "front end" SAP devs that are hired to work on custom solutions by a client. Not the core devs that actually work for SAP on building the product itself.

The devs OP taled about are front end, SAPs front end is the custumizing of it for a client. Thats what non-SAP employed devs work on.

The UI isn’t just terrible, it’s hostile to the user. The rare times I am forced to interact with it I feel like I’m using software that was meant for some other purpose. I’ve worked in the industry for 25 years, I’ve never come across worse UI.

My favourite bit of the SAP UI is whenever you scroll a listbox, it goes back to the server to load the rest of the list. It only has data for the exact 5 items it's showing; the other 1 above or 3 below each need a server hit. And it forgets the data it loaded before.

It isn't use for you as a user, it is meant to run your company. You are not the user, you are the one feeding data into the system. And that is actually perfectly fine in case of ERP systems.

That's nonsense, people interacting with software are by definition users. If they pay for it we call them customers.

tldr: hard stuff is hard and not fun to work on

Why did AWS, a group probably fairly technical savy and a direct competitor to its vendor, take so long [1] to migrate from Oracle?

Why does Google, as of today, have job openings for SAP in its Rev Rec division [2], and more widely in areas touching [3] “ SAP ERP domains (e.g. Finance, Revenue/Cost Management, Billing, Materials Management, Sourcing, Procurement and/or Inventory Management)”?

Granted you could say, and I believe in one of the many google “corporate biography” books Eric Schmidt allegedly worked through this same problem: hey is an ERP a product for us? A core competency? Should we build it? [Seems HN discussed this in 2021 already, 4]

Conversely, given the wide ranging scope of random things Google has built and how naively simple accounting and something like a fixed asset ledger looks at first glance…why did they never do it? Surely not because building 7 conflicting chat tools was a priority.

My guess (as a non developer) would be it’s crazy hard to build SAP. From personal experience even QB Online has a daunting level of “backwards compatible” complexity [5] in its data scheme even coming from an accounting background. The API keeps versioning up incrementally and you’ll find gems like “XYZ local French Tax” and other accumulated baggage. As an anecdote, using arguably a knowledgeable vendor, as of a year ago it wasn’t possible to populate a full simple profit and loss statement via Fivetrans ETL tool [6], even though they did a phenomenal job in mapping out the ERD compared to anything else that existed imho [7]. CDATA let you run SQL queries, but the complexity of scripting some of the reports was much more fragile. The community even built a DBT layer [8] and given how cumbersome it was to generate even just the “Revenue” line on the P&L out of a simple non-enterprise tool like QBO, SAP seems 1000x harder.

That’s probably why everything in-market, post-sales cycle is garbage. But hey, someone in a dorm room might be working on replacing SAP right now :)

Note: this excludes versioning, which I believe Workday does every six months, which is also a bunch of work twice a year.

1. https://aws.amazon.com/blogs/aws/migration-complete-amazons-...

2. https://careers.google.com/jobs/results/142858723165905606-r...

3. https://careers.google.com/jobs/results/118792275728704198-s...

4. https://news.ycombinator.com/item?id=26706991

5.(imprecise but good starting point) https://developer.intuit.com/app/developer/qbo/docs/api/acco...

6. https://fivetran.com/docs/applications/quickbooks

7. https://docs.google.com/presentation/u/0/d/1u0dnyq5L_rcEgR2_...

8. https://fivetran.com/docs/transformations/dbt/data-models/qu...

I think ERPs are a basket case category generally. I've worked with SAP for a few years (or more accurately work hard to keep it out of scope for what I do) in my day job. I've also worked for a company providing ERP stuff for SMEs (mostly S).

Anyway SAP/ERPs aren't code for running your business. They're code for running code to run your business. Now you have all the shortcuts SAP made to get stuff out the door, and on top of that you've got all the layers of shortcuts your business has made to get things out the door too. Therefore lots of nasty difficult complexity.

And finally I've seen evidence that in SAP people treat it like the fundamental abstraction layer is the spreadsheet[1]. So like in unix everything is a file, in SAP everything is a spreadsheet. This is a nasty complicated fundamental abstraction without the natural elegance of Unix's one.

[1] Maybe it really is, maybe it isn't but that's how a large chunk of the ABAP code I've seen treats it.

I kinda feel like SAP is the ultimate in checkbox checking. If you ask every department what they need, and write it all down, then find the product that matches all the checkboxes, SAP is it.

SAP checks most of the boxes of almost all industries you need to run a modern business. Some specifc domains better than others, sure, but none are actually bad or unusable. And all tjose functions are integrated with each other. That alone is tremendous value.

> Some specifc domains better than others, sure, but none are actually bad or unusable.

I’m fairly certain most of them are bad. You don’t make an everything monster and have things be good. They’re likely at best adequate.

Some weaknesses I see with SAP compared to dedicated solutions are in logistics and warehouse management, process industries (e.g. continious chemicals production, SAP is way better for discrete products and still it works just fine for the pricess industry), aerospace MRO (SAPs aerospace and defence package is more geared towards production) and eCommerce (eCommerce as a business is not that complex).

Basically, if you are a manufacturing company SAP is easily among the best solutions out there. Added benefit of using an ERP that litterally everone else is usong as well: you have a way larger pool of people to recruit from that know the system. The less market pebetration an ERP has, the harder it is to get people who prwviously worked with it. That means higher training efforts, more need for external cobsultants and performance issues until your emoloyees adapted to whatever ERP you have.

I think part of it is the problem space to be honest. SAP basically gets used to glue all the fiddly bits of organisations together and I don't know that there is an approach to that set of problems that doesn't get tangled up in corner cases.

With a lot of the nice looking web based apps we're used to looking at, the UX and the target domain evolve together and if there isn't an elegant way of doing a particular operation then there's going to be pressure to drop that operation entirely. SAP deployments always have to do everything in the organisation so complicated corner cases either get dropped (bad) or end up with suboptimal interfaces (also not great!).

I would disagree that the UX is horrible.

It definitively is neither pretty, discoverable nor intuitive, but in the hands of experienced power users (who have spent a lot of time learning the UI), it works really well. I have seen people (who have used the system probably for > 10 years) dig the most arcane information out in seconds, navigating through about ten different views without ever touching a mouse.

It's a UI from another era, but if you take the time to learn it properly, it can be very efficient.

I would disagree with your disagreement and instead argue that the UX is indeed horrible.

SAP is very inconsistent across different views. It's not about learning a different concept, but memorizing each little detail.

On some forms you need to press <enter> to get to the next one. Sometimes it's clicking a button. Another time it's <F3>.

You can become a pro in SAP UIs, of course. But it's tedious and your knowledge applies nowhere else.

> ABAP, the programming language of SAP, is quite nice nowadays

I took a brief look at the ABAP wikipedia article and this insanity [1] stood out to me. I think after a decade of SAP you are too brain-washed to give an objective opinion anymore.

[1] https://en.wikipedia.org/wiki/ABAP#Spaces

For a regular software developer, ABAP is pure insanity. But it has powerful data manipulation procedures, it's easy to just create and manipulate all your data tables in any way you want.

Wow, that's a real landmine

Wow. That is pretty insane. I hope there is a tooling to surface a warning when it detects this.

But lots of domain specific languages have idiosyncrasies. The Apex language used to program Salesforce is a half-implemented clone of Java from a decade ago. And they didn't cherry pick the best parts.

Some companies will be forever scarred by the past trend to create an entirely new programming language for their product when an existing one could‘ve been entirely sufficient

Oh my god

>, but the deeper I am entrenched, the more I see why you choose SAP: Because there really is no alternative. The data model is so complex because it is growing iteratively since the 80s.

Yes, the scope of ERP and SAP is so immense that even other software companies that have competency in the business of programming also buy SAP licenses instead of coding their own home-grown ERP system.

E.g. Microsoft, Apple, Amazon, Google all run SAP.

Microsoft even has their own ERP software (Dynamics GP acquired from Great Plains Software) and yet they run SAP. Microsoft sells Dynamics GP to mid-tier businesses but they don't use it internally for the consolidated financial accounting of their complex multinational business.

And in an interview about Google's early days, one of the employees recommended that they install ERP system like SAP and co-founder Sergei Brin was skeptical saying "Why would they need to buy that when their programmers could just code it themselves?!?" Well, Google did eventually buy Oracle Financials ERP and then eventually switched to SAP: https://www.google.com/search?q=google+migrates+oracle+finan...

If you're a brand new YC startup, you're not going to need a complex behemoth like SAP ERP. Maybe Quickbooks or some SaaS service for accounting & HR/Payroll is all you need. However, if the business grows enough (i.e. multinational), you'd be wasting money by paying your own staff programmers to re-invent what SAP already does. Just pay the millions in SAP licenses. It's expensive but still cheaper than trying to do it yourself.

After participating in the hiring of an SAP developer I realized -- financially speaking, anyway -- that I picked the wrong thing to specialize in.

The first time we brought in someone truly experienced in SAP development, we paid him more than any other developer on staff[0]. I appreciate the different take on SAP. Can I ask -- is it still as lucrative to be an SAP developer?

[0] This was a global multi-national telecom who ran an in-house developed audio conferencing service (written entirely in C++, interacting with a lot of hardware) ... the skillset of some of our devs was incredible, which made this all the more surprising.

SAP developers aren't paid because they're more talented than other developers, they're paid because the niche in which they're deeply embedded extracts extreme business value.

It may take just as much talent to write interfaces for obscure audio hardware and deal with janky bluetooth edge cases, but that doesn't mint the same $$$$ as a SAP guru who refactors a business process to be more efficient.

Depends what you're comparing it to. Even in Germany it's a niche skill set, that has a higher payment than the average Java guy, but with enough skills you can get paid the same for any specialization, e.g. security, cloud-computing. I changed to solution architect recently, which is a bit removed from SAP work itself.

I am a project manager and a SAP user. First I hated it. And the more I used it, the more I hated it. It's like a really, really uncomfortable chair, strong, but designed with zero attention to ergonomics.

Hey, I worked for SAP for ten years and I don't agree with you. ABAP is still ugly with all its improvements, version control system and developer experience is awful. CDS views are great until they aren't, then we had this newest feature where you build apps with metadata on top of CDS views and that's where I decided that it's not a software development anymore.

I do see how Fiori launchpad is a great thing, how HANA is extremely powerful if you know what you're doing. At the same time I couldn't stand the corporate culture, QA processes and etc anymore. There're innovations and innovative teams but for the most things SAP is doing, software development is not the core competency.

Fun fact: I work with Datapath now (if you know what it is then you get an irony)

> it's getting better.

This should be the SAP tagline. I swear I've heard this since I started working with SAP in maybe 2009(?) as well - I had a brief stint as an ABAP developer.

Isn't Salesforce the alternative?

No, it's Oracle.

Salesforce is a crm not an erp, which is SAP's main offering, to the point where SAP is almost synonymous with its ERP product.

> But you can be agile with SAP, especially if you move to the cloud.

Does SAP even have ERP in the „real“ cloud?

Yes, sure https://www.sap.com/products/erp/s4hana.html It's quite nice, even though they do some crazy (also cool) stuff with it https://blogs.sap.com/2021/09/30/steampunk-is-going-all-in/

No, S4HANA is marketed as cloud. Reality is different.

How common is „three system landscape“ in cloud, like S4HANA? Elastic scaling? No. TCO footprint of an new tenant? Sigh.

There are two versions, the on-premise landscape and the cloud version. The on-premise version makes sense sometimes. You can even deploy SAP platform to cloud foundry.

Indeed, for a long time it seemed like SAP didn't "get" cloud. Having to sign long contracts and speak to an account executive to get access to their cloud platform (rebranded every few months, now "Business Technology Platform", BTP) was the way they did things. Contrast with Google, Amazon, etc.

I've not yet used S/4HANA Cloud (only the on-premise version), but it looks to me like it's just a hosted version of standard S/4HANA but with various restrictions on what you can customise etc. No real elasticity, cloud scaling, etc. SAP ERP has been multi-tenant since at least R/3 in 1992 (I never used R/2) so "Cloud ERP" smells to me like "we host it for you and call it cloud".

Yes, I am rather cynical at times.

any pointers for a good introduction to SAP developement ? I need to integrate with SAP for one of our customers

maybe this one: https://open.sap.com/courses/abap1 In general open.sap.com is the site where you can learn stuff. but depending on your customer's stack it might be different.

Reply on news.ycombinator.com