Aufbau einer Architekturabteilung

Question

Etwas Kontext vorab:

Stellen Sie sich vor, dass ein Unternehmen mit mehr als 200 Entwicklern endlich ein mehr oder weniger unabhängiges Architekturteam/eine mehr oder weniger unabhängige Architekturabteilung aufbaut.Das Software-Portfolio bestehend aus über 20 „Projekten“/Anwendungen unterschiedlicher Größe in der Produktion wurde von Teamleitern/technischen Leitern betreut, die auch für die „Architektur“ des Projekts verantwortlich waren.

Aus der Notwendigkeit heraus, die Architektur zu konsolidieren und zu kontrollieren und neben dem notwendigen Wissensaustausch bestimmte erforderliche größere Überarbeitungen an den Systemen als Ganzes zu ermöglichen, beschloss das Unternehmen, eine Architekturabteilung einzurichten.

• Was sind die TUNs und NICHTs eines solchen Unternehmens?

• Aus welchen Personen besteht ein solches Architekturteam?

• Was sollten ihre Verantwortlichkeiten sein?

• Was liegt außerhalb ihres Geltungsbereichs?

• Welche sinnvollen Übergangsstrategien gibt es für das Unternehmen?

• Wie kann man verhindern, dass man jedes Mal, wenn jemand „das Architekturteam“ erwähnt, einen schiefen Blick zuwirft?

• Hat Ihr Unternehmen einen solchen Wandel bereits erfolgreich durchgemacht?
  Warum ist es gescheitert?
  Warum war es erfolgreich?

Das sollte nicht eine Diskussion über „Was ist Architektur?“ sein (was sehr eng damit zusammenhängt ;).

Die wirklich interessanten Punkte wären akzeptable/realistische, vielleicht sogar reibungslose Möglichkeiten, ein solches Team zu installieren, abgesehen natürlich von einigen Warnungen vor Schlachten, die besser gar nicht erst begonnen werden sollten.

Answer 1

Hier sind ein paar Fragen, die darüber nachgedacht werden sollte:

• Was das genaue Mandat für das Architektur-Team ist?
• Was ist das lieferbare Architektur Team? Ein Rahmen, Richtlinien, Umsetzung helfen ... Oder sind sie nur Architektur Astronauts ?
• Ist dies nur für Anwendungen, für die Zukunft, oder wird dies eine Rückportierung sein?
• Wer für Zurückportieren ist verantwortlich? (Und wir Budget bedeuten hier ...)
• Wird es Mittel bereitgestellt, um das updates zu testen?
• Ist das Architecture Team echten Muskel hat, oder Wille des Management faltet, wenn die erste Gruppe über die 4 Monate grouses es dauern wird, um die Änderungen zu implementieren ...
• Wie werden Sie mit der Reibung zwischen den einzelnen Projektgruppen befassen und dem architure Team (und es wird Reibung sein?). Opportunisten wird dies als eine wunderbare Gelegenheit, Jockey für Position ...
• Seien Sie sich bewusst, dass dies in erster Linie ein politisches Spiel sein wird ...

Mein Freund, Sie haben einen harten Weg vor ...

Die ersten Schritt ist kristallklar sein auf das, was die Architektur Team erreicht werden soll.
Warum setzen Sie das Team vor Ort?
Versuchen Sie, alle Anwendungen zu vereinen, einen gemeinsamen Rahmen, was?
Was ist das Mandat und die Vision für dieses Team?

Wer die Führung in diesem Team besser hat Kick A ** soziale Kompetenz.
Es sollte nicht die brillanten Codierer sein, den den star wars Titelsong pfeifen und Lichtschwert Geräusche machen ... aber er sollte vermutlich in einer technischen Kapazität im Team sein.

Sie sollten wahrscheinlich das Team mit Menschen füllen, die mit der Mehrzahl der Projekte vertraut sind. Ich würde vorsichtig sein, die Auswahl alle die Stromzuleitungen, wie das könnte einen großen Teil des Wissens aus den aktuellen Teams nehmen. Und seien wir ehrlich, haben diese Teams produktiv sein, während die Architektur-Team mit seinen eigenen Leistungen kommt.

