On February 11th, 2021, SAP acquired a No-Code Development company called AppGyver. As I work for a company that has long partnered SAP and Mendix both, you can imagine there are a lot of questions thrown my way about what this could mean. I don’t have any “inside knowledge” from either partner nor does my employer influence what I write here in my blog. I have spent some time thinking about this purchase and coming up with a lot of crazy theories, some of which I’d like to share here and record in case they end up marginally correct, or if they don’t, I can’t claim to be “Nolandamus”.
No-Code vs Low-Code
You might be reading this with no knowledge of the differences between No-Code and Low-Code so let me give you a really brief answer. Application development historically has two really high level categorizations: “Back end” and “Front end”. Back end development focuses on where the data gets stored, secured, and accessed, where Front end focuses on what the user interacts with such as the design for the interface and user workflows. There’s overlap and complexity but we speak about it in that way. No-Code development focuses on the Front End to make it really simple to build the User Interfaces and workflows but requires a separately skilled developer to handle the complexities of the backend. Low-Code developers are, well, Full Stack developers (yet another term) who use their tools to build both the Front End and the Back End of an application.
Then there is Server Admins and Cloud Architects and DBA’s and…let’s not worry about all of that. Just remember this:
No-Code focuses on Front End development
Low-Code focuses on both Front and Back end development
AppGyver is a No-Code platform; Mendix is a Low-Code platform
Now that everyone reading understands the very basic concepts behind these two types of solution classifications, you now have a basic understanding of the differences in approach between AppGyver and Mendix.
AppGyver is trying to help front end developers and people who want to learn about that to create apps using data services that are made available for their consumption. You can build the most amazing web, progressive, or native app in the world but without the backend being accessed through data services to securely pass data back and forth, you don’t have an app. More on why this is important to SAP in a moment.
Mendix is trying to help full-stack developers and people who want to learn how to create apps end to end to create both the front and back end in a faster way by abstracting complexity. A Mendix app can be fully standalone because everything it needs to run is part of the solution platform. AppGyver depends on other technology services in order to be classified as an App.
What could this mean for the future? Why would SAP buy AppGyver if they already partner with Mendix?
Let me address the second question first and then I’ll define what I think this could mean in the future. As you have read, AppGyver is targeting a different business problem than Mendix. Both can be used to create apps, but they target different developers and have different dependencies. SAP isn’t afraid to have multiple overlapping products or SOLEX partnerships. Not everyone wants to buy a stand-alone Mendix platform to build an app on their data, especially if that data is already secured and made available through services where Fiori or now AppGyver might make sense in time (the Fiori vs AppGyver post could be a juicy one…). Similarly, not all clients want to bring all data into SAP BTP (Business Technology Platform, formerly known as SAP Cloud Platform “SCP”) in order to share it to the other Extension Suite tools and a standalone, integrated app is a better solution. For example, a B2C use case that would have different users accessing the app and wouldn’t cause an increase in the SAP license. The point is that SAP sees an opportunity in a No-Code solution as a part of BTP that is separate and distinct from a full-stack low-code platform such as Mendix for the reasons I mentioned, and when you understand the BTP offerings, you can see how an AppGyver-like tool was missing.
Importantly, SAP has other application development tools that I am not addressing because this is focused on low vs no code tools and their partnerships since they will be directly compared. I’m not addressing SAP’s Business Application Studio, Fiori, iOS SDK, etc. Some of these tools overlap the capabilities of AppGyver and Mendix as well, which furthers my earlier point that SAP likes to have overlapping solutions to help client with options to “dial in” their own solutions.
Finally, this is where I start to connect dots and may end up foolish or smart in time. As a part of SAP’s rebranding of the SAP BTP, there are a number of messages and signals being put out that I am reading as follows:
AppGyver and Mendix both accelerate in adoption within SAP clients.
“Keep the core clean” is a message you will hear a lot in the SAP community, mainly coming from SAP and clients wondering how to do that. As companies move from ECC to S/4 in the cloud or the need to change how Concur works for them or dealing with a unique labor workflow in SuccessFactors, they have to figure out what to do with the decades of customizations that have slowed down their ability to apply service packs, let alone migrate their systems to a newer platform in the cloud. What risk does that keep carrying when the next innovation comes along in half that time, and half that time again for the succeeding change? Innovation doesn’t stop and if you keep customizing the core, you create massive technical debt that has to be paid eventually. Therefore, SAP has been communicating that the best option is to keep the core clean by leveraging the tools in the BTP and SOLEX partners like Mendix. Leveraging the Extension Suite and Integration Suite, clients can build those custom workflows and tap into and pull out the data from the core systems without changing those workflows or UI elements that make it unique to their business. This is a good thing for clients looking for Mendix or an AppGyver solution and makes me very bullish on these as key solutions going forward.
CPEA lowers the barrier to adopt both AppGyver and Mendix, but pricing will fluctuate wildly for early adopters
CPEA licensing allows SAP customers to adopt a cloud model similar to Amazon’s AWS as an example, where you pay based on what you use. You don’t have to buy a separate license for every tool but instead you can develop your solution under the license and then just pay for the consumption of resources. This lowers the barrier to entry to no and low-code tools. Did I mention that Mendix can be included in the CPEA?
The pricing for these tools and their consumption is incredibly difficult to pin-down. How much container room do the apps need, how many resources will be needed for scaling, what breakpoints in pricing should exist as apps scale…these are all questions that need to get figured out. Early adopters could end up getting a great deal…or they could end up heavily overpaying. This is very difficult to price and we won’t know until these tools get deployed and tracked in SAP’s BTP before we know if the price is any good. With Mendix, you can use their cloud to deploy if you don’t want to use your own, and they have a robust pricing model with a decade of experience. Watch CPEA adoption closely and the rate swings.
Mendix is years ahead in coupling with SAP apps and services
AppGyver is a long way from being an SAP tool. Much like Mendix did when they partnered, AppGyver will need to work with the SAP team to develop all of the core services as connectors, develop Fiori-like UI standards for the UI templates, and so forth. We are at least 1 year or more away from that machine being ramped up and a few years out from having the capabilities Mendix already has with SAP.
A No-Code tool makes sense in the SAP BTP offering
BTP Business Services as part of the Extension Suite, combined with the capabilities of the Integration Suite, make a no-code tool like AppGyver as part of the BTP solutions a no-brainer in my mind. SAP isn’t going to stand by and watch the market shift to low and no-code platforms without having direct skin in the game. I like this pairing a lot for internally-focused business apps and I like Mendix more for solving the same problems teams historically use full-stack development for, particularly B2C and B2B apps.
Mendix is a much more mature solution vs AppGyver
From what I have seen, Mendix is a much more mature solution in this immature marketplace of abstraction development tools than AppGyver is. That isn’t a shot at AppGyver in any way but as a developer you can clearly see the differences between the two. I think this translates into a prolonged benefit between SAP and Siemens where Mendix remains a SOLEX partner for many years to come.
SAP AppGyver stays focused on SAP-only solutions which limits it’s potential
This one is a riskier prediction but I think AppGyver stays narrowly focused on SAP’s huge library of apps and services whereas Mendix focuses on many industry solutions beyond industrial clients of Siemens. I worry that AppGyver becomes the next BusinessObjects acquisition which is a topic for another day, but read into that as you will and you’ll see what I mean.
I don’t think the AppGyver acquisition hurts Siemens Mendix at all; in fact, it tells me that SAP is serious about this space and accelerating the adoption by taking up the services model in their BTP. I’m bullish on Mendix with SAP for the next 2-3 years. I would love to hear your thoughts in the communities about what the AppGyver acquisition means in the SAP portfolio, and what it means to the SOLEX partnership with Mendix.
TL;DR
AppGyver is targeted at front end developers and will pair nicely in the SAP Extension Suite of apps and services offered through the BTP and SAP services. Mendix is focused on accelerating full-stack application development of all kinds and the buyers of Mendix are likely not cross-shopping AppGyver. Let me hear what you think!