Architecture principles are probably the most accepted tool in the toolbox of enterprise architects. It is easy to see why: One of the goals of enterprise architects is to fight the chaos that naturally occurs in the constant maelstrom of changes and improvements in the enterprise. Architecture principles offer the promise that they can prevent chaos to emerge (note: the link gets you a short animation that has been very effective in communicating the need for enterprise architecture to the organization at large; I know it has been adopted by EA functions of several large organizations). Another big advantage is that principles are generally simple, clean and seem easy to follow. That makes them one of the products of enterprise architects that are actually liked by management.
Personally, I think the use of architecture principles is responsible for many, many IT disasters.
Architecture principles are not new. Modern architecture-of-the-physical already discussed principles in the '20s of the previous century, long before IT. Children of a time when logical positivism was in vogue -- a time when many thought the world could be logically explained and logically built -- famous architects like Le Corbusier believed that a set of rules could result in good architecture. Apparently good rules such as letting people live in the best locations and using inferior locations for industry, ideas about light in houses sound like no-brainers. What resulted when these principles were applied were crime-infested high-rises, however. Apparently, something was amiss with the direct link between applying good principles and getting good results. A lesson for enterprise architecture if there ever was one.
US Environmental Protection Agency, Public Domain
Highrise Housing project in Chicago shortly after World War II. Note: I am not aware this particular project ever became 'crime-infested'.
Actually, not the principles themselves are generally a problem. The problem is how we use them. Enterprise architects tend to use principles in a prescriptive way: to steer design choices. And the principles are generally accompanied by the usage dictum: comply or explain. Now, the phrase "comply or explain" already shows that we are aware that sometimes following a principle leads to bad results. So, we offer the leeway that an architect or designer working under these principles is allowed to go against them, but that requires an explanation that is to be accepted by some higher up design authority.
This in itself is already a contradiction. Think about it: comply or explain in effect says that following a principle is always good. After all, you do not need to explain yourself if you are following the rule, if you follow the rule, your design is accepted, hence it is considered to be good. But the "explain" part on the contrary allows for the case that following the rule is not good. Even principles-loving enterprise architects know: in the real world there are no perfect rules. Following a rule when the effect is damaging is not a good plan, hence the escape of "or explain."
One of the main sources of problems I have encountered in my career were principles (or standards) followed where the result was much worse than it had been if they had not been followed. And this easily happens. After all, not all designers or architects are good, so often they will not recognize the need for an exception. And sometimes the pressure they are under makes them follow rules even when they shouldn't (going up against EA takes effort and time). I have even seen the effect of "comply or explain" lead to multi-million euro disasters.
So, are architecture principles useless? Well, that depends on how you see them. Often architecture principles do describe a desirable outcome. In my book "Chess and the Art of Enterprise Architecture," I have likened the use of architecture principles to strategic/tactical rules in the game of chess. One such rule might be: "When you can get material advantage, take it." and the explanation for beginners may be to give each piece a number (queen equals 9, rook/castle equals 5, etc.) and if you take more points than you give, you win a material advantage.
Now, can you play a good game of chess by following a rule like that (or several of them)? The answer is no. But when you analyze played games, you will see that most of them were won by the player with the most material advantage at the end. In other words: while the rule describes a desirable outcome very well, following the rule does not lead you to it. In fact, it may even trip you up: comply and (subsequently) die. Architecture principles are descriptive rules, not prescriptive ones. And that difference is something that can lead us astray, it is related to the difference between statistical and causal relations. Enterprise architects can do worse, by the way, than read the later Ludwig Wittgenstein on rule-following (or his best interpreter as far as I'm concerned: e.g. read Peter Hacker's Wittgenstein's place in 20th century analytic philosophy. Don't worry, uncle Ludwig is in essence not as complicated as many make him out to be).
I prefer to see architecture principles as patterns emerging from good design. A good architect/designer will not follow those rules, but his or her work will show them. Governing by those rules easily leads -- just as with those rules from physical architecture that are in the Athens charter by Le Corbusier -- to disasters. I generally say that giving guidelines is OK, but creating principles is dangerous. And especially "comply or explain" is a toxic approach. There are better ways to get sensible architecture/design decisions.
Oh, and by the way, arguably having hundreds of design rules (such as in the reference architectures of the '90s) is obviously useless (and thus, following uncle Ludwig, meaningless) so these days we have small sets of maybe 10 to 20 fundamental principles. But as Thomas Reid's said: "The rules of navigation never navigated a ship. The rules of architecture never built a house." In other words: we do much more than follow a (small) set of rules when we create.
Therefore, if you still believe that the essential (and constantly increasing, whatever silver bullets are proposed) complexity and unpredictability of Business-IT landscapes can be managed by adhering to a small set of simple rules, I may have a nice bridge to sell you.