EPI-USE (my employer) has a long history with SAP and it is what we are most known for. We do a lot of other stuff as well but the core to our practice has been global Payroll and HR experience leveraging SAP. Along the way we created a successful Rapid App Dev practice that leverages Mendix, and along that path SAP and Mendix joined together in a partnership, cementing what we had discovered earlier that Mendix makes app development easier. This created the opportunity for Mendix R&D to build out tools that we no longer had to, such as OData connectors, XSUAA SSO configurations, and so forth. When it comes to using Mendix and SAP together, we’ve got a lot of experience. As Sapphire 2019 is about to kick off, I thought I would share a few strategies to help SAP shops that are already or considering adopting the Mendix platform to help transition your teams from solving everything with ABAP, UI5, and Fiori to leveraging the Mendix platform.
There are three key personas to consider when training up resources to use Mendix at an SAP shop: ABAP/Fiori developers, Business Analyst/Citizen Developers, and Project Managers (SCRUM Masters).
ABAP/Fiori developers - These folks are typically skeptics of the platform out of the gate. They are highly skilled developers that already know how to solve business problems by creating and leveraging Z-tables, writing transaction scripts, and tracing through the legacy of transaction code that has been built up on their ECC or converted S/4 systems. They don’t need to be taught object-oriented programming (though a refresher doesn’t hurt), but they do need to understand how the Mendix Studio Pro (desktop IDE) works and most importantly, how to connect to their SAP services, be it OData or API’s/RFC’s. They could breeze through the online RAD training that Mendix offers to familiarize themselves with the IDE, but they will need some advanced instruction/consulting when it comes to integrations.
Business Analyst/Citizen Developers - These Subject Matter Experts (SME’s) now have a tool to directly get involved in the creation of applications with Mendix Studio (Web Modeler). They need to be taught how to use the tool as well as some basic programming skills to get off the ground, and governance needs to be setup to manage responsibilities and expectations. The online training is adequate to get started but I would argue not ideal for this group in it’s current form. If you want them to be enabled to kick-start development of apps that replace spreadsheets and Access db “Shadow IT” with Mendix apps, they need more in-person instruction and an extended focus on developing those skills to be of use on project teams. a 3-5 day course is likely not enough if the goal is to leverage their talents to work on app development. If they develop a great prototype, IT can take it over to properly secure and stage the app for enterprise use all within the Mendix tools and RAD lifecycle.
Project Manager/SCRUM Master - If you already follow AGILE principles, then adopting Mendix for RAD will be a smooth transition. You can leverage the Mendix tools for managing the Sprints, Feedback, Documentation, etc, or you can leverage your investments in JIRA. But most SAP shops I encounter typically are new to SCRUM (or a version of AGILE based project management) or they are entrenched with Design Thinking and the SAP Methodology. That’s OK as well, but I don’t recommend that approach over SCRUM with RAD because of the inherently iterative nature of the app dev (Dev Ops) process. You will need to get these folks some training on how to manage the challenges that are inherent with SCRUM projects and understand how to overcome those hurdles. A third-party certification program (for example, the Scrum Alliance) could be in order to help manage the change, or observation of the process on a project or two by an experienced Mendix project based Scrum Master could be ways to get them the training needed. (Quick aside, as consultants we will often run a Blueprint or Design Thinking session before kicking off a Mendix project. The projects may be T&E but we need to establish where we are going and if we have the right team and tools needed to get there. You can’t iterate your way to the peak of Mt. Everest, but you will need to adapt along the way!)
This one can be approached in a couple of ways but here is what I have found to work best when determining a good “first app” to build with Mendix:
Requires SAP integration - This is absolutely critical. Most ABAP developers think of Mendix as a UI tool. They believe all logic should be created in SAP and Mendix should be used as the UI layer on top of the logic layer. They think this way because it is what they know and understand. And so for the first project, I don’t fight this and neither should you. Mendix is not “just a UI”. I know that, but they don’t know that yet. So for your first project, scope it out accordingly. Extend a transaction that SAP does in a new way with Mendix. At one client, they needed to move costs from Parked to Posted status. SAP has a transaction to do it. But the customer needed to go through lots of approvals to execute that transaction and that workflow wasn’t written as code yet. We used Mendix to do the approval workflow and simply exposed the RFC as a RESTful service to authorize the transaction to move to Posted after the appropriate workflow. It was a great first project. Another project we are working on exposes a series of data as OData that are leveraged to give the user a new experience and gives them all the data they need to execute a workflow. We didn’t rebuild the workflow and even built a needed summary of the data in HANA (performance!) and use Mendix primarily as a UI layer. But what this builds is understanding on how to hook up Mendix apps with SAP transactions. That foundation needs to be understood before you start scoping out a litany of Mendix apps.
Fiori templated - If the SAP shop leverages Fiori and the Launchpad, you should look to launch the Mendix app as a tile on the Launchpad and utilize the Fiori UI Template in the Mendix app store. This will allow you to build apps that look and feel like Fiori apps without rocking the boat out of the gate. Prove the efficiency and then move on to new style guides. If you come out of the gate with radical UI (because you can), you will pigeonhole the mindset of your enterprise to think Mendix is only to be used to solve customer facing apps, highly stylized apps, and so on. Mendix definitely excels on that end, but don’t make it a one trick pony. It can also build great looking “Fiori-style” apps that are seamless to the business users as well.
SSO - If you purchase SAP Cloud Platform Rapid Application Development by Mendix through SAP channels, you get a lot of goodies. You can deploy directly to your SAP Cloud (they make it easy with the config and needed tools), leverage the XSUAA connector to easily communicate the authorizations among the other SAP tools, etc. So if you go that route, make sure you create an app that leverages the SSO. If you purchase through a partner or directly with Mendix, you’ll have the Mendix Cloud included or potentially on-premise/private cloud options for deployment as well (AWS, Azure, Red Hat, etc.) In order to hook up your SSO with Mendix, you’ll have to leverage SAML or OAuth and work with your IDP, Gateway, and so one to securely Authenticate and Authorize resources. It’s a bit more complex if you go the non-SAP Cloud route but completely a solid and secure solution. Be sure to add this element to one of, if not the first, projects you scope. However you develop it, save the module to your personal App Store in Mendix so your company can leverage it time and time again (no more development for every app!).
Third-party integration - This is where in my opinion Mendix truly shines over competitors, even Fiori as proven time and time again. I’ve said this in earlier blogs where I compared Mendix with Fiori directly, but I can’t emphasize enough that if the data you want to work with is already in SAP, there’s a good chance you should just build it with Fiori if you have the resources that understand the transactions and have the skills. As soon as you want to introduce a new source system, be it a web app, a flat-file, a data service…Mendix becomes the more attractive option. I could break down time to implement, cost savings, iterations, security conformance…there are a host of reason, but as a guide, try to include some form of third party integration so the teams and users can see just how easy it is to work with. Even a simple email config to alert people to status changes or system log issues is a simple and straightforward process.
Mobility/Responsive design - If you can scope a project that has some mobile element to it, you’ll be pleased with the results. Mendix has two approaches now to mobile development: The first is Hybrid Mobile and the second is Native Mobile. I’ll be dedicating a blog to this in the near future. Both have pros and cons, but both also make deploying apps to the app stores (iOS and Google) incredibly simple when compared to the other platforms. There is a lot of bang for you buck with Mendix and this is an area where they really shine in an SAP shop
I tried to share some observations and strategies that have needed to be addressed when kicking off Mendix projects at SAP shops. It’s by no means an exhaustive list but should give the aspiring or recent adopter some areas to focus on to help with the change management. Your first app also doesn’t have to have all of these, just a smattering will do. As these skills are learned and enhanced, you’ll start to see what projects make more sense to use Mendix or which make more sense with Fiori. And if you need some help or advice along the way, you know how to reach me! ;)