Managing multiple DBs and servers with central or local processes? In my previous job, I had to manage some DBs (~500) installed on some servers (~20). Everything on SQLServer.

For basic tasks such as backups, archives or monitoring, I used to have a process installed on a central server which knows where is everything and what to do on each DB or server. So, a generic SSIS package, some configuration tables, a couple of SQLServer jobs, and we loop, apply scripts, and pull results and logs to this central DB server. 

Everything was going well and I get used to that kind of design. And also learnt the good and the bad (ex: pro = only one process easy to configure ; con = it's a kind of spof).

Now, in my new company, I am facing the opposite: each server has its own local jobs and scripts, and pushes the results to a central DB server (using linked servers).
First, I thought it was not a very reliable way of doing things (if one task is completely failing, nobody knows / harder versioning / etc...). But actually, it seems to work well for years.

So I would like to have a better point of view than "I'm not used to that so it's bad". 

What could be the pros and cons of each approach ? (in a SQLServer environment, version 2008 and more).
In the environment I managed for about a decade, backups were handled by local jobs, but we did have a couple of monitoring jobs (daily login records for audit purposes, and daily report on failed jobs) that was centralized.

So, here's what I can think of:

Centralized job "hub"

PROS:


Same approach applied to all servers.
Easy to change process for all servers in the environment.
Easy to monitor entire environment.


CONS:


One point of failure - If the hub fails, nothing gets backed up, etc.
Likely implemented with one account with admin access to all servers - if that's compromised, everything is.
"One size fits all" approach to all tasks may not be appropriate, in some cases (server-specific jobs may limit when you want to do full backups, for example; if all full backups are run from a single job, it becomes more difficult to accommodate specific time frames for particular servers).
You can presumably run certain unique jobs from that single server, but beyond a certain point it gets confusing as to which jobs hit which servers.
Harder to check status of a single server (unless that data is retained in a central table, in which case it may actually be easier).


Server maintenance jobs run locally, reported to hub

PROS:


Jobs can be configured as is best for that server.
One server can fail with no impact to the others.
Can use accounts that do not need access to all servers.
Easier to confirm activity for a single server - check the Job Activity Monitor for the server, all jobs are there.


CONS:


Failure of one server to report job status to hub server may not be noticed (harder to notice something that isn't there than something that is).
Jobs have to be set up one each server, or backups, etc. won't happen.
May be harder to spot trends affecting multiple servers.
Jobs may not be configured in a consistent way (even if the same person configures all the servers).


Many of the cons can be overcome if you've still got a central server that receives/collects data on jobs across all servers. As I said, that's the environment I worked in for several years, and it worked well for us.