Answer 2

Architektur ist schwierig, richtig zu machen.

Die „Architekten“ brauchen die Kraft um Dinge zu erledigen, müssen aber klug genug, um nicht diese Macht zu missbrauchen und vollständig den Rest der Gesellschaft entfremden.

Ich habe an zwei Stellen gearbeitet, wo Architekturteams umgesetzt wurden - war ein Erfolg, der andere sucht nicht so gut. An dem erfolgreichen Ort, war es eine relativ kleine Umgebung, in der der Kopf Architekt wurde als technischer Leiter anerkannt, und die anderen Mitglieder des Teams hatten ausgezeichnete Schreiben und politische Fähigkeiten. Jeder handelte im besten Interesse der Organisation.

An der Stelle, die es nicht so gut geklappt hat, stellten die Architekten eindeutig bestimmte Fraktionen in der Organisation und nicht verdienen das Vertrauen oder Respekt des gesamten Ort. Das Ergebnis war, dass mehr Zeit wurde das Kochen Ausrede verbringt die Architektur als Nachlese eines beliebigen Wertes von ihm zu umgehen. In diesem Fall stellte sich Frustration in passives / aggressives und anderen anti-sozialen Verhalten.

Ich denke, die anderen Fragen, die Sie über Umfang / Verantwortung / Übergang fragen werden alle beantwortet von „es kommt“. Es hängt von der Gesellschaft, die Menschen, das Geld und dem Zeitplan.

Answer 3

Interessante Frage.

Als erstes müssen Sie eine klare Vorstellung davon haben, was Problem dieses „Architektur“ Team zu lösen. Wenn Sie nicht eindeutig die „Mission“ des Teams definieren können, wird es scheitern und tut es mit großen großen Explosionen. :)

Dass gesagt wird, ist der erste Schritt, das Problem definieren Sie zu lösen. Versuchen Sie, mit der Technologie Schritt zu halten? Versuchen Sie, eine Wiederverwendung von Code zwischen Projekten zu integrieren? Versuchen Sie, Ihr Entwicklungspersonal auf die bestmögliche Wirkung zu nutzen? Es gibt mehrere Gründe, eine Architektur-Team und angesichts Ihrer Einrichtung zu implementieren, einer dieser könnte sufficent werden. Aus Ihrer Frage, es sieht aus wie Ihr Ziel, die bestehenden Anwendungen ist Nacharbeiten, so dass ein guter erster Schritt ist.

Da Sie bereits eine Gruppe von Leitungen haben, die gute spezifische Kenntnis der Anwendungen haben, es wäre eine gute Idee sein, mit ihnen zu beginnen. Holen Sie sie zusammen und Hash heraus, was die neue globale Architektur aussehen sollte. Vielleicht haben Sie auch einen Berater erhalten wollen zu helfen, das Gespräch an dieser Stelle zu erleichtern. Definieren Sie die Ziele der Nacharbeit und kommen mit einem „big picture“, dass jeder zustimmen kann.

Danach würde ich eine Handvoll der Leitungen nehmen und fördern sie (die Leitungen vom Entwickler Pool Verfüllung) an die Architektur-Team. Sie werden dann mit den Leitungen treffen, um die Dinge sicherzustellen, werden nach diesem „Big Picture“.

ich würde in einer ganz neuen Gruppe von außen bringen. Das würde ein unerwünscht sie gegen sie dynamisch erstellen, die nie gut ist. Die Außenseiter habe auch keine Vorstellung davon, wie die Dinge sollen oder arbeiten, warum die Dinge nicht so, wie Logik funktionieren würde bedeuten, sie sollten. :)

Answer 4

„Architektur“ in diesem Zusammenhang an sich bedeutet nichts. Es bedeutet „Experten auf transversale Themen“.

Jedes Mal, wenn Sie ein „Architecture Team“ haben, werden Sie ein transversales Team haben, die Dienstleistungen für viele Projekte bieten.

Wie die bisherigen Antworten angegeben, müssen Sie wissen, welche Themen ein solcher „Architektur-Abteilung“ wird auseinandersetzen müssen.

