All IT leaders face challenges of outdated technology. Sometimes it’s time to build or buy a new application. But nowadays, it might make more sense to refresh the new old one. I explore those challenges and provide real client examples where I’ve used low code to help in both cases.
I share my thoughts on the recent acquisition of AppGyver by SAP and how that does or doesn’t relate to their SOLEX partner, Mendix.
The world is battling a war on two fronts: our health is threatened by COVID-19 and our economies have slowed and even stopped in certain sectors. As an App Developer, does my work really matter in such times?
After years of delivering, leading, and coaching leaders in Rapid App Development, I give you my perspective on what skills and profile it takes to be a ‘Great’ RAD Maker.
It’s been 1 year since I first wrote the post, “Extending SAP: Fiori or Mendix?” and a lot has changed. Because of the changes, this older post has gotten a lot of renewed interest so I thought I would take a look at my opinions from a year ago and see if they differ. If you haven’t already, please refer to the original article to have context for this one.
IT should be an expert “SWAT” team with precise skills to tackle the toughest app challenges, not a bottleneck to solving business problems.
A feature that is often requested is the ability for a privileged user to impersonate another user’s account. If you aren’t familiar with that, it just means that the privileged account wants to be able to see exactly what that other user sees on the same screens when they logon. It is primarily used for support purposes to assist the impersonated account. We’ve designed this feature in different iterations but it comes with a lot of education and security risks that must be addressed.
Let’s face it: Application Security Modeling is a difficult topic. I’ve seen (and built) numerous attempts and security models using the Mendix framework, and they are rarely consistent and often misunderstood. I’m going to attempt to document my processes and procedures that I have determined to be best practices to hopefully help some developers out there struggling to find a “best practice security Mendix” search on Google. There are many ways to approach it so by no means is my approach the only way to do this, but I do know it works to ensure each element is considered in the modeling
A lot of Mendix app developers are rightfully excited when they need to implement security; Mendix provides for the common options directly in the Business Modeler and in addition, there are modules such as LDAP and SAML that can be included into an app to take advantage of SSO. But what if you need to run security in the application but need to add customizations above and beyond what is provided in the default Mendix setup? I’m going to show you a few common requests that security teams ask for and show you how to implement them in your application.
Last time in this series, I wrote about the concept of roles and ways to design roles for a Mendix application. This time I’m going to talk about implementing security in the Entity and how that compares to setting up security in the User Interface (UI).
This has come up quite a bit for me recently as I’ve been attached to multiple new Mendix projects. I get asked about roles, read/write, prototype vs production, and then the big question: How to add additional layers beyond what Mendix provides out of the box? Given the scale and scope of this topic, I’m going to break it up into a series of posts to help make all of you out there masters of security within Mendix. This first post is going to deal with Roles.
