A constant frustration point of IT is how we name deployment environments and how we treat them.

There are risks for not allowing proper place to build and test new ideas, but there are also risks and costs for trying to properly maintain and authorize multiple deployment environments. And, not everyone agrees on the current state of a deployment. Do "development" and "production" mean the same thing for a systems administrator? A software developer? An IT manager? An application administrator? A network engineer?

The bureaucracy around deployment environments can stand in the way of productivity and innovation. "It's too hard to get X in production, so we'll just point people to use dev." Or, vice versa: "It's too hard to get into dev. So, we'll just be careful and use production".

The panel discussion on this topic should be lively and bring awareness of the concerns and viewpoints from the diverse spectrum of stakeholders in IT.
-------------------------------------------------------------

Example panelists could be:

a CISO, a CIO, a dev-ops engineer, an applications administrator, a systems administrator, a software developer, a web designer, an instructional designer, a network analyst, a security analyst, a database administrator, etc. Perhaps even an application owner, like a registrar, or finance director.

Example moderator questions:

In the world of automated deployment and configuration management where everything is virtualized and software defined, should we even be supporting a formal development environment? That is, should development stay on laptops?

We run into situations where something in "dev", the moment it starts working, becomes "production" without ever being redeployed. Should this be discouraged through controls, or encouraged and formalized through CI/CD?

Sometimes critical or expensive work is lost because something was marked as "development". How disposable should development be? Is there such a thing as a critical development system?

Given the effort and complexity to maintain, patch, synchronize, and secure multiple environments for multiple departments… how do we balance the risk of not having enough environments with the risk and cost of too many environments? How many is too many?

Development is supposed to be a sandbox, but who should be allowed to play?

Should production data be used for development? For testing?

Once something is developed, how are consumers supposed to test? Redeploy to a testing environment? Open up development to more people? What if there are only two choices: production and not-production?

What environment should be used for training end users?