I recently read this Book “97 Things Every Software
Architect Should Know”. It provides advice from software architects around the
world on how to approach a project and avoid common pitfalls.
Here are some of the
learnings from the book: –
1. Don’t put
your resume ahead of requirements. Always recommend a solution that is best for
the problem and not a solution that is based on latest technologies and trends.
2. An architect
should know how to communicate the goals and objectives of the software
project. The key to effective communication is clarity and leadership. Keep
things as simple as possible. As a leader, you must gain the respect of your
co-workers to work in a healthy and effective environment.
3. Always ask
for the intended value of the requested feature or requirement. This will
enable you to address the real problem and provide better and cheaper solution
than that suggested by the client.
4. Once you
understand everything will eventually fail, you will be able to design your
system’s reaction to specific failures.
of the application should be considered right from the beginning. By addressing
performance testing early, you can avoid much more expensive efforts once you
discover performance issues.
6. An architect
is an interface between business and technology team and thus must understand
every aspect of technology to be able to represent it to business. Also, must
understand the business to drive the team towards serving the business.
7. You should
promote continuous integration methods and tools. Continuous integration
ensures automatic builds and testing of an application at regular intervals.
This will reduce risks and will provide a more stable and directed development
8. There is no
‘I’ in Architecture. You should work together as a team. It’s the teams’
architecture, not yours alone.
9. It is very
important to your success and your team’s success to give all your teammates
enough freedom to exercise their own creativity and abilities. Create an
environment where they come and ask you for suggestions. Make sure developers
have the tools they need. Repetitive and mindless work should be automated.
Create standards for consistency.
architects must understand basic architecture and design patterns, recognize
when to apply patterns and be able to communicate to other architects and
developers using them.
11. You need to
balance Stakeholders Interests with technical requirements. It’s your job to
create functional, quality software for users while balancing with interests of
CEO, with ease of maintenance and learning for future programming staff.
12. Start with
a walking skeleton i.e. a minimal, end-to-end implementation of the system that
links together all main components. This approach gives us a short feedback
cycle which helps us find and address our mistakes early.
13. You should
be able to code your design. Don’t use a pattern, framework, technology or
server you haven’t used personally before. This will help you understand the
learning curve for your team better and your estimates for the efforts will be
14. You should
avoid shortcuts during the initial development phase of a project. Any
architectural problem or design flaw should be rectified as soon as encountered
when it is cheapest to fix.
15. You need to
take care of your customer’s customer. They are the end user’s and you need to
understand what all they will need even if not mentioned in the requirements.
Communicate your customer about these needs.
16. The end
user will access the system through the user interface. Better user interfaces
lead to happier customers, therefore, involve user interface experts at an
early stage and throughout product development phases.