When a power user creates a Nintex solution and then leaves the company who supports the solution?

This is a just a governance issue.

On some customers, this issue is solved having a helpdesk with those technical skills that a regular user does not have.

On a different governance, all those changes are only made by a specialized support service on that tool.

This last approach is profitable because on that specialized support service , they can work with a set of well known best practices and governance on all your company customizations, and not leave it to the discretion of users.

Every governance direction has pros and cons.

We have the same issue with power users creating great no code solutions and then leaving and not being replaced with someone who has the same aptitude. 

We're fortunate enough that we have a dedicated SharePoint staff with Nintex Power Users on the team, so the affected Team can submit a ticket to the SharePoint Team for help. The request is assigned to someone who basically tears apart the workflow and if there aren't notes on the workflow actions they add them, so that in the future it is easier for one of their team members (or if the original team gets a Power User again) to understand how the workflow works and how to tweak it for new requests.

This goes back to the need to document on the workflow and preferably some kind of back up documentation about exactly what the workflow does and why. This has been a running conversation in multiple entries, including the January 2017 Mission and Document Your Workflow - Ideas and Tips from the Nintex Community.

In our company we call this EUC (End user computing)...which is basically frowned upon 

Luckily EUC's were an issue before Nintex was introduced. Now as per governance policies we do not allow end users to create any Nintex solution. They always need to go through IT. We have a very competitive SharePoint and Nintex team internally to take care of such requests.

Some benefits of doing it centrally:

1) Best practices are always employed while deploying a solution.

2) Since the same team works on all solutions there is more standardization possible. This makes any new comer pickup things very quickly.

3) No abrupt server performance issues. Our SharePoint admin is almost always consulted when deploying solutions. So no surprise CPU spikes !

I will say this will vary from company to company.

We look at Nintex as just another development tool. I agree it provides simplicity and power in the hands of the end users...but hey their "Power App" becomes IT departments headache once it starts failing .

if we assume only 5% of our employees create workflows we will have to face 100s of undocumented "Server busters"!

You should see the carnage of workflows sharing a history list and then spamming it with log to history list actions. I have seen very large farms brought to their knees by this scenario. Letting end users run wild with Nintex work flow is not the best idea in my humble opinion. That said, educating end users to build well constructed solutions can be a huge money and time saver for companies (as found in various studies).  Just my two cents!

Agreed. I would even go as far to say never use a log to history action for anything other than debugging/diagnostics. If you are using it to retain data for any purpose, you should look at building out some sort of solution (list, sql db/table, etc) for recording that data. It will give you better reporting and it will not be the target of needing to be deleted later on to resolve performance issues.

If you make some poor administrative desisions like turning off the loop pause, not distributing your site collections across multiple content and Nintex databases then you could run into problems. Blocking the use of Nintex just masks those underlying issues.

I think we agree an agree about the need for up front governance, guidance and user training. There is a happy medium between not letting users use Nintex and letting them have a free for all. It just requires us to engage our customers and partner with them.

I think a lot of us here are coming to Nintex from using InfoPath. I've seen internal customers being put-off SharePoint-based solutions all together due to bad experiences with user-created InfoPath forms, and I've also had to pick up the pieces when InfoPath citizen-builders have moved on - they've taught themselves enough to build one solution, and that's it.

With Nintex, it is not as bad (on the forms side), but I and other dedicated solutions developers at my company are where requests for solutions should come. As with all systems, there is a learning curve. A citizen developer will learn as much as they need to build their one solution (that they need now). Most dedicated teams/developers will keep themelves up-to-date with changes, and will have various requests to handle - which also means development time will be shorter and quality will generally be higher.

Generally, if you build it, you support it; so having a team involved means they are all aware of what is being developed, and can share ideas as well as support duties.

nice jargon there - Citizen Developer.

A citizen developer will learn as much as they need to build their one solution (that they need now). Most dedicated teams/developers will keep themselves up-to-date with changes, and will have various requests to handle - which also means development time will be shorter and quality will generally be higher.

I completely agree to this point. Ultimately better quality solutions will keep the overall costs down.

Imagine me becoming a Sales professional just by reading a 50 page book ;-)...Development is ITs job...best it stays within IT

The drag 'n drop is easy and doable by anyone with a mouse and a will.  Its the architecture that'll get ya everytime.  Decisions, Decisions, Decisions (kind of like that old poster with a Lambo, Ferrari and Porsche on it).