Depending on how your environments are configured, I would think that "view" (read-only) access wouldn't be a terrible thing, but giving the architect write access, especially at a root/admin level is NOT a good idea (for similar reasons to why devs shouldn't have such access).
So the question becomes: how do we give him/her enough access to be informed and effective, but not so much that it is likely to allow problematic changes.
There could be a few ways of this. In many cases, there are management or monitoring systems with management UI's on which you can create accounts with view-only access. For example, in many places I've worked, there are one or all of the following:
* A network management software which is capable of listing all known managed network devices and returning logs or configuration details for them (without allowing access to change)
* A software/package management system capable of tracking all licensed hosts (e.g. satellite/spacewalk for Linux, or perhaps something tied to WSUS in the windows world) and the software/configuration of those hosts.
* Monitoring software which tracks the status of running applications/services/devices, and generally knows at least a little bit about the underlying OS versions, hardware, and various applications installed
* An asset management system which tracks stuff like hardware, OS, location, ownership, etc of physical and virtual hosts
That gives several points where one could have a limited-access account where one can pull up the information needed to build a fairly decent picture of how things tie together, but without giving somebody the temptation of being able to actually change or tweak things him/herself. There may be some fine details that aren't immediately apparent with the above, but that's why you have the fifth option
* cultivate a mutually beneficial/respectful relationship between your devs, architects, security team and admins.
Seriously, the "chain of incomplete/disaster projects" is almost never on one guy, but due to a breakdown of communication between layers. By cultivating a good relation between the levels of staff, you not only have people who are willing to donate some time to getting the information you need (or considering the changes you propose), but often bring important stuff to you for advise/advisement before you even have to ask!
So yeah, you should have lots of access to *see* what's going on in a global sense, but not to *change* it (except on paper/design). Access to the noted systems is going to be helpful with that, but having strong ties to the right people is the real trump.
It may just be how things are phrased (and to be fair "ask slashdot" often comes off as better describing ones frustrations than relations), but at the moment it sounds like you're not doing particularly well at the communication bit or at relinquishing control. Don't be a one-man army... even if you do get the access it'll just lead to you taking all the heat for issues and/or burning out.