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: 
> 
> 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.
I would tell them that MVC separates my concerns.

My first concern is the code logic - what I do behind the scenes to make the website perform the actions they want it to.

My second concern is the business logic - what they (the user) want the application to do.

My third concern is how the site looks - The page they visit to do what they want.

(I woudln't tell them this next part) So, in order, my explanations were for the Model, Controller, and View.