re: What should I know to be a software architect? VIEW POST

FULL DISCUSSION
 

How to be a good software architect?

Talk!

https://zapier.cachefly.net/storage/photos/c5832e50694763e30a7ad573dc0357fc.png

Software architecture is social work. It's not rare the software architect is also the project in chief, and it could also be a CTO.

We, as an architect, we must be able to answer 3 questions: what? how? and with what?

  • A software architect must understand what the requirement is. So, how we know this?. Talking, we talk with the product owner / who request the project and talk with all parts, including the team.

  • Then, the software architect must evaluate the resources. For example, the goal is to build a Facebook in a year, but we have 3 developers juniors. So, is it possible?. No, without extra resources, so let's talk with the guys of HR if we are able to hire new developers, or let's say if we could increase the time or lower the requirements.

  • About resources, let's say it is a startup and the company hasn't picked a technology, so, we should choose a technology based on the resources (developers, licenses, server if any) and start marking a roadmap. For example, if the team is aligned with Visual Basic 6 and it is enough to work, then go ahead, and we will develop with VB6. However, if we are a startup (there is not technology or team), then we could pick the best technology for the job.

  • And finally, we create the database model, screen mockup, use-case (if any), UML (usually they are useless trash, but some people love it) and such. Then, can we start?. NOPE. We should talk (again) with the product-owner, we should show the mockup, the use-case (or workflows if any) and the product-owner could ask changes.

 

What the fk, that isn't an architect at all. Architects aren't people who who write up diagrams and talk to product owners. At least, the dozen I've met look nothing like that.

 

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 like your answer, even though stereobooster had something different in mind. Your answer matches pretty good what the role of a software architect is about in the company I work. It's not a software company. This is probably the major reason for the focus on mediating between business and IT.

code of conduct - report abuse