Mendix tips & thoughts

Mendix Series

1.  Overview of Mendix 

2. Mendix - Part 2 - Diving deeper

3. Extensibility for Mendix Studio 

4. Building a Mendix Widget for the Mendix marketplace (Convert text to Audio using Azure AI)

5. Mendix Tips & Thoughts (this post)

6. Competitors

Mendix Charting/dashboarding options:

• E-Charts (Community supported) are simple and nice,
• Anycharts (very common),

Grafana can be integrated, but I haven't tried it with Mendix.

Power BI can show reports using an iFrame widget.  I like this approach.

Module/Widget Support Note: Check whether libraries are supported by Mendix/Platform or Partner.

Community-supported obviously can be changed by the community. Partner-supported is also an option if you have an agreement with the partner or trust them.

Performance Testing Tool options:

A colleague has used JMeter and feels it was not ideal. 

I'm considering using the Microsoft Playwright Testing service and Playwright testing.

Enterprise Logging/SIEM SaaS integrations supported by Mendix:

1. App Dynamics.
2. Datadog,
3. New Relic,
4. Dynatrace, and
5. Splunk

Watch out for:

Logging

Each system logs to loc files on the local machine; these can be pushed into the Postgres local instance.  This can result in a massive storage load being added for auditing and logging.  

Monitoring

Logs can be shipped out using backup and restored or by calling the REST Open API.

Maintenance

Mendix builds a database per app per environment, so the recommendation is to use at least 3 per app as you need dev, Test, and Prod. Each instance, by default, uses PostgreSQL (you can only use PostgreSQL if you use the Mendix-provided images deployed on AWS).  

Global Variables

Mendix doesn't have a concept of a global variable at the start or per session. You can load lookup data, which is often held centrally in your enterprise. This can get heavy quickly, but you can copy Open API results into the local PostgreSQL database so it only gets local data.  

Costs

With Mendix, the cost can escalate rather quickly. Reduce cost by scaling back to the most minor instance in dev and test, especially post-go-live. Each app has a separate database, so management and connectivity can become hard to control. 

Performance

Number of Controls & Size of each application.

Mendix Series

1.  Overview of Mendix 

2. Mendix - Part 2 - Diving deeper

3. Extensibility for Mendix Studio 

4. Building a Mendix Widget for the Mendix marketplace (Convert text to Audio using Azure AI)

5. Mendix Tips & Thoughts (this post)

6. Competitors

SaaS Product Customer Experience - level 101 Thoughts

Overview: With SaaS products is is easy for our customers to leave.  We need to reduce turnover/churn and technology can help to deliver great Customer Experience (CX).  CX is closely coupled with Customer Success.

Topics to Review:

1. SLA's & OLA's
2. Pricing: 
1. per seat (subscription), 
2. flat usage or 
3. usage model (pay as you go).  
4. Always keep it simple.   In B2B SaaS pricing keep it simple, aim for MMR, that clients understand for cost forecasting.  Make it easy to buy, increase/upsell and leave.  It's amazing how many companies try to hide the sale to reduce churn.  Build good products and service don't try hide exit so stop loosing customers, it's pointless and a poor long term strategy.  
5. Tiered pricing is good, but keep it simple.  Try stick to 1 form of pricing, its aweful for the customer to have base usage costs and then some crazy secondary model to figure out and explain in the purchasing process.
6. Companies want Monthly Recurring Revenue (MRR) or ARR and the ability to up sell later.  It depends on the nature of the business and product but monthly should be the default goal especially for B2B SaaS.
7. Offer a free trial for E2E fairly long is not a bad idea depending on the product.  Two weeks is a rough starting point.  Less if you need them engaged quickly or even several months to get real value.  I tend to find E2E customers with free software don't tend to use it unless their is a limited time.  So I'd always limit to 1 month for a free trial. you can always extend.
8. Freemium version may be useful (unlimited time) and generally are not applicable to B2B/E2E SaaS models.
3. Service Status Page - Microsoft do a great job at showing status pages for their services.
4. Incident Management - Convert into knowledge base both internally and customer facing.  Sales and customer management information alignment.  Find a customer, see their past requests, help reduce churn. service now incident management,   Generally, go for tech touch for interaction over low touch or even high touch.  In E2E, large customers want good tech touch but will require high touch, specifically around customization.  Beware the small customer demanding high touch for their "future potential growth/usage".
5. Content - product documentation, community forum, online knowledge base, ability to have a good search to cross all the channels (think Coveo), support chat bots, live conversations with support.
6. Certifications, "gamification" useful for building a community. 
7. Communicate new features, educate support, educate sales and evangelists and clients.  Training and consultancy.  Monitor communication, use Sentiment Analysis.
8. Support level i.e. free support may not allow phone conversations and not have an SLA whereas premium support may offer 24 hour production issue resolution with money back guarantees.  Example: Azure Support Plans.  Phone is expensive for support, do we offer this 24/7 and having good support is costly.  People are becoming more familiar with digital self service.  It is also a good idea to have a  warm hand-off from automation to a person.

