3 ms·

I work in the SAP industry as a consultant, but I hardly ever work directly with SAP. In fact, I work in a dept. whose primary purpose is to do all the non-SAP

I work in the SAP industry as a consultant, but I hardly ever work directly with SAP. In fact, I work in a dept. whose primary purpose is to do all the non-SAP work, so 99% of the time I'm working with your typical modern stack(that I get to pick myself, usually), like nodejs/graphql/typescript, etc. I do however often work adjacent to SAP or have to integrate with it, and since I've been at this for a few years now, I've gotten to try a bunch of their stuff. SAP's biggest problem is honestly just that they are absolutely terrible engineers, while they suffer from the worst Not Invented Here syndrome I've ever seen. They nearly always want to build their own thing instead of using something that already exists. Do you want to build web applications that interact with SAP systems? Well, SAP uses OData almost exclusively for all of its backend stuff, and practically no one else uses it. This means all developer tooling, like libraries and such, are almost non-existent. So what do you do? You use SAP's UI5.. which is easily the worst-made UI library out there that anyone has ever built. It's technical debt personified. No one knows UI5 except people who work in this business, so companies are forced to hire consultancies like mine, because no normal web developer has ever worked with it(nor would they want to look at it in their spare time). I can scarcely begin to imagine how many man-hours SAP has wasted on building out this gigantic turd, or how many hours they could have saved by going with, say, React, and instead building libraries and tooling around that. This sort of thing permeates everything SAP does. Everything they do is some of the worst stuff I've ever seen. But hey, it pays great money, and the company I work for has great benefits and lots of freedom. All other things equal, I don't think there are many tech companies out there that could offer me a more rewarding job. But that doesn't change the fact that observing SAP from close-up is like watching an on-going technical trainwreck that never ends.

taway19920706 4y ago
Agree 100% - NIH is a huge thing with SAP, along with very often picking the wrong horse (Silverlight anyone?). They've also built their new PaaS using Cloud Foundry, which I'm not certain about... I'm glad that someone else feels the same way I do about OData and UI5. I've used both extensively (initially to learn more about them and then because I need to develop solutions that can be supported by customers) and neither is, well, ideal. The worst is that the SAP ecosystem is a massive echo chamber, filled with fanboys saying how wonderful OData and UI5 are. Really, they're not - UI5 is open source and yet no-one uses it. Why? And let me not get started with CAP (WTF did you give a product the same name as Brewer's theorem?). There have been some attempts to extract some of the UI5 controls so that they can be used with React/Angular but I can't see those ever being adopted. I've worked with UI5 development teams that struggle with even getting the basics of Git and love using that godawful WebIDE, so I have no hope for customers being dragged away from SAP solutions to anything vaguely "industry standard". Sorry for the negativitiy, but after 20+ years of SAP paying my bills (and paying them well), I'm even more cynical than ever.
intrasight 4y ago
A big part of my recent consulting work for fortune 500 companies is to, in a sense, put a new UI on top of SAP. Not just SAP but several other big IT systems. My team maintains a large data warehouse with web and Tableau reports delivered to hundreds of business users. I don't know the internals of SAP. I really don't have to. For us, SAP is a collection of OLAP cubes that have a highly curated view of that part of the business that the SAP system manages. And there's a clean API to this data since SAP supports the XML/A SOAP interface standard to those OLAP cubes. It is a very chatty API to extract the data from the cube - but it gets the job done. It allows us to leverage all of the business logic that goes into the cube schema, and the huge investment that the business makes in SAP. I could instead run extracts of the underlying source data but that would lack all of the business logic that goes into the cube definition. I do occasionally have to use their desktop UI to better understand the cube schemas. It is like a trip down memory lane to use the SAP user interface screens. Harks back to the 90s for sure. Anyway, if anyone's interested in interfacing with SAP through a relatively clean programmatic interface, I highly recommend using the XML/A soap interface to the cubes. My client company's SAP team does a great job of building cubes that expose what is relevant to the business. The SAP data is merged with lots of other business data in our data warehouse and the business gets a modern web and Tableau reports. Problem solved.
- sakesun 4y ago
  One-way UI ?

taway19920706 4y ago

Agree 100% - NIH is a huge thing with SAP, along with very often picking the wrong horse (Silverlight anyone?). They've also built their new PaaS using Cloud Foundry, which I'm not certain about... I'm glad that someone else feels the same way I do about OData and UI5. I've used both extensively (initially to learn more about them and then because I need to develop solutions that can be supported by customers) and neither is, well, ideal. The worst is that the SAP ecosystem is a massive echo chamber, filled with fanboys saying how wonderful OData and UI5 are. Really, they're not - UI5 is open source and yet no-one uses it. Why? And let me not get started with CAP (WTF did you give a product the same name as Brewer's theorem?). There have been some attempts to extract some of the UI5 controls so that they can be used with React/Angular but I can't see those ever being adopted. I've worked with UI5 development teams that struggle with even getting the basics of Git and love using that godawful WebIDE, so I have no hope for customers being dragged away from SAP solutions to anything vaguely "industry standard". Sorry for the negativitiy, but after 20+ years of SAP paying my bills (and paying them well), I'm even more cynical than ever.

intrasight 4y ago

A big part of my recent consulting work for fortune 500 companies is to, in a sense, put a new UI on top of SAP. Not just SAP but several other big IT systems. My team maintains a large data warehouse with web and Tableau reports delivered to hundreds of business users. I don't know the internals of SAP. I really don't have to. For us, SAP is a collection of OLAP cubes that have a highly curated view of that part of the business that the SAP system manages. And there's a clean API to this data since SAP supports the XML/A SOAP interface standard to those OLAP cubes. It is a very chatty API to extract the data from the cube - but it gets the job done. It allows us to leverage all of the business logic that goes into the cube schema, and the huge investment that the business makes in SAP. I could instead run extracts of the underlying source data but that would lack all of the business logic that goes into the cube definition. I do occasionally have to use their desktop UI to better understand the cube schemas. It is like a trip down memory lane to use the SAP user interface screens. Harks back to the 90s for sure. Anyway, if anyone's interested in interfacing with SAP through a relatively clean programmatic interface, I highly recommend using the XML/A soap interface to the cubes. My client company's SAP team does a great job of building cubes that expose what is relevant to the business. The SAP data is merged with lots of other business data in our data warehouse and the business gets a modern web and Tableau reports. Problem solved.

sakesun 4y ago
One-way UI ?