Architecture is Important
"The great thing about Standards is that there are so many of them."
The good and bad news all in one sentence. But Architecture is the real issue here, and it too suffers the problem of standards.
Architecture may be more important than standards. It sets the playing field for a set of applications that (are supposed to) accomplish a specific set of purposes. But the conflict in architecture design arrives when the desire for clear limits to the design space confronts the need for future flexability. Often times the future flexability wins out and the architecture becomes ill defined and less than useful.
This is a bad approach 90% of the time. The key to clean application design and implementation is a clear set of limits, not something that looks like an amoeba.
The best way I have to convey my view of how this should be done is to list the best and worst ways to design:
1. The all inclusive design: Design is finished when you can no longer add any features, AKA 'Kitchen Sink' design.
2. The exclusive design: Design is done when you can no longer take anything away, AKA the Einstein design criterion.
Note that #1 is Microsoft's design philosophy, and it gives us products like Word, which will do almost anything you want after a few years of training and experience. My personal selection, having tried both when I was younger, is #2.
Architecture defines the playing field for systems, and it should follow the principle in #2 for almost all systems. It is only where systems are probing the boundaries, experimenting with approaches, that approach #1 is useful, and even there well defined boundaries should exist if only to limit the time spent in marginal areas.
In both cases, experience and critical analysis of the purpose for the system should be your ultimate guide. The closer you can come to a limited, well defined playing field, #2, the more stable and reliable will be the product.