Software-Architekt ist eine Rolle, die ein Entwickler zumeist phasenweise einnimmt, nämlich dann, wenn es um den Architekturentwurf geht. In einer Architekturentwurfsphase geht es um die grundlegenden Komponenten des Systems und deren Zusammenspiel. In einem realen Projekt, welches nicht nach dem Wasserfall-Modell abgearbeitet wird (...und das sollte heutzutage selbstverständlich sein), gibt es zumeist viele solcher Abschnitte wo man sich mit der Architektur befassen muss. In einem Vorgehensmodell wie SCRUM z.B. beschäftigt man sich zu Beginn eines jeden Sprints eigentlich immer auch mit Architekturfragen.
Es kann also jeder Entwickler situationsbedingt auch die Rolle des Software-Architekten wahrnehmen, wenn es erforderlich ist. Das hat zunächst einmal gar nichts mit einem bestimmten Berufs- und Bildungsweg zu tun. Es gibt große Organisationen, welche sich explizit "hauptberufliche" Software-Architekten leisten. Das kann gut gehen, wenn die entsprechenden Personen nicht abgehoben, wie von einem Elfenbeinturm, agieren und den Entwicklern ihre heiligen Konzepte zur Implementation nur "vor die Füße" werfen, sondern wenn diese in die Teams integriert sind und sich auch als Coaches verstehen. Ein guter Architekt entwickelt nämlich auch sehr viel, z.B. Prototyping, ein schlechter Architekt malt nur Kästchen oder UML-Diagramme...
Noch einmal zur UML: die UML ist nur eine Sprache; sie ist keine Methodik und auch kein Vorgehensmodell. Man kann diese Sprache in unterschiedlichsten Ausprägungen verwenden: als Kommunikationsmittel am Whiteboard oder Flipchart im Team, bis hin zu einem durchgestylten model-driven Software-Development Ansatz inkl. Code-Generierung. Wichtig ist aber zu verstehen, das es eine Sprache ist, und eine Sprache muss man erlernen!
