Dismiss this notice
Welcome note for all new members Read here


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
What is a good software architecture?
#1
A good software architect is:
  • A domain expert. They know enough about the software domain (e.g. database services) to know what components are needed to do the job. They understand the trade-offs between reliability, flexibility, performance, and ease of implementation. They’re familiar with the spectrum of appropriate design choices and can guide the selection of the best set to meet system requirements.

  • A mentor and consensus builder. Often times the purpose of a system is fuzzy, as are its requirements. Proposals for behaviors and components are not fully thought through. A software architect can fix these problems and teach the other engineers how to avoid them in the future. They can understand and explain system properties and behaviors in an accessible manner. A good architect drives consensus on how the system and the different parts should be designed and constructed.

  • An effective technical leader. An architect excels at communication, tailoring messages to audiences ranging from CEO to front line engineers. They can justify the system goals and architecture, and produce excellent verbal descriptions and written documentation. They unify the teams on their projects, helping to drive a common vision and focus, getting people to work together to produce something that is integrated and cohesive, rather than a cobbled-together hodgepodge.

  • Technically credible. An architect’s assertions and judgments are credible throughout the organization. Typically an architect has already proven themselves as an engineer and is known as producers of solid systems. In the absence of sufficient information to justify the architect’s proposals, people are inclined to believe they are correct.

  • Optimistic. A good architect is positive, and a source of can-do optimism for the entire undertaking. They don’t say the sky is falling. If a system is broken, they explain how it can be fixed. If a system is a bad fit for a problem, they’ll propose one which is a better fit. Above all, they explain how to reach goals efficiently, and give people faith that no matter how dark things look, it’ll be alright. A corollary for this is that an architect needs to be able to identify when a project truly is unsalvageable, and come up with alternatives.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)