That seems like a poorly run company. Idk. Maybe we’ve worked in very different environments, but devs have almost always been aware of the criticality of the app, so convincing people wasn’t hard. In most places, the answer hinges on “is it customer facing?” and/or “does it break a core part of our business?” If the answer is no to both, it’s not critical, and everyone understands that. There’s always some weird outlier, “well, this runs process B to report on process A, and sends a custom report to the CEO …”, but hopefully those exceptions are rare.
>devs have almost always been aware of the criticality of the app
I'm sure that developers are aware of the how important their stuff is to their immediate customer, but they're almost never aware of the relative criticality vis-a-vis stuff they don't own or have any idea about.
I maintain a couple of apps that are pretty much free to break or to revert back to an older build without much consequence, except for one day a week, when half the team uses them instead of just me.
Any other day I can use them to test new base images, new coding or deployment techniques, etc. I just have to put things back by the end of our cycle.
Welcome to University IT, where organizational structures are basically feudal (by law!). Imagine an organization where your president can't order a VP to do something, and you have academia :)
agree. ethbr1 is 100% right about this being a problem; if politics is driving your criticality rating, it's probably being done wrong. it should be as simple as your statement, being mindful of some of those downstream systems that aren't always obviously critical (until they are unavailable for $time)
edit: whoops, maybe I read the meaning backward, but both issues exist!
