Who Needs an Architect?

In Who Needs an Architect? By Martin Fowler, we get some flashbacks from our previous reading on Software Architecture in the book Code Craft. By Fowler's description, Architecture is design, if design were a turkey pretending to be a peacock (that's how I interpreted it, anyway). He reminds us of the traditional description of architecture (The architecture of a software system (at a given point in time) is its organization or structure...)  but also presents us with a more pragmatic approach. A shared understanding of the system's design. So the people who care and understand the design are, as one might already assume, the software architects. They are classified into Architectus Reloadus (the one who calls the shots), Oryzus (the one who hunts for issues, and brings the team together). They operate similarly to how a Captain and a Quartermaster work on a ship in pirate times, perhaps a good article could be written about the similarities between them and software architects, just a thought. In the last section, Fowler entertains the idea of getting rid of Architecture entirely, based on the premise that irreversibility can be dealt with. I see it this way: If your building your software, you need the architects to tell you how the overall design looks like, and where to target your efforts moving forward. This seems very similar to Traditional software design methods, like Waterfall, linear and irreversible. On the other hand, agile methods are all about granting the software engineers the privilege to undo and redo as they wish. Why plan everything at the start if changing anything in software is easy?

He surely sells it better than I do, no doubt. That is mainly because, if I do it right, I'll do it once, so I better make sure I do it right. That's just my thought, I'll stick to design every day of the week, agile or not.