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:

  1. High learning curve of new things
  2. Lack of info about problems which may come
  3. Lack of solid answers for problems which may come
  4. 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:

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:

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!