Isn't this a description of what IT people and operators are supposed to do? "A bunch of services, set up with a little glue and a lot of configuration," is exactly what ops is about. Customarily, programmers run the show and tell the operators what's needed, but perhaps for a small business it would be best for an operator to act as "software concierge," arranging for new software to be engineered only when necessary or helpful.
The "concierge" idea is a new one that I hadn't heard before. It helps describe a piece that I feel is missing from what it is I feel that I do, because, so often, perhaps because the terms "operations" or "system administrator" don't have the word "software" in them imply that I don't understand it or can't apply engineering to it.
Although I don't feel comfortable going as far as dictating the outcome of some version of the build vs buy decision, I agree that, when I happen to be on staff, tremendous value is lost by not at least consulting me as to what "buy" [1] alternatives are available. As an experienced technology (not just software!) concierge, I often know even more than one.
Unfortunately, by the time I'm hired, it's almost always too late. Especially at modern startups, programmers very much run the show, so the focus is very much on writing new software.
That said, I don't think this notion is unique to ops engineers. It can be extended to programmers, as well, in that very senior ones tend to follow similar models, of simpicity, code reuse, libraries, and, ultimately, eschewing actually writing (especially rewriting) new software unless necessary.
[1] quotes because it's often free-gratis, merely not custom-written there
