Question: I have a need to explain MVC to non-programmers. Namely, to managers of other departments, in the context of progress report. One of the things I do is refactor our codebase towards MVC separation.

What is MVC separation they might ask?
Why is it needed they might ask?

After reading a fairly technical answer like this: [What is MVC, really?](https://softwareengineering.stackexchange.com/questions/127624/what-is-mvc-really), I am not entirely satisfied, since I will be talking to non-programmers. They may nod their heads but they probably will not understand what it is and why it is needed. 

In reality, I don't fully grasp what MVC is other than "separation of concerns, duties, functions, classes, blocks, tasks, things, in order to improve flexibility of making changes to the software". Separating database from view and view from business logic using techniques like DI and OO tools and techniques is something I consider to be MVC separation.

So next time you are explaining MVC to a non-programmer who has background in sales and accounting for example, what would you tell them?

Answer: 
While I endorse the gist of [Oded's answer](https://softwareengineering.stackexchange.com/a/269440/55314), that you should explain technical projects to business managers in "their language," I have a qualm about "they don't need to know technical details, just why it was done."

If you are in a project or investment review meeting with department heads, and you declare "this is what we're doing," they may want to ask "Umm...why? That seems like a big investment of time and energy. Could you give us a little more understanding what you're doing and why?" That seems an eminently reasonable question. You don't want to be caught out in a position of "Well...it's complicated." or "No, I can't really explain it." or "Don't worry yourselves about it." The more senior the staff you're doing the project review for, the less likely they are to let "it's just stuff I can't explain well" fly. Better if you can go at least one level deeper to make others feel comfortable that 1) you know what you're doing and 2) this really is a reasonably-considered effort/investment.

So, have a sketch of MVC in your hip pocket, ready to go. Something like: 

"It's a bit technical, but... MVC divides code into Models (responsible for the core data and business logic), Views (which displays the data), and Controllers (which handle user interactions and updates). It's a proven architecture--possibly software engineering's most successful "design pattern." I know it might like seem like "just some plumbing," but to handle all the requests coming in, we need a stronger foundation. This will put us on the right footing to build new features and resolve bugs faster."

Even if they don't fully understand MVC at the end of it, and even if you had to over-simplify to make it comprehensible ("break some eggs to make an omelet"), I wager you will find it much more comfortable to have an explanation ready than to have to say "I can't explain it" or "you aren't qualified to understand it" to senior managers.
> 
> in order to improve flexibility of making changes to the software
> 
> 
> 

Managers are interested in the end result. The less technical they are the less likely they are concerned with how you get there. MVC is very common, popular and proven.

When change requests are made in the future, you can let management know they can be made easier and faster. Everybody likes to hear this.

It is a common strategy, so hiring new developers shouldn't present a problem. In fact, you may attract better developers who are strong proponents.

This is all going to be very difficult if there are many pressing issues in this particular project. They may not be wiling to take a step back so you can take two steps forward. On solution may be to wait or implement in smaller pieces.