The 7 Keys to Deliver Better Applications Faster through Effective IT/Business Collaboration

Skip Navigation

The 7 Keys to Deliver Better Applications Faster through Effective IT/Business Collaboration

/ December 5, 2013

Over the years, we have been involved in hundreds of implementation projects.  Along the way, we’ve developed countless best practices to help clients and partners apply the Mendix App Platform in the most efficient way, so that they can build better applications faster, without all of the traditional cost, complexity, and risk.

We created this blog series to share those insights and lessons learned.  Our plan is to cover a number of topics (IT/business collaboration, team structure, methodology, maintenance, etc.), starting first with high-level posts and subsequently going into greater depth. This body of knowledge is one of many things we’re doing to ensure that Mendix meets or exceeds the expectation of each client and partner.

Not surprisingly, the first post in the series is about IT/business collaboration because it’s the reason Mendix was founded in the first place.  While my co-founders and I were in business school, we saw firsthand how painful and frustrating it is to be involved in the application development process from the business side.  We set out to solve that with Mendix – to improve collaboration between IT and the business and to make development radically faster and simpler while ensuring project success.

With that in mind, this post outlines the 7 keys to successful IT/business collaboration.

1. Focus on the business problem, not the customer envisioned solution

When developing applications with Mendix, it’s always best to focus on the business problem, not the customer’s envisioned solution.  The reason is that the customer’s view of what is possible is often limited by the tools or technology with which they have prior experience.  In other words, what they may might think is the best way of doing something might not be the best way at all, especially with Mendix.

We’ve found that the Mendix App Platform opens up a world of new and better possibilities—solutions that customers didn’t know existed or were even possible.  Therefore, it is the responsibility of Mendix business engineers—a term we use to refer to non-professional developers who are business savvy, yet have some affinity for technology—to understand the business problem and design the best solution.  Business engineers are in a unique position to do so because they possess a deep understanding of the business as well as capabilities of the platform.

One example of a client that was boxed in by previous tools was a large health insurance company.  The business problem they were trying to solve was an automated way to collect information from their customers.  Their envisioned solution was distributing and collecting Excel sheets—simply because they didn’t realize how easy it would be with Mendix to build a specific web-based interface for customers that is also tied into their existing back-end system.  By adding a user role, security rules, and optimized forms, a high-quality interface was built for a fraction of the cost and resulting in a much more scalable and user-friendly solution compared to the Excel alternative.

2. Divide work based on user stories instead of specialties

The next important key to successful IT/business collaboration is to divide development work based on user stories, not developer specialties.  The latter is a more traditional way of approaching application development, where specific team members each focus on specific technical areas, such as database/data model, UI, etc.  This isn’t the most efficient way to work with Mendix, because business engineers can typically complete 80-100% of the work themselves, with the exception of some very technical topics (i.e. styling or integration).

