I would say this is not quite the definition of software architect
A software architect must understand what the requirement is.
Yes, but as well as many other people like a business analysts, managing developer, tech lead, product manager. This is not unique to architect, this is not a distinctive feature.
Then, the software architect must evaluate the resources
Well this is sounds like a manger or tech lead or director of engineering or CTO to me.
And finally, we create the database model, screen mockup, use-case (if any)
Sounds like business analysts or managing developer or architect.
I mean those all are good and valuable things, but they don't give you any deep insight, for example how functional paradigm and OOP can be viewed as two sides of the same coin. RIght? I mean at which point of talking to product owner about requirements you pause and "Ah now I see how Y-combinator relates to McCarthy's eval".
UPD Maybe title is a bit confusing, but I extended actual question in the text. I asked more about how to get deep understanding.
Thank you for the answer. This is for sure good career advice. But I would say this is not quite an answer to my question about deep insight.
I agree with Jorge Castro in this point of view. Even you have the deepest knowledge of coding and software architecture, without those you cannot be a good software architect.
As a software architect (Martin Fowler for example, not about any job role), you must understand requirement in order to match you solution. Over engineering or under engineering is both not good.
In a small team, software architect is the same as CTO in a big company. CTO cannot decide everything for every team. Even if you are just developer in that team, knowing your teammates capabilities will help you give more properly suggestions.
In the modern engineering methodology, evolution design is the top choice as it improves agility of the project. Every developer has to know how to model the business, why software project failed (to not repeat it), why we should do this and not do that...
I know it's an old topic but I still want to say. The confusion is not in the title, but in the fact that architects are different.
Jorge Castro is talking about Solution Architect. And what interests you is the Application Architect. These are different areas, which is why you are talking about slightly different things.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I would say this is not quite the definition of software architect
Yes, but as well as many other people like a business analysts, managing developer, tech lead, product manager. This is not unique to architect, this is not a distinctive feature.
Well this is sounds like a manger or tech lead or director of engineering or CTO to me.
Sounds like business analysts or managing developer or architect.
I mean those all are good and valuable things, but they don't give you any deep insight, for example how functional paradigm and OOP can be viewed as two sides of the same coin. RIght? I mean at which point of talking to product owner about requirements you pause and "Ah now I see how Y-combinator relates to McCarthy's eval".
UPD Maybe title is a bit confusing, but I extended actual question in the text. I asked more about how to get deep understanding.
Thank you for the answer. This is for sure good career advice. But I would say this is not quite an answer to my question about deep insight.
I agree with Jorge Castro in this point of view. Even you have the deepest knowledge of coding and software architecture, without those you cannot be a good software architect.
As a software architect (Martin Fowler for example, not about any job role), you must understand requirement in order to match you solution. Over engineering or under engineering is both not good.
In a small team, software architect is the same as CTO in a big company. CTO cannot decide everything for every team. Even if you are just developer in that team, knowing your teammates capabilities will help you give more properly suggestions.
In the modern engineering methodology, evolution design is the top choice as it improves agility of the project. Every developer has to know how to model the business, why software project failed (to not repeat it), why we should do this and not do that...
I know it's an old topic but I still want to say. The confusion is not in the title, but in the fact that architects are different.
Jorge Castro is talking about Solution Architect. And what interests you is the Application Architect. These are different areas, which is why you are talking about slightly different things.