Getting your processes correct and clear is key to your Digital customer experience (CX).  Key areas to consider: 

• Advertising/attracting clients, converting leads to clients;
• Trials and paying (make it easy, cost effective, billing) - customer must understand what they are paying for;
• First time user experience (easy good experience the client can use);
• Habitual users (once use to the system, do my users have the best experience - get usage telemetry); and
• Support (levels of support, chat bots, email, call support).

Thoughts: SaaS world changes so quickly these days, great customer experience and support are more important than ever.  An interesting idea I heard, "You can loose a customer on price or customer service, you will only win them back thru customer service".  (KYC) Know Your Customer to ensure you can delight your customer and comply with AML rules.  Get one step ahead, try understand your customers concerns early.

There is a great book that has been around for a few years on Customer Success by Nick Mehta, Dan Steinman, and Lincoln Murphy.  How innovative companies are reducing churn and growing recurring revenue.

Knowledge Transfer/Support Handover

Problem:  Projects that I tend to work on are complete by Scrum teams filled with specialist and specialist contractors who move on after project completion.  Support is generally handled by dedicate people/teams offshore.

Hypothesis: Having high quality support people working alongside you throughout the project is not very common due to costs.  I believe there are key points to cover to ensure that the operational support is effective.  Too many companies merely focus on checklists and the ops team don't get a fundamental understanding of the system.

Resolution:
1. People/Support: Understand the domain - Hard
2. People/Support: Understand the architecture - Easy
3. People/Support: Understand who is responsible for level 1- level 3 support and what that entails.  Easy if done correctly.
4. People/attitude: Hire patient collaborative, eager people in support (most key point) that want to learn and take ownership. Easy if done correctly.
5. Knowledge base - have a wiki or equivalent.  The same issues always present, so document and have an answer that can help your uses.  I also like to record mp4's for different levels of support.  Record the sessions as it is too easy for level 3 people to say they never got a handover or covered something.  This allows people to look back, easily train additional users.  Easy if done correctly.
6. Ensure you have automated tests, they are a great source of how your system works.  And if a fix has to be released, it also easy to validate that the original logic still works.  Hard but it returns great benefits if used.

SharePoint Support Models

Overview:  Large organisations tend to use a tiered support model also called the escalation model.

The Problem with Tier Support Models:
A user finds an issue and explains it to level 1, the Level 1 support guys figures out it's too difficult or not on his easy path and pushes to level 2,  the whole bug needs to be re-explained generally involving the business user that reported the bug and the level 1 support person.  This goes on for 3  to 5 levels in bug organisations and is eventually passed onto engineers or the vendor.  It takes an astronomical amount of time, and provides a poor impression to the business user.  Coupled with a tracking system that the end user don't know how to use and the support people trying to add as much content as possible so as to cover any responsibility as they have not missed anything.  It's just a disaster.  Anyone doing Level 1 and 2 support is generally not happy and poorly remunerated so the turn over is high, end use satisfaction is not good.  A lot of time and focus is wasted.  To me the fundamental problem I have with Tiered support models is a lack of Total Ownership.  Support people pass the problem and tick off the easy fixes.  I have seen multiple support escalation software products and fundamentally the products don't tend to make much difference, it's the implementation of the support process and the quality and ownership of staff that determine good support models (but its far easier for people to blame software).

On the plus side, Level 1 support people are considerably cheaper and if they have good knowledge basis and training they can return 70% plus of incidents at this 1st stage.  Funneling tougher questions to more specific staff.

DevOps: DevOps relies on close collaborative deployment and support, so the upside is you have the developers and they understand the infrastructure and are best position to fix mistakes cleanly and quickly.  In traditional enterprises, we tend to have hundreds or even thousands of applications and you loose economies of scale by having to keep dedicate higher cost people around to do support and it generally affects sprints as people need to be pulled out to fix bugs.  On the plus side, you get fixes done quickly and correctly.

For me the answer is "It depends...", if you are a tech company with 1 main product, think Facebook, AirBnb then devops is clearly the choice approach.  If you are a company that has legacy applications such as a bank, an application supporting mortgage applications has been used for 10 plus years, tier support is much cheaper and effective.  So the tough question would be what about the same bank that is now developing a new complex application, ideally if governance would allow it then I would start developing the product and use DevOps, allowing better deployment and support in a rapidly changing environment.  Once the project starts maturing then the question is when can I move the product to a tier support model.

Summary: DevOps works well in an Agile environment and support is vastly improved, assuming the product is not changing and the number of incidents is low, this the time to transition to a tier support model.