Instead of dividing tasks based on specialties, project work should be divided based on user stories, a term used in scrum or agile development methodologies to refer to a specific feature or piece of functionality written in in the everyday language of the end user (one format is “As a <role>, I want <goal/desire> so that <benefit>.”).  These stories should be developed by one or more business engineers as a whole. This way, every business engineer develops a full working piece of functionality each sprint rather than working on a certain activity. In the process, they’re able to better focus on the business solution (see point #1) and deliver the best solution, versus simply completing his/her assigned task.  The result is better software and happier end users.

We often see new partners or customers try to divide tasks this old way because it’s how they’ve always worked—and as we all know, old habits die hard.  One of our outsourcing partners took this approach early on and the initial progress was less than anticipated.  The knowledge transfer and documentation required between different tasks created a lot of overhead and noise, which resulted in low productivity and lack of business agility.  Once each business engineer took full ownership of a user story within a certain domain, we saw a dramatic increase in productivity and quality.  In addition, the knowledge and understanding of functional aspects of the application increased significantly, resulting in better collaboration and working software.

3. Provide working demos or prototypes every sprint

Systems design can be a very abstract exercise.  Two people can literally sit in the same room for hours and think they’re talking about the same thing, but in reality be on completely different pages.  That’s why it’s crucial to show working functionality (whether a demo or prototype) during each sprint.  The demo/prototype should be used to validate requirements and assumptions (knowingly or unknowingly made) to discuss possible changes because needs or other factors have changed.  With Mendix, changes can even be implemented during or at the end of the meeting to show the business stakeholder what impact it will have.

This process of validating major assumptions by showing working functionality is especially crucial in the early stage of the project.  The longer you wait to validate business requirements, the greater the potential disconnect and the more time and effort you’ll need to course correct.

At a large project for a church with 2,000,000 members, the functional requirements for a new application were specified by the church’s volunteers.  As soon as business engineers implemented the flow for moving a person to another address, the volunteers asked, “How do we move the whole family at once?” This important feedback highlighted the fact that the concept of families was not addressed properly in the functional requirements.  By providing the prototype, the missing requirements were identified within two weeks and the client was able to take the necessary measures to embed into the system.

4. Implement daily “walk-in” hours to validate assumptions and synchronize with the business

The Mendix App Platform allows you to rapidly develop new applications and functionality.  No matter how precise the upfront requirements are, there will inevitably be points where requirements conflict or business engineers don’t understand something, have questions, or envision a different way of doing something.  Because Mendix helps them to be so productive, they can’t afford to wait days for an answer.  If that’s the case, they may start to make assumptions that end up needing to be reworked or thrown away altogether.

Therefore, it’s important to ensure there’s an opportunity each day for developers to interact with the business, discuss ideas, and validate assumptions.  This may be perceived as a strain on the business but in practice it’s not.  When the developer works on site, this can be done quickly during lunch or a break.  In other words, it can be fit into the schedule of the business user, creating little to no burden or disruption.  And that quick check will save rework down the road.

We’ve found that when their input is put immediately into the product, business users become more much motivated and enthusiastic.  They realize it’s worth the time and effort and they start to make a mental business case for themselves to spend time with the developers.  Very often, the change in demeanor is apparent from one meeting to the next.  By the second or third meeting, they’ve gone from reluctant participants to willing and enthused advocates.

5. Model complex business rules and forms together with the business

There may be times when daily “walk-in” hours are not sufficient, and closer collaboration and knowledge sharing between developers and business users is needed.  In these instances, the Mendix App Platform is ideally suited to facilitate cross-functional pair programming where business users—instead of the traditional process of writing requirements documents—are paired with Mendix business engineers to co-develop complex business rules and forms using the Mendix Business Modeler.

If you think about it, it’s nearly impossible to envision every possible situation or scenario up front.  Therefore, once an application or piece of functionality is developed using traditional methods, you have to validate whether the developer understood the requirements correctly, which results in a large and lengthy testing procedure.

This can be avoided by the Mendix business engineer and business user modeling the application together.  While one-off sessions are a great starting point, many customers take it to the next level by physically locating the development team in the business for the duration of the project, facilitating continuous conversation and collaboration.  The business engineer can stop and ask questions about different scenarios, helping to identify and resolve any misunderstandings or issues on the spot versus waiting weeks or months until the application is already built.  This way of working enables your team to build the right product faster.

A great example is a pharmaceutical company that developed a site monitoring application as part of its clinical trial process.  Because the company’s process was so unique, extensive interaction with the business was required.  Therefore, the development team sat with the business and directly collaborated with the business owner to build the application, with no detailed specifications up front.  The application was delivered in a fraction of the time and cost compared to the alternative: an off-the-shelf clinical trial management system (CTMS) that would have given them exactly what the competition had.

6. Close collaboration with end user testers (during UAT)

User acceptance testing (UAT) is typically a last but important phase of the development cycle.  While something might work from a technical perspective, there’s no guarantee it will “work” from a business perspective so UAT serves as the final validation by the business.  Traditionally, though, UAT is a formal procedure with a large amount of overhead, such as creating tickets, planning them for release, etc.

With Mendix, however, UAT assessments can be made on the spot without following a formal, time-consuming procedure.  By collaborating closely with the end user test team, Mendix business engineers can identify and fix small issues immediately on the fly. Changes are typically implemented so fast that the test team is often able to test the fixed application/functionality before they would have even been able to create a ticket. This approach simplifies and improves the progress of bug fixing and testing in general with better feedback from, and experience for, the end-user.

7. Implement a feedback loop to capture end-user feedback

The number of end users is always bigger than the project team you’re working with (including the business representatives).  Therefore, it’s important to facilitate end user feedback to identify those details or issues which are not known within the smaller group responsible for building the software.

The challenge is that traditionally, there have been large barriers to providing feedback: complex ticketing systems, unwieldy spreadsheets,  or e-mails that end up in a black hole.  In addition, it’s often difficult for end users to explain exactly what they were doing and what they expected from the application.  Meanwhile, feedback like “it doesn’t work properly” is useless for developers who require all sorts of follow-up contextual questions.

Mendix solves these issues by including a feedback button in every application.  With a simple click, end users can provide feedback, with Mendix automatically capturing the context (which user, browser, form, etc.) and including it with the user story that’s submitted to the development team.  It’s all part of the same platform – no additional system, process or implementation required – so user feedback immediately ends up with the relevant development team and can be easily reviewed and addressed.

Let’s face it: the perception of the quality of the software is largely related to minor semantic elements: the sequence of input fields, proper captions, etc.  Because these changes take minutes to implement and deploy in Mendix, they are quick wins that can help you to get more value from the software while making end users more enthusiastic.


Despite all of the discussion, there is still a clear disconnect between IT and the business.  According to the IT Governance Institute, 50% of organizations lack any formal structure to align IT investments with business strategy.  Meanwhile, a CIO Magazine survey reveals that 71% of projects fail because of poor business requirements management.

It’s time to make IT/business collaboration happen instead of just talking about it and experiencing yet another project failure.  Fortunately, the Mendix App Platform is enabling companies around the world to make IT/business collaboration come to life with applications that truly deliver what the business needs and when it needs it.  By embracing the seven principles above, they’re delivering applications faster, cheaper, and with more successful outcomes.

Copy link