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.
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:
- Enterprise Architecture Patterns - framework for high-level architecture
- Application Architecture Patterns - defines applications or subsystems should be designed
- Integration Patterns - for designing & communicating
- 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.