I love Eric Lippert's series on "Cargo Cult Programming". I've often seen it as a problem, but never had such a catchy label before.
I've long been a proponent of the idea that you can't be a successful architect without understanding how the underlying system (all the parts of it) work. For example, I may be architecting a system that relies on storing data in SQL server. I mostly likely won't be the one to do the actual SQL Server implementation, since I'm not the best qualified. There are plenty of people who understand TSQL, indexing, and suchlike DBA stuff way better than I do, but I need to understand how SQL server works at a deep enough level that I can make informed decisions about architecture.
I would encourage anyone working as a ".NET Architect" to read books like .NET IL Assembler, or CIL Programming. You may never write a single line of CIL, but you can't really understand how to make good decisions about .NET architecture unless you understand what's really happening under the covers. In case you are interested, I would recommend CIL programming over the other. It's much easier to read, and more practically oriented, although there are some interesting details about things like .EXE headers and such in .NET IL Assembler.
To be a good architect, you don't have to know every last detail about how everything works. In fact, IMHO, you shouldn't and can't know all the details of how things work. That's for other people (domain experts) to know. I would argue that an architect should avoid getting caught up in domain details, since it tends to lead you to think that everything is an exception. Many programmers I've known in the past who really know the intimate details down to the last speck for some particular domain (an industry standard, or a piece of hardware, etc) tend to think of all the ways in which their area of expertise contains exceptions. "Two credit reporting agencies send addresses this way, but the third sends them differently". "The monitor always returns a valid value for this reading, except when it's too cold in which case it's -1".
Architects who gets too involved in those kinds of details may miss the opportunity to uplevel their thinking and change their underlying model of the system. If everything looks like an exception to a rule, then more than likely the rules are wrong. But if you know all the details, it's easy to see the exceptions instead of trying to find new rules that work.
It's hard to find the middle way. If you don't know enough about how things work, you'll make poor choices. If you know too much, you may miss the big picture. And, of course, the reality is that these days the systems we architect are often so complex that you just can't afford the space in your brain to hold all the details about the whole thing.
It's also tempting to want to understand all the details because of how "neat" it would be to write that part of the system. That's a trap I find myself falling into on big projects. The reality is, though, that I just won't have time to write the whole thing (no matter how neat it is), and I have to let go and trust that someone else will understand the details.
Hmmmm. That ended up somewhere different than where I started, but I hope that makes sense. Find the middle way. Understand enough about how the system works to make good decisions.