Inventory the mistakes that software architects often make

Have you ever thought about using icons to represent the process of making coffee? or other ordinary things, such as bathing? In fact, I think the question was a little sudden, the answer to this question is certainly not answered.

For other things that are a little bit more cumbersome, such as software development, a small amount of design work is useful or necessary.

The question is, is architecture design worth the time and effort? Well, first answer the question: Can early design reduce risk in the project? The greater the goals and challenges of the project, the greater the risk and the more difficult it is to successfully complete.

How to identify risks: The easiest thing to do is to start from the requirements and find the things that look hardest to achieve.

Gathering demand is the basis for deciding what to do and how to do it. Of course, sometimes the problem that causes the project to fail has arisen from the outset, with some assumptions underestimating this critical phase and fundamentally shaking the architect's role:

1. Demand analysis is the responsibility of others

(business) domain-driven architecture choices, not the other way around, (business) requirements create architectural problems. At least you have to assist the business Analyst (for Business analysis).

2. I write code while learning domain knowledge

While software prototypes (development) are a good way to reduce engineering risks and identify the most difficult problems, writing code is a waste of time in analyzing business areas. Modeling in advance is the best way to propose output.

3. The relevant parties have fully understood the need

It is difficult to communicate thoroughly between people. The role of the software Architect is hard to do if people don't understand what you're doing and why.

4. Business areas and architectural decisions are irrelevant

Developers may copy the schema (design) from past projects. It is possible to follow the standards of the company, but ignore the reasons for the choices they made before, and they probably don't know the actual requirements for the current project.

5. I understand the need

At least you should have a demand document in your head, but designers should use models to enhance reasoning and expose risky but not very clear aspects.