Software Architect?

 Hi everyone, today's blog is quite a thrilling one. I found Martin Fowler's article very interesting and with some hot takes that I wouldn't have thought about myself. We are presented with the idea that the concept of an architect and what they should do is very subjective and in a way, as he states it, a social construct of what developers think is important for the system they are going to implement. You could say that there is a lot of responsibility in the architect's hands for what the end product will look like, deciding which components are important and even essential to the main structure of the system. By this definition it kind of makes project management and software design and architecture as a single person mission. 

As the article says, I agree that this is too much responsiblity for what we would call a software architect. Deciding on whether or not something is to be considered important for the development process should be a collaborative effort. Engaging with all the teams involved, being developers, testers, requirement people, etc. I liked the way the text puts it, an architect should be instead seen as a guide, an element that connects all the pieces in the puzzle and makes them work together, not because the architect states what needs to be done, and what should be considered important, but because they're constantly interacting with their team, listening and making sure that all requirments from the diverse teams are met. 

We can relate this mindset, this approach to software developing to what we now know as agile techniques, which explore constant interaction, requirement verification, and flexibility towards change. In a way, a software architect in my opinion is what keeps the wheel turning, supported by their team's input.