27 important architectural points, first part

Some time ago I read a book about 97 things worth remembering while being a software architect. I would like to share with you a bit shorter version in two parts, based on 27 ones which I found important to me. So, let’s begin!

1. Don’t put your resume ahead of the requirements

Use right technology for solving problems, not because of it is new and shiny, but because it is the proper tool for given job. Usually when you select a tool which is shiny, on the later step it might become a problem as you may not seen issues with that. Have a good reason for selecting a tool.

4. Communication is King; Clarity and Leadership its humble servants

Use whiteboards for explaining ideas and issues. Record them or take pictures of the pic on whiteboard. As a leader, create collaborative environment in the team, where everyone is able to share his opinions and suggestions.

5. Architecting is about balancing

Balance technical requirements between stakeholders. It means, that you should balance technical aspects of the implementation and business needs. For instance you should not modularise the system, if the business doesn’t require that.

8. Skyscrapers aren’t scalable

Deploy one component of software at the time. When necessary and possible, split the system into smaller components. In this way you can spread technical risk in time. When one component is failing, you know it immediately. So use incremental deployments, component-by-component. Deploy early and often. It also forces you to define better interfaces, which are more consistent.

10. Quantify

Use numbers for requirements, not just nouns and fancy expressions. Instead of “lots”, use “2.000 users”, instead of “fast”, use “20ms”. Don’t accept any “requirements” which are not specified in numbers.

13. It’s never too early to think about performance

Measure performance early and often. Check it from the very beginning to have a base line from which you can say “OK it’s getting slower”. Also, measuring performance from the beginning may be helpful, while having a not functional requirement about the performance. Measure performance by automated testing and save the results after each of the test. Also, it allows you to scope down to the place where is the cause for worst performance.

17. Business Drives

Act as a bridge between business and the development team. Understand ROI (Return of investment). Make appropriate decisions about the technology according to ROI. Consider value and cost of adding a new feature. Communicate in a proper way to the development team, why they won’t use given technology. Present information from the business to the development team using whiteboard. Have feedback loops between development team & business - e.g. fast releases. Protect the dev team, that they don’t make any business decisions - decisions are made by the business.

18. Simplicity before generality, use before

Firstly create solution for a specific case, and later, make it generic if it is necessary, instead of firstly making it generic. While looking for for instnace for a library, use the simplest one, and only on the later step, if necessary use more complex one.

19. Architects must be hands on

Understand the underlying technology. Be confident of all aspects of the technology. While talking with business guys, represent all members of the team. Present confidence while talking with business. Understand all levels of the technology - from the network to component interfaces. The same with tools, for instance an IDE.

22. Architectural Tradeoffs

Good architecture is about making tradeoffs and selecting the appropriate good and important things, because every solution cannot be selected. There is a story about a Swedish ship, that was supposed to be good at battle and good at transporting people. It was impossible to have both things at the same time, and the ship failed.

Tools for making tradeoffs: * Architecture Tradeoffs Analysis Method * Cost Benefit Analysis Method

25. Scope is the enemy of success

It’s always a good feeling to have a big project, but it is not always a good idea. The issue is that when project’s growing, the probability of success is decreased. Scope down the requirements and keep only the important ones, by understanding the real needs, slicing work into smaller pieces, prioritising work, delivering valuable results as soon as possible. Build the simplest thing that possible could work.

30. Understand The Business Domain

Understand the business domain. Without this knowledge, it’s hard to make good decisions in context of a solution. Knowing the domain helps picking better patterns for new challenges, e.g. SOA for an insurance company. Knowing business trends helps understanding impact on the produced software. Understanding specific goals of business helps specifying better requirements for the system, for instance high availability for a hospital software.

33. Give developers autonomy

Developers should have autonomy - especially if your previous role was a developer and you feel, you need to control all their movements. Work on higher level of problems, e.g. if a documentation is not clear, improve it, if business domain is wrong, correct it. The best idea is to have environment where developers come up with decisions on their own, instead of moving them in the proper direction.

42. Talk the Talk

Use different kind of patterns to communicate with others stockholders in effective & clear way. Families of architecture & design patterns:


It would be perfect to remember details of all the points, but we are humans and we don’t have this ability. Just remember that here you can find the important points. If you have any architectural questions, let me know about them, I am open to help you with them. In a week I’m going to release the second part, the rest of the important points. These points are taken from the 97 Things Every Software Architect Should Know book.

Back