Nun, hier ist ein Beispiel für Organisation von Architekturteams basiert auf mehreren Themen:

• Geschäft und Functional Architecture Team: schreiben viele unternehmensbezogenen Spezifikationen und prüfen die Ausrichtung zwischen dem bestehenden Anwendung und funktionalen Workflow, um eine kohärente Kartographie der Anwendung zu vervollständigen
.
• Application Architecture Team: Sorgt für die Kartographie, sondern auch entscheiden, wie die funktionalen Spezifikationen von der Business und Functional Architecture Team entschieden werden in Anwendungen organisiert werden
  . Zum Beispiel müssen Sie ein Funktionsmodul für „Portfolio-Prozess“, aber das Application Architecture Team entscheiden kann, dass in einen „launcher“ aufzuspalten, einen „Dispatcher“, eine grafische Oberfläche, und so weiter.
• Teams Technische Architektur, immer bestehend aus:
  • Ausführung Architecture Team, für alle Nicht-Business-rein-technische Themen (Protokollierung, KPI, Frameworks, ...)
  • Entwicklung Architektur Team (Werkzeug Bewertung und Unterstützung, technologische Umfrage, Repositories Management für Versions- und Konfigurationssteuerung)
  • OA (Operational Architecture) für eine Umgebung „ausführbar“ zu machen (das heißt, die richtigen Prozesse zu kennen, die richtigen Server und die richtigen Netzwerke, um Ihr System entweder für die Homologation oder für die Produktion einzusetzen.)

Sie können ein Logistic Team für die Verwaltung der Server und Netzwerk hinzufügen, mit den Aufgaben der Sicherung und DRP-Strategien. Und eine Förderstrategie basierend auf einem guten Kasussystem.

Und Sie sind gut zu gehen.

Nun, vergessen Sie nicht, dass, wenn Sie einige „große Nacharbeit“ beginnen, Ihre Functional Architecture wird die Mission haben zur Durchsetzung der Kohärenzen sowohl zwischen:

• die überarbeiteten Projekte sicherzustellen, dass sie innerhalb des festgelegten funktionalen Umfang bleiben
• Vermächtnis Projekte ihre maintenances sicher sein sich nicht mit entgegengesetzte Entscheidungen im Vergleich zu der auf die überarbeiteten Projekte angewendet.

Jede Nacharbeit in einem Geschäft dieser Größe bedeutet in der Tat der Lage sein, machen notwendig Entwicklungen auf Legacy-Projekte , während für die Nacharbeit warten, um die ersten Veröffentlichungen zu produzieren. (Das Erbe kann nicht nur noch während 2-3 Jahre Nacharbeit warten und bleiben)

Eine große Nacharbeit sollte drei wichtigen Meilenstein beinhalten:

• 1 / Dialog mit dem Erbe
• 2 / komplett das Vermächtnis
• 3 / ersetzen das Vermächtnis

Bedeutung die einzelnen Komponenten in der Tat entwickelt wird drei Mal! ;)

Viel Glück und gute Nacht.

Answer 5

in der Regel sehr vorsichtig sein, um die Anreize sowohl politische als auch auf andere Weise mit der Architektur-Gruppe zugeordnet. es ist viel zu leicht für den ‚Architectural Review Board‘ (oder was auch immer Sie es nennen wollen) Barrieren werden, um die Fortschritte. Alles, was es ist null Anreiz nimmt die Dinge und einen negativen Anreiz zu verbessern, wenn die Dinge ändern und nicht sofort verbessern.

erkennen, dass Fehler werden gemacht werden, einige ‚große neue Technologien‘ wird sich als unausgegoren Marotten und ecourage Wandel und Innovation sein. dies kann die gelegentlichen kurzfristigen Verwerfungen und gescheiterte Transformation ergeben, aber das ist besser als Stagnation.

und die Alternative zwangsläufig ergibt Stagnation; in größeren Organisationen habe ich Karrieren, weil ein Manager genug in seinem Team glaubt ruiniert gesehen ihre Empfehlung für die neue Technologie des ganzen Weg nach oben, bietet die Fallstudien zu unterstützen, es zu beweisen, und es auf den Griff zurück. Wenn die neue Tech schließlich genehmigt wurde (nach fast einem Jahr der politischen Querelen) der CTO (die sie die ganze Zeit gegen) behauptet, für die Innovation Kredit und der Manager auf eine Hinterwäldler-Abteilung übertragen. In einem anderen Fall wurde eine neue Technologie, mit zahlreichen Beispielen für den Erfolg im gleichen Geschäftsfeld und ein committe gebildet wurde zur Untersuchung der Frage vorgeschlagen. Fünf Jahre später sie das Problem noch studieren, und nichts getan wurde,

Answer 6

Ich denke, das Architektur-Team Menschen Senioren genug haben muss, dass sie das Innenleben aller Entwicklungsteams und in der Lage zu sagen, Nein zu Anfragen / Führungslinien kennen. Ich habe in Teams mit guten Entwickler gewesen, noch nicht genug Autorität und nach landeten unabhängig von den höheren Rang Entwickler Manager aus verschiedenen Teams und produziert inkonsistente Frameworks.

Answer 7

Sie müssen die Geschäftsszenarien A) und B) durcharbeiten.

A) Was passiert, wenn Sie es nicht einrichten, d. h.nichts tun:
Schätzungen der Nacharbeiten zu den laufenden Wartungskosten

B) Sie richten dann Folgendes ein:
Unterbrechung kurzfristiger Lieferungen aufgrund von Ressourcenumleitung.
Es besteht das Risiko, dass mehrere Produkte kurzfristig distanziert werden.
Kosten für wahrgenommene zusätzliche Arbeitskräfte.
Wer wird sich verzeichnen, wenn die Produkte durch die Übung geschwächt werden (Leistung oder wahrgenommene Inflexibilität)

Als nächstes bringen Sie die Produktteams dazu, dieselbe Übung durchzuführen und die Ergebnisse zu vergleichen.

Wenn Sie es rechtfertigen, sind hier zwei Routen, die ich gesehen habe:
1.Wählen Sie ein Hauptprodukt aus, um die Architektur voranzutreiben und diesem Projekt Ressourcen hinzuzufügen.
Seien Sie dann bereit, weitere Ressourcen hinzuzufügen, und seien Sie geduldig, sonst leidet das Hauptprodukt.
Mit diesem Weg riskieren Sie eine Spaltung. Es funktionierte, als das Hauptprodukt 40 % des Umsatzes ausmachte.
2.Stellen Sie ein kleines Team zusammen, das sich aus den vielversprechendsten Diskussionen zusammensetzt, die intern stattgefunden haben, und integrieren Sie die neue Architektur schrittweise in jedes Produkt.
Integrieren Sie die Arbeit dieses Teams in die Produktarbeit.

Einige Fragen, die Sie sich ansehen sollten:
1.Wie schnell muss die Architekturkonvergenz erreicht werden, um geschäftliche Vorteile zu erzielen?
2.Wer sind die Teammitglieder, die bereits über Architekturkonvergenz sprechen, und fragen/schlagen sie ihre Bedeutung vor? Diese Frage sollte für 80 % Ihrer Teamleiter auf der „Backburner“-Liste stehen.

Was man nicht tun sollte
* Stellen Sie Experten von außen ein (es sei denn, Sie stecken gerade in einer echten Klemme)
* Geben Sie nach ein paar Monaten auf, das ist langfristig.
* Alle Projekte auf einmal ändern.
* Beginnen Sie, bis Sie einen Dreierkern haben, der dies ermöglichen kann.
* Lassen Sie die Architekturabteilung größer werden, als sie sein muss
* Lassen Sie den Eindruck entstehen, dass die Architekturabteilung die Probleme der Produktteams lösen wird
* Lassen Sie jedes Produkt so aussehen, als würde es „auf die neue Architektur warten“
* Lassen Sie die Architekturabteilung „alles definieren“ oder lassen Sie den Umfang zu
* Erzwingen Sie alle Produkte in der Architektur, einige passen möglicherweise nicht (z. B.nicht im selben Land entwickelt)

Was tun:
* Bewaffnet mit einer guten Begründung von Erste Frage: Ermitteln Sie die Geschäftsleitung sich einzukaufen und das Produkt zu fragen Teams, um über den Fortschritt zu berichten
* Schritt-für-Schritt-Änderungen in der Ausrichtung des Produkts an der Architektur vornehmen Landkarte
* Arbeiten Sie an der Ausrichtung der vielversprechendsten oder risikoärmsten Produktlinien erste
* Richten Sie Metriken ein, damit Sie den Mehrwert demonstrieren können (siehe Begründung aus dem ersten Satz von Fragen)
* Erstellen Sie einen Fahrplan für die Konvergenz aller Produkte oder nicht.
* Überlegen Sie, was die Kernarchitektur leistet und wer sie pflegt Artefakte
* Ermöglichen Sie es den Produktteams, zum Kern beizutragen, und zwar in Bezug auf Spezifikationen, Code und Wartung des Kerns
* Richten Sie Schulungen ein, wie Sie die Arbeit des Architekturteams für Neueinsteiger und bestehende Teams

Answer 8

Architektur allein könnte sich Menschen in Astronauten / Zombies. So sollten sie auf jeden Fall einige Codierung selbst zu tun haben, wenn das Grund Prototyping ist. In der Tat der Erfolg ihrer Prototypen definitive Beurteilung Faktor sein muss.

Sie sollten durch monatlich Präsentationen / häufige Blogs geben, die ihre Arbeit zu verfolgen, so dass andere in der Organisation lernen können.

Es sollte akademische Ziele sein wie mit bestimmtem vertraut zu seinen Plattformen / tools / Bücher und Design-Philosophien.

Sie sollten Zeit gegeben werden, um zu verfolgen, neue Werkzeuge / Projekte / Aufgaben in bestehenden Projekten, wenn sie Lust dazu hat.

Sie müßten die Verantwortung mit Code Artrichtlinien at-mindestens 3-4 Code-Reviews kritischer Module und kommt zu tun.

Sie würden die Verantwortung niedriges Niveau Designs bei Least Keymodul zu überprüfen.

Sie sollten Freizeit als Einzelpersonen oder Teams gegeben werden, etwas, das sie könnte nützlich sein, das Gefühl zu bauen.

Sie sollten die Möglichkeit haben, auf die Architektur zu verzichten und auf regelmäßige Arbeit zurückkehren, wenn sie, wie es ohne Strafen fühlen beteiligt.

Sie sollten die Informationen über haben was über alle Projekte hinweg geschieht in der Organisation ausgeführt wird. Mindestens ein Projekt sollte genau verfolgt werden, damit sie ihre eigenen Kollegen über Dinge passieren anderswo informieren kann. Dies kann möglicherweise das Projekt, in dem sie Code-Reviews durchführen und so weiter.

Sie sollten eine sehr technische Person als Manager haben.

Architekten zwischen den Projekten umgeschaltet werden sollen, wenn sie mit einem von ihnen sehr vertraut sind, und erlaubt auf folgen, was auch immer Prototyp sie, wo folgenden, während sie mit dem ursprünglichen Projekt arbeiten.

Hat

mindestens ein eigentliches Ziel (wie konsolidiert alle Gemeinsamkeiten über Projekte in eine einzige Bibliothek) jedes 1 Jahr

Investieren Sie Zeit und Ausbildung, um sicherzustellen, dass Architekten nicht bekommen Ego gebunden und ziemlich professionell durchzuführen. Konfliktlösung und andere Soft Skills Training zusammen mit Mitteln der technischen Sitzungen und Schulungen auf jeden Fall auch erforderlich wäre.

Answer 9

Betrachten Sie das Lesen / Kauf dieses Artikels von der ACM: der Software-Architekt . Es gibt mehrere Referenzen vorhanden dort und der Autor ist ungewöhnlich klar auf einer solchen diffusen Thema. Er wird Ihre Fragen nicht direkt beantworten, aber der Artikel Ihre Strategie konzentrieren.

Die bestplatzierten Antwort auf Ihre Frage macht einen guten Punkt: Fokus auf Soft-Skills und Ziele definieren. Ich würde ein tiefes Verständnis für hinzufügen, wie die Dinge in der Organisation getan.