How to improve skills in software architecture

Question

What is the best way to improve your skills in software architecture? We were taught design patterns in university, and I see plenty of books with simple and straight forward examples, but aside from them, how can you learn good architecture? In other words, how does one evolve into a great architect? What are the prerequisites?

Answer 1

1. Network. Get to know some good architects. Talk to them. Learn from them, and bounce ideas off of them.

2. Read voraciously. There are hundreds of books on software architecture (several good ones even). Read on topic, and read related topics (building architecture, management structures, electrical engineering, operational architecture, etc.).

3. Study architecture. There are thousands of platforms and products out there. Look at them. Dissect their parts. Some of my best learning early on was from looking at great architectures (look at the little languages, packed files, and simple structures in the original Doom source, for example).

4. Think, sketch, try. Practice your design skills on imaginary problems. Fun problems. Interesting problems.

5. Do. Work on real systems. Ship them. Feel the pain caused by your poor decisions, the pain you cause your developers, and learn from it. Good architecture is in balancing what you get, how you get there, and how much it costs.

Answer 2

Personally, I'd say that I've learned more from sheer trial and error than I have from reading. You might be surprised at how many of the crazy ideas you have turn out to be good and the number of brilliant ideas that turn out to be terrible. But you never know that until you try. This is just as true when you first start writing the code as when you're halfway through it. Don't stick to an architecture that doesn't work just because it's what you've already decided on.

Lastly, spend the time to think your solution through. Do your best not to listen to coworkers and managers who pressure you not to think things through and just start coding.

Answer 3

A coder thinks about solving the problem; an architect thinks about maintaining the solution, limits the implementation imposes on the solution, areas of the implementation to improve as time permits, areas of the implementation that can be left out or reduced in scope if the schedule slips, dependencies (both internal and external) that can impact the performance of the implementation and things that can be done to limit the risk exposure, the training required for new users of the system, the documentation being developed and changes needed as the implementation deviates from the envisioned solution, and how the stake holders feel about the progress that is being made and the applicability of the implementation to the actual problem being solved.

Being an architect requires you to be able to communicate effectively, organize your thoughts and plans into a workable schedule, decompose a problem into implementable pieces, build prototypes of technically challenging pieces, and coordinate the implementation of the pieces so that everything finishes on time.

Learn to diagram your solution using Enterprise Architect, Visio, or pencil and paper. As mentioned in other answers, get an architect mentor and share your solution diagrams with them for review. Listen to the feedback and revise your diagrams.

Learn to build realistic schedules. Start tracking how long it takes you to implement things, and keep track of how close you are to correctly estimating how long it takes.

Break down your next assignment into small pieces before you start coding and keep track of the steps you left out. Learn to anticipate problem areas and prototype them before you start coding the final solution.

The article linked by Pierre 303 over in this answer to a similar question is worth adding here as well:

Who needs an architect from Martin Fowler