Ask HN: Software architects – what’s your typical day look like?

Feed stuff to chatgpt, feed it to build pipeline

I believe that the job description differs a lot from company to company.

From my experience, the best architects spent most of their time focusing on these things:

  1. Always understand what the current business priorities are.
  2. Design the overall system architecture so it covers all of the business needs, and nothing more. Always focus on keeping it as simple as possible. Even when people argue "lets do this some other way, because we might need it in the future".
  3. Fight the urge to use "latest and coolest" technology. Don't listen to consultants selling you unnecessary tech. Stick to what works. Even when it's boring. Explain it properly to your team.
  4. Maintain proper documentation. Focus on making it as simple as possible, easy to adjust and up to date. Otherwise its value will be close to 0.
  5. Use UML diagrams. Think about where the complexity of the given system is, and use only the most relevant ones. For example, if the complexity lies in complex workflows, use sequence diagrams or state diagrams. If the complexity lies in complex datamodel, use ERD diagrams.

But more often than not, architects also have to focus on other things, mostly related to DevOps, Platform Engineering and overall developer workflows.

[shameless plug] That's one of the reasons I founded https://stacktape.com - AWS-focused "internal developer platform" that allows developers to do this sort of stuff on their own, without involvment of architects, DevOps or others.

I’m not an architect, but used to closely work with one and it was a pleasure.

The key role that our architect played that brought immense value to us was being the integrator of teams. Teams had a high level of autonomy when it comes to implementation details which meant there could easily be “reinventions”, incompatibilities, and even narrow minded choices. Our Architect always had the big picture view across teams, almost always sat in our feature grooming sessions with valuable inputs, worked closely with product owners who bring in feature requests that may need integration of multiple services etc.

Above all, he was very active, and approachable to all teams instead of hiding behind barriers and occasionally bringing out UML diagrams. Several times, when we were debating which technical choice to make, held chime in with valuable points about what would be better if we were to integrate with another service, or something like “that team did this because blah, which might be relevant to you”.

A great mentor once told me about the poker analogy method of coping with situations you describe.

Let's say you are a great poker player. When you get dealt a good hand, you play it and end up loosing - does that make you a worse player?

Turns out even the best of all players loose quite frequently. What distinguishes them from others is that they make the best choices with the limited information they have at the time. They later go back and learn from any mistakes they have made and move forward.

When I was an architect, my job was to scale my knowledge and save others time. Not 10 minutes of googling, but several weeks or more for a team who would need to sound out a solution. An example would be spending an afternoon designing a slide that represented the main transactions we were building for as an M/M/1 queue (or other queue) so that devops could decide in a couple of seconds how many VM instances we were going to need, and the likely compute costs - instead of scheduling several meetings where they needed to sort out their internal power struggles of who was right to move the decision forward.

I might spend several days (or more) going through code and interviewing developers about how they implemented an authentication protocol so that I can draw it in BAN logic on a slide, which other projects can use to integrate their code with, and our certification/accreditation/infosec people can reason about so the project doesn't get spike stripped at the production gate and delayed a quarter while a post-hoc security analysis gets done on it.

I would meet with our vendors and tech service providers and establish whether they in fact provide the services they said they would, and what that physically means. A great example is whether an o365 tenant supports OAuth2 federated logins with non MSFT tenants or not, and how we are going to enroll users based on the amount of friction the realization of this feature causes(or not). Another one would be pushing standards down into development so nobody would roll their own protocols, and so I could have a short answer to what we implemented. You might see it as ticking a box, but an enterprise is like an airport, and some people get to fly while others don't. The ones who don't are usually stewing over some counterfactual.

I would meet with external consultants, often security and regulatory people, and provide them with the technical details and assurances that would keep them from taking a pound of flesh from the project in the form of a 6 week analysis engagement.

What makes an architect something different is they recognize that when there is direction or demand for a tech project, that creates opportunity for a lot of other very sophisticated technical people to inject themselves into the critical path of the project and use their leverage to extract money, management authority, and other concessions from it. As an architect, you see these people coming, and make sure they do not derail your tech.

I enjoy it because it's solving problems at a higher level of abstraction. I also like doing product, but the architecture urge sabotages that, as in product, solutioning comes at the cost of listening and scaling your listening out to architects to solution stuff.