What shall I expect from an architect? [closed]

Question

I am working for a huge multinational software firm, and have been on job for slightly over 1 year.

The architect of my team has 15+ years of experience.

Th architect:

• Gets off from work at 3pm. (The majority of my team start late & finish late)
• Refuses to do necessary designs for the project, such as drawing diagrams or providing documentations. ("I couldn't spend all my day drawing pictures")
• Doesn't write code. Struggling to provide unit tests to a block of code he copied from an example project.
• Showed no interest in trying out new technologies, even if they are potentially valuable to the team. We have to write PoCs for him.

Our manager shows interest in listening to our thoughts during meetings. I couldn't help but call out on some of these lunacies. He would get noticeably aggressive and impatient. My manager would then engage in a discussion with me, and the architect would say stuff like is this worth discussing for so long.

EDIT: I tried to make the question more specific. I am expecting the architect to:

1. Understand the basic interaction of classes/components of the current implementation.
2. Read the code.
3. Provide guidance and mentorship to the juniors. Challenge our implementations.
4. Hold code review sessions,
5. Design the architecture (class/component) from a grand view.
6. Be curious about newly emerged frameworks/technologies, and provide a PoC to test them out if he thinks it's useful to our project.
7. Do not say because this is a project of small scope so there's no design necessary. We implement it as easy as possible, even breaking established software principles.

Am I expecting too much from an architect?

EDIT AGAIN: I asked partially because our manager (the APO I mentioned) actually did point 3,4, to some extent 5, 6 (although not directly writing PoCs, we developers did that, as he brought these new techs up to us). I don't know if they are indeed the responsibilities of a manager, or should rather be the responsibilities of architects, if they have to be done anyways?

Regarding point 1 and 2, please do correct me if I'm wrong, but an architect should understand the architecture of the project inside-out? I am not exactly sure if he/she can if the architecture was not envisioned by him/herself, and also without thoroughly reading our code.

Answer 1

Your question is "should i keep voicing my thoughts".

The answer is yes. But do it politely.

There is nothing wrong with engaging in a software team and proposing new ideas and technologies, and it is a very rare and poor manager who does not support this.

The is something wrong if you go in thinking something is "lunacy" and then attack the person aggressively. You'll just make the architect dislike you, which will just make life more difficult. You use the word "lunacy" in your question, among other more aggressive terms.

The majority of your question, however, reads poorly. You express that you feel the architect is incompetent, effectively. However a software architect cares about very different things from a software engineer.

Architects care about how the product fits into the existing ecosystem. They understand how the various bits of data flow from one end of an org to another, and how to best ensure data is reliable and available.

Understand that you shouldn't be attacking the architect, because they're worried about different things than you, and they have different skillsets.

As a rule of thumb:

You need to learn to be polite and work on the problem, not the person.

After all, you're all there to find solutions to the same problem.

---

As for your new points:

1. Understand the basic interaction of classes/components of the current implementation.

Why do you want this? If you want it will help the team, then raise it to the manager to start having training sessions about the design/implementation.

2. Read the code.

Why do you want this? If the person isn't a developer then they have no real gain from reading the code.

3. Provide guidance and mentorship to the juniors. Challenge our implementations.

Ok, I understand this. But you need to ask this person and their manager to create time - say an hour or two or so a week - to do this.

4. Hold code review sessions,

Why do you want this? This is highly dependent on the team and what the manager of the team decides. In some teams, for some projects, code review sessions are great. In other teams, a couple of leads pushing "bad" code back to get fixed online is great.

5. Design the architecture (class/component) from a grand view.

Why do you think they are not? What does "grand view" mean? And grand views take time - look, I myself prefer simple code that works that is then, as it is upgraded, fixed with better design patterns. Design patterns are heavy. There's no point having a factory pattern thing if it only makes one thing in one way. Add the pattern in when you need to make it two or, preferably, three ways.

6. Be curious about newly emerged frameworks/technologies, and provide a PoC to test them out if he thinks it's useful to our project.

Hm. Teams are mostly paid to execute business tasks, not investigate emergent tech. If you want to investigate emergent tech, then do it on your own time. Make the PoC on your own time.

7. Do not say because this is a project of small scope so there's no design necessary. We implement it as easy as possible, even breaking established software principles.

Disagree here - if a project is very small, or the lifetime is going to be short, or you're unsure if anybody needs the project, then it's better to make it small and simple and fast. You can make it fancy later on when there's a need.

---

Just because a design pattern exists doesn't mean it has to be used all the time. McDonald's makes more money than the best gourmet burger joint in the world - because they're fast and cheap. I'm not saying they're good, and heck I don't eat their food - but while it's nice to know how to make a fancy burger, it's even nicer to make money.