The key point is about balancing between architectural role and software developer role.
Based on this book: “Fundamentals of Software Architecture by Mark Richards and Neal Ford (O’Reilly). Copyright 2020 Mark Richards, Neal Ford, 978-1-492-04345-4.”
Bottleneck trap is defined as following:
The bottleneck trap occurs when the architect has taken ownership of code within the critical path of a project (usually the underlying framework code) and becomes a bottleneck to the team. This happens because the architect is not a full-time developer and therefore must balance between playing the developer role (writing and testing source code) and the architect role (drawing diagrams, attending meetings, and well, attending more meetings).
And then the solution proposed by the authors
One way to avoid the bottleneck trap as an effective software architect is to delegate the critical path and framework code to others on the development team and then focus on coding a piece of business functionality (a service or a screen) one to three iterations down the road. Three positive things happen by doing this. First, the architect is gaining hands-on experience writing production code while no longer becoming a bottleneck on the team. Second, the critical path and framework code is distributed to the development team (where it belongs), giving them ownership and a better understanding of the harder parts of the system. Third, and perhaps most important, the architect is writing the same business-related source code as the development team and is therefore better able to identify with the development team in terms of the pain they might be going through with processes, procedures, and the development environment.
So my question is about why focusing on a business functionality could not become a bottleneck? (if the architect become a developer of this part). And why it(business functionality) is not critical path of the project. In this example critical path of the project is an underlying framework code.
Is that because a business functionality is usually simpler than underlying framework? I understand, an architect is still doesn't have enough depth on the topic, and because he has other duties it may affect the quality of his job and become a bottleneck. But Anyway architect is not a junior, he will be able to have a hands on experience, with some efforts, so what is the problem? During this time, there will be bottleneck trap?
Is there exceptions from this rule? because from what I see, usually architecture roles does imply that you have a great depth of some technology and can take a lot on you doing the same job as senior developers and at the same time you are supposed to do architecture decision (whatever). From what I understand the books opposes to this.
this question is relevant a bit: Should application architects write code?
For example there is an answer that:
business and functional architects: they are concern with business operations and functions workflow, and they actually should not ever code, because they have to be able to abstract themselves from any kind of implementation, and they must produce functional specifications which leave the technical solution open.
So the guys with quite a big reputation says that business architects should not code.
So how does it work in the reality?
P.S. Oh, I love this so much! Each statement is making a perfect sense at a first glance however we are gathering them together it becomes more chaotic. So I am trying to understand: is it because I don't understand something or it is chaotics because of its nature?
So my question is about why focusing on a business functionality could not become a bottleneck? (if the architect become a developer of this part). And why it(business functionality) is not critical path of the project. In this example critical path of the project is an underlying framework code.
Because the application can contain A LOT of business features with different priorities, so architect tacking some time to code the less important one should not become a bottleneck for the whole project and less important business features are clearly not a critical path.
On the other hand the (shared) framework/infrastructural code usually is a dependency for all (or almost all) others and as something which is base for other projects for obvious reason can quickly become a bottleneck if architect takes the full ownership of it and can work on it only part-time. So in this case the argument is totally valid and framework/critical infrastructure code should be delegated to development team (quite usual approach is to have a designated team to handle those, even sometimes as part of architecture team, while architects perform high-level supervision, maybe conduct code reviews).
So how does it work in the reality?
The answer is simple - "it depends". Software development practices tend to differ from place to place vastly and there is no silver bullet or answer which suits all cases.
usually architecture roles does imply that you have a great depth of some technology and can take a lot on you doing the same job as senior developers
Quite often this can be the case but it is not the rule, you can have a successful architect whose language/technology stack differs from the main in the company, in this case architect would not do a lot of "hands on" stuff obviously.