Embracing digital transformation for any organization can seem like a daunting task. If your business has been burned by technology implementations in the past, you may look on cloud technology and integration claims with skepticism. Rightfully so as analysts and trade publications frequently peddle fear mongering articles (don’t let your business get “Amazon-ed or Uber-ed”) or over hype potential benefits (“Artificial Intelligence (AI) can automate your business”).
This article outlines five (5) real challenges our clients face everyday when embracing digital transformation via the Mendix platform. By educating yourself on these challenges, you can prepare your organization to adopt processes and cloud technology to drive tangible results. So without further ado, here are five (5) challenges when adopting Mendix.
1. Understand the cost of rigidity (inability to make changes) to your organization
When considering if an investment in Mendix makes sense for your organization, you must first understand the cost of rigidity on your business. If your team has ideas of ways to streamline processes, automate repetitive tasks, or launch new digital products or services but lacks the technical wherewithal to execute you probably understand the cost of IT rigidity to your organization. These costs manifest themselves via manual processes, duplicative data entry, and administrative work.
The image below is an easy way to visualize the discrepancy between business need and IT’s ability to deliver:
Image depicting business need vs. IT's delivery capacity.
2. Embracing Agile if you are familiar with the “V-Model” or waterfall method
If your organization uses traditional software development methodologies such as the V-Model or the waterfall method, then adopting agile can be a challenge. Embracing agile if you are familiar with the V-model is challenging because business analysts will no-longer attempt to scope out the entire application (i.e. requirements gathering) before development / building begins.
For detail-oriented professionals, this seems counterintuitive. How can the development team possibly deliver the solution I am envisioning if I do not explain every detail? The answer lies in prioritization, the most critical functionality is developed first, and the test / verify iterative nature of agile development. Using these tools the team will “fail fast and cheap” while quickly refining the solution to the business experts specifications. If you have not seen this process work in practice and the subsequent results, it can be difficult to get behind.
3. Making the knowledge leap from traditional code to visual modeling
Developing with visual modeling can be a challenge for developers used to writing lines of code. As an example, a simple loop in java would look something like this:
// Java program to illustrate for loop.
public static void main(String args)
// for loop begins when x=2
// and runs till x <=4
for (int x = 2; x <= 4; x++)
System.out.println("Value of x:" + x);
The output for this statement is:
Value of x: 2
Value of x: 3
Value of x: 4
In Mendix, a similar function would look like this:
Image of a Mendix microflow executing a loop while certain conditions are met.
While this takes some familiarity to grasp, by using simple building blocks and intuitive flow / arrows an experienced business engineer can walk through the logic with a non-technical stakeholder to verify the logic is correct.
4. Shifting mindset from results in quarters to results in days:
With visual modeling what you see is what you get (WYSIWYG)! This allows changes to be made rapidly and results to be recognized by the business / user six to ten times faster than traditional development.* With security, error checking, and a built in feedback mechanism, results can be recognized in days or weeks rather than quarters or years.
If your team and users are used to traditional software development, this claim will likely be met with skepticism. Time and again business engineers are able to design, develop, and deploy, integrations new features, and entire applications in a fraction of the time taken for traditional development.
* Metric calculated by internal CapGemini studying Mendix development vs. .NET, SAP, and java.
5. Get comfortable with ambiguity - applications evolve & are rarely “finished”
When adopting an agile framework for application development and digital innovation, proper prioritization of requirements is critical. There are only 24 hours in a day, so functionality / initiatives must be prioritized. By starting with the three most critical functional points, without which the application would be inadequate, you can mitigate the development risk and improve the likelihood of project success. For example, if integration to an existing system is critical to the projects success, start here and get it right.
From here the application(s) will evolve. Once users see the potential and experience what is possible, the ideas will begin to flow into the application via feedback. Again, prioritization is key as you will not be able to get to every item but you will continually iterate towards a polished solution.