There's a provocative editorial on the "Academication" of software development at DevX:

Software development is not an academic exercise. It has more in common with the blue-collar "build me a house" ethic than it does with ivory tower research. So let's quit treating it as if it's university research. It's not. Define, design, build, test, deploy -- that's what we do. Deliver code that does what the end users of the code need or want. No more, no less. From Web sites to database applications to games, it's all about what your code will do for the end user and not about how you did it. Your end users don't care if you used a Booch diagram or anointed blocks with arrows and written descriptions to communicate to the development team how you were going to build the software. They care only that the software works the way they expect it to.

As an aspiring architect, I tend to agree. It takes a good developer to make a good architect. Never forget that you're a developer first and an architect second. Forget the ten dollar acronyms and fancy diagrams. Gather feedback from the developers doing the work to determine if your designs are working. Throughout the project, you should continually ask yourself:

• Do I have difficulty explaining my design to other developers? When I explain it, do I get the feeling that they are just nodding along to be polite, or do I get a palpable sense of engagement, that my ideas click with them?
• Do I make a lot of excuses during the explanations? I wanted to do it this way, but.. I know it seems complicated, but.. in the next version we'll improve that..
• Do developers tend to write code that fits well with this design? Or do they keep "getting it wrong" and forcing me to intervene?
• Am I getting a lot of questions about this design? For things that I consider simple and straightforward?

A software architecture isn't automatically good just because it came from a $45 book on Amazon. A software architecture is good when-- with a little education-- it fits the developer's mental model of the way things should work and it makes them more productive. If your architecture is screwed up, believe me, you don't need a book to find that out. Just pay attention to the warning signs from your co-workers.

I do agree that patterns are useful as a standard part of our design vocabulary:

The names of patterns give us a lexicon by which we can talk to each other about the arrangement and interaction of components, especially for those arrangements and interactions that we're likely to encounter again and again. Once again, the onus is on the organization to ensure that there is a standard for pattern names and that the developers in the organization know that standard. Besides, if you're a professional programmer working in any of the mainstream OO Programming languages, you should be worried if you're stumped by "Decorator". In such a case, high-tail it to Amazon or your local bookstore and pick up a copy of Head First Design Patterns.

Patterns are an important part of the continuing evolution of software development. But don't be a slave to the patterns, either.