rglenn-accenture
commented
1 year ago I think we can be a little overly purist when it comes to ClickOps. I actually see a Level 4 or 5 primarily driven by what is indistinguishable from ClickOps: at some point, folks could be leveraging kubernetes et. al unwittingly, interacting with a UI abstracted far away from the underlying code.
The problem I have (and I think most share) with what we commonly think of as ClickOps is the size of the range of variables. It’s not that we have to click buttons, it’s that we have to click 20-30 buttons to get anything safe and useful with the stock controls.
From my perspective, a very valid high level of maturity allows for (or maybe even prefers) a “Self Service” approach to general-use resource management, which all but requires a tightly-fit (i.e. potentially highly customized) “ClickOps” interfaces*.
I do think you want to leave Self Service/ClickOps until the end, though, when you have minimized the options you want to expose (and maybe introduced intelligent defaults, where appropriate), and more importantly, put a million policies that keep things from getting out of control.
*I know this is not strictly ClickOps, as in truth the concept implies stock interface controls. Many platforms do allow for configuring the stock interfaces through policies, and I think that would be an appropriate way to deliver a Self Service solution, albeit an extremely vendor-lock-in-y one. I think what I'm most worried about is people hear "avoid click ops" and think "avoid all web interfaces", which I don't know that I fully agree with, at maturity level 5.
When to provide a paved road for developers i.e. all the automation and configuration needed so they have a standard tool chain i.e. Avoid clickops where a person just clicks around to get something out.