re: The role, skills, and duties of a software architect VIEW POST

FULL DISCUSSION
 

Thank you for this. It's what I just need at this moment.

I would like you to help me clarify something, though. You wrote: "In some cases, an architect may work in an established enterprise company and hand down instructions on technology stacks to the developers. At the other extreme Agile development, a team may work without the involvement of an architect."

My question: is the Agile development process, and "processes" in established companies mutually exclusive? Put differently, is the Agile development process exclusive of an Architect role?

 

Thank you for your comment and your question!
The situation you asked about cannot be considered as the confrontation of the method to the need of a software architect. I'd say, that it is rather an experience that while using an Agile method you don't use a software architect. These two options are not mutually exclusive. You can read about the agile method in my article dev.to/iriskatastic/top-6-software...
You can use a software architect, but it more depends on a complexity of the project. If there's nothing new to implement and you don't need to solve new problems or face something outstanding to develop - you can avoid asking the help of a software architect. In other words, you need a software architect for high-design choices. If there's nothing difficult or you repeat the project you've done before you can use the waterfall or the agile method with no software architect.

 
 

Just going to offer an alternative POV here.

I have been in an official "Software Architecture" role in a larger company, had to work with software architects in an large enterprise where I worked at one point, and am now a Senior Developer at a small startup. I have been through very rigid waterfall methodologies, and am now involved in very agile DevOps style delivery at my current job.

Through this gamut of experiences, I feel what the most important thing is not necessarily who does software architecture, but that it is thought about and agreed upon before too much development is done. Sure in an enterprise situation, where they can hire someone to "pass on" instructions, the formal role of a software architect can definitely work. In my current position of fast moving, rapidly iterating and evolving code, we have a lot of conversations about software architecture and figure it out collaboratively, which also works.

If software architecture is not considered, or is not agreed to, then a whole slew of problems can arise, that can be worse than if you simply make a wrong choice in the architecture. The most severe I have seen are things like: no scalabilty (as opposed to limited scalability from a wrong decision), unmaintainable code (resulting in massive rewrites), and various culture problems.

So I guess, depending upon why you are asking the question, maybe the answer is "make sure software architecture is considered, and pick a method of making sure that happens that works for your and your team".

code of conduct - report abuse