Second part of being a good architect
This article is a follow up to the previous one about being a good software architect. In this one, I would like to add a few of points which are worth remembering.
49. Janus the Architect
As mythological Janus, you as an architect should behave as you would have “Two heads”. One is looking forward into the future and the other one is looking into the past and draw conclusions. You want to observe and change the process to make it better. You want to see business expectation and required changes to match the expectations. Be a good listener and evaluator.
60. Start with a Walking Skeleton
Create basic end-to-end architecture as a skeleton, and then incrementally add required features. Do not start with big up-front design.
61. Share your knowledge and experiences
Whatever you know, share it with other people, talk about that. It helps validating and sharing your knowledge. It makes it solid in your mind - discussing things also gives you ability to evaluate different aspects.
63. If you design it, you should be able to code it.
Architect is just another developer. If you came with given architectural solution, remember that you may need to implement that. There are 4 things worth remembering when adding cool features with a new tech stack:
- High learning curve of new things
- Lack of info about problems which may come
- Lack of solid answers for problems which may come
- Introducing unnecessary risk
64. The ROI variable
Whenever you make a decision for an architecture or way for developing it, think about returned value from such investment. For instance, writing tests is an investment, but in return you get trust and you’re sure about new changes.
67. Understand the impact of change
Understand and lower the impact of change by:
- making small, incremental changes
- building test cases and running them often
- tracing dependencies
- automating repetitive tasks
70. “Perfect” is the Enemy of “Good Enough”
While designing the architecture or implementing it, don’t try to achieve the perfect thing, try to achieve just good enough. Good enough means good performance, easy maintainability, clarity and concise documentation. Usually designing the perfect architecture leads to something what is really hard in maintain.
73. The Business Vs. The Angry Architect
Don’t be overconfident. Say less than you listen. Learn to accept certain things which you don’t like from the business context or just leave it for a better business. Establish good relationship with business people. Behave as a trusted advisor
81. Choose your weapons carefully, relinquish them reluctantly
While selecting a new technology, always consider trade-offs of such decision. When a technology is new, wait until its hype settles down. Talk with others, research and seek for constraints and problems with a new technology before using it on production.
84. Choose Frameworks that play well with others
Select frameworks which are small and focused, which don’t overlap each other features too much since it creates complexity. Select such a framework, which fits into your problem. For instance, if framework is rich in many different features, be sure you’re using most of them, not only small part.
85. Make a strong business case
People believe what they can see. At the beginning of the project, it’s really hard to see new features - since it’s just a beginning. Make strong & solid business case in order to make good impression for the stakeholders. Five useful cases which are good while selling the architecture:
- Establish the value proposition - warranty of this what will be delivered, what value will be delivered for the business.
- Build metrics to quantify - metrics for measuring the improvements by delivered architecture in context of the business
- Link back to traditional business measures - translate delivered value into money, money, which business can earn or save.
- Know where to stop - have a roadmap with milestones, in order to see the correlation between delivered part of architecture and value for the business.
- Know when to sell the ideas - find aproprieate moment for that.
86. Pattern Pathology
Be aware that patterns may cause over-engineering of the system, making it hard to understand and maintain. Patterns are good but only when you really understand the idea behind them and which problem they solve.
88. Don’t Be Clever
Create as simple as possible solutions for the architecture. If something is complex and “clever” it will be brittle and expensive to maintain. At the beginning create simple one purpose components, and when you see duplications, make it a bit more generic in order to reuse e.g. components.
97. Great software is not built, it is grown
Build the architecture in small steps - deliver & improve. It’s not a good idea to start with a big up front design, since it’ll fail. Building software requires small steps, looking over the impact & improving what has been done currently.
It would be perfect to remember all of these points, but we are humans and we don’t have this ability. Just remember that here you can find these points. If you have any architectural questions, let me know about them, I am open to help you with them. Thanks Wojtek for your feedback to the article!