Beste Antwort
Es gibt keine formalen Definitionen dieser Rollen, die von als Standard weit verbreitet sind Organisationen, daher wird es viele Variationen und lokalisierte Kontexte geben.
Als allgemeiner Leitfaden verwende ich die folgenden Definitionen:
- Technischer Architekt – Ein Spezialist für Bereiche, die ausgerichtet sind zu Infrastruktur, Netzwerk und Sicherheit.
- Solution Architect – Ein Generalist, der für projektbasierte Lösungen verantwortlich ist, die alle Aspekte einer Lösung berücksichtigen (z. B. Auswirkungen auf das Geschäft, Anwendungsänderungen, Überlegungen zu Daten und Informationen sowie die Technologie, die Dies alles untermauert) und hoffentlich auch Kundenüberlegungen.
- Hauptarchitekt – Jemand mit einem breiteren Verantwortungsbereich als die oben genannten Rollen. Dies kann sich auf eine Geschäftsdomäne, ein größeres Arbeitsprogramm oder ein gesamtes Unternehmen konzentrieren. Es wird auch häufig von Beratungsunternehmen verwendet, um ein Maß an (Erfahrungs-) Überlegenheit gegenüber anderen Architekten im Team vorzuschlagen. Normalerweise haben sie eher allgemeine Bedenken als sich auf eine einzelne Architekturdomäne wie die Infrastruktur zu konzentrieren, aber das ist nicht immer der Fall.
Ich hoffe, das hilft. Es ist wichtig, sich daran zu erinnern, dass es solche gibt Keine akzeptierten Standards, daher sind die Begriffe selbst spezifisch für die Umgebung, in der sie verwendet werden.
Antwort
Zunächst ist es wichtig, die Softwarearchitektur von einfachen Best Practices zu unterscheiden. Ein guter Softwareentwickler kann hervorragend codieren, ausgezeichnet und detailliert vorgehen und viel Einblick in das Problem haben, ist aber möglicherweise kein guter Architekt.
Zumindest ein guter Der Architekt sollte über die folgenden Fähigkeiten verfügen:
Ein Architekt ist hervorragend bei der Problemzerlegung . Problemzerlegung ist die Fähigkeit, ein Problem auf praktisch jeder Ebene zu erkennen und in die Schritte und Teile zu zerlegen, die zur Implementierung erforderlich sind. Ein guter Softwarearchitekt kann eine Aussage wie „Unsere Flugsicherungssysteme sind unzureichend und wir brauchen ein besseres Design“ treffen und kennt die Fragen, die gestellt werden müssen, um das Problem in erreichbare Komponenten zu zerlegen und diese Komponentenziele in erreichbare Teilprojekte zu zerlegen und zerlegen diese Teilprojekte in erreichbare Programmieraufgaben. Ein guter Architekt kann diese Dinge auf jeder Ebene oder in jedem Maßstab tun, von der Vorstellung eines Softwareprojekts mit Milliarden Zeilen bis hin zum Verständnis der besten Methode zur Implementierung eines Algorithmus zur Bewältigung unzuverlässiger Verknüpfungen. Die Skalierung ist irrelevant, da der Prozess immer derselbe ist.
Ein Architekt versteht Schnittstellen . Schnittstellen, ob in Form von Protokollen, Funktionsbibliotheken, Klassenschnittstellen oder Schemata, sind das wichtigste Werkzeug, um die Komplexität von Projekten zu verwalten, wenn es unabhängige Auftragnehmer und Implementierer gibt. Wenn ein Architekt den Prozess der Definition klarer, eindeutiger Schnittstellen kennt, die logisch vollständig sind, kann er viele Menschen in die Lage versetzen, Teile von Systemen zu erstellen, die sich leicht verbinden lassen, um ein größeres Ziel zu erreichen.
Ein Architekt versteht, dass Komplexität der Feind ist, und beherrscht die Programmierwerkzeuge und -paradigmen, die erforderlich sind, um die Komplexität aller Komponenten zu verringern, die Komplexität der Schnittstellen zu verringern und eine minimale oder keine Redundanz der Implementierung sicherzustellen der Funktion. Sie können Algorithmen und Implementierungen, die zu spezifisch oder zu allgemein sind, schnell erkennen und die Entwickler bei der Erstellung von Komponenten unterstützen, die genau die richtige Funktion ausführen. Die Werkzeuge zur Verwaltung der Komplexität sind häufig Dinge wie das Ausblenden von Daten, objektorientierte Programmierung, selbstvalidierende Systeme und umfassende Testpläne für Standardschnittstellen. Ein guter Architekt ist jedoch nicht dogmatisch in Bezug auf Werkzeuge und Technologien, da er ein umfassendes akademisches Verständnis der Grundlagen und Gründe hat, warum das Verstecken von Daten funktioniert und warum bestimmte Sprachen gute Entwurfsprinzipien unterstützen und andere nicht.
An Der Architekt ist ein guter Kommunikator, ein guter und produktiver Schriftsteller und Dokumentator und spricht sowohl die Programmiersprache als auch die gemeinsame Sprache der Beteiligten Neben einer guten Kommunikation kann ein guter Architekt konkrete Gründe für Programmierpraktiken anstelle von Meinungen angeben und bietet seinem Team eher Einblicke als Argumente. Sie befürworten und suchen nachdrücklich die Meinung des Benutzers zur Eignung für das eines eigenen oder der am Projekt beteiligten Programmierer.
Ein guter Architekt ist ein guter Leiter und kann hervorragend den Respekt aller technischen Leute erlangen Sie arbeiten mit .In der Regel bedeutet dies, dass sie über ein hohes Maß an Fachkenntnissen verfügen, in mehreren Sprachen gearbeitet haben und zuvor Architekt waren oder ihre Fähigkeit unter Beweis gestellt haben, Systemdesigns zu erstellen, die angesichts von Veränderungen flexibel geblieben sind.
Viele Definitionen enthalten eine Reihe von Schlagworten, die Methoden wie datengesteuertes Design, agile Programmierung, bestimmte Sprachen, Plattformen und Toolkits hervorheben. Diese Dinge sind aktuelle Bezeichnungen für verschiedene Techniken, deren Grundlage gut verstanden werden muss, weil sie nicht akzeptiert werden derzeit in Mode. In vielerlei Hinsicht sind die Hauptfähigkeiten eines Architekten Erfahrung, Intelligenz, die Bereitschaft, hart zu arbeiten und eine praktische Rolle zu übernehmen, eine gute Intuition und die Fähigkeit, Probleme mithilfe von Logik zu lösen, damit die Schlagworte der Branche kommen und gehen. Ihre Entwürfe bleiben nützlich und relevant.
Meine obige Definition beinhaltet absichtlich keine Projektmanagement-, Planungs- und Managementfähigkeiten. Die Aufgabe des Architekten besteht darin, gute Systeme zu erstellen und keine Teamprobleme oder Budgets zu lösen. In der Tat ist es am besten, wenn diejenigen mit Budgets und Teamproblemen lediglich Stakeholder sind, die dabei helfen, eine der Einschränkungen zu definieren, mit denen sich der Architekt befassen muss wenn es Teil ihres Designproblems wäre.