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.
Explain the advantages
======================

I would explain MVC in terms of business benefits. Your managers will be able to understand this, and will get on board if the advantages are convincing.

MVC allows you to break down your application into sensible units, each of which exists independently of the others. You get clean, maintainable, testable code, and potentially code reuse between systems.

The Model
---------

Each model encapsulates a single type of business information, for example, a customer record or a product, along with all related business logic.

Separating this out allows you to easily test your business logic in isolation from other parts of your application.

You can also easily extend the application by adding additional models, it's very modular and clean. 

Each model in theory can exist independently of the others. You might consider enforcing this by using service objects to handle relationships between models. You can swap out models without affecting the rest of the system.

The View
--------

Separating out your view allows you to easily update your front end without breaking the underlying back end. 

You can give your front end code to another developer without necessarily giving them access to the whole system. 

You are also free to create alternative front ends that work with the existing system. You might show your data as a mobile app, or an API, or a PDF, or an Excel spreadsheet. You can do this without hacking into the rest of the system. You're less likely to break things accidentally. You can readily create integration points for existing systems to hook into.

The Controller
--------------

The controller wires the models to the view. It keeps everything separate. You can wire in a different view very easily. If you change your model code, the view doesn't even need to know.

Other Advantages
----------------

It's a common pattern. Other developers will be able to understand your code and work on it. If you return to your code years later, you will likely be able to understand it and make changes. Your code will be less likely to become another legacy headache for a future developer.

Because everything has a place, it's much easier to produce clean code. The risk of spaghettification is dramatically reduced (though not eliminated). Your code becomes maintainable.

Because everything is modular, you can test parts of it in isolation. Your code is testable and less likely to harbour bugs or security holes. Future upgrades will be much easier as you will be able to easily test the whole system.