Unternehmen, Systeme und Anwendungsarchitektur (Best Practice?)
https://stackoverflow.com/questions/755540
-
09-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Ich bin derzeit mit der Erstellung einer Dokumentation, konsistente Architekturführer für Software-Entwicklung beauftragt. Wir haben viele schlau Leute, die richtigen Dinge zu tun, aber eben nicht konsequent und wiederholbar.
Wir sind mit Microsofts Application Architecture Guide 2.0 als Ausgangspunkt. Daher mit einer Anwendungsarchitektur kommen ist ziemlich (ich will nicht einfach sagen) geradlinig. Vielleicht, weil ich ein paar Jahre Erfahrung als Entwickler habe so habe ich ein ziemlich gutes Verständnis für diesen Bereich und es gibt auch viele Beispiele und Anleitungen.
Da unsere Organisation ein paar Anwendungen hat, die mit 1 oder mehr Systeme bilden, die wir dann „an“ Kunden installieren ... wir dachten, es wäre sinnvoll, eine Systemarchitektur und eine Enterprise-Architektur als auch zu schaffen. Und das ist, wo die Probleme beginnen.
Es gibt keine einheitliche Führung gibt. Wenn Sie für „System Architecture Beispiele“ suchen, die Sachen, die Sie zurück bekommen, sind so unterschiedlich, dass ich frage mich, ob es eine „Standard“ Art und Weise, dies zu tun.
Aus meinem (Limited - klar) Verständnis von allem, ist die Systemarchitektur eine Abstraktion von 1 oder mehr Anwendungsarchitekturen darstellen, wie sie zusammenarbeiten, um ein System zu bilden. Weiterhin ist eine Enterprise Architecture ist eine weitere Abstraktion zeigt, wie Sie Ihr System (e) passen in eine Organisationen Unternehmen und wie sie interagiert mit den Geschäftsprozessen, IT-Strategie und wie es Integrats in andere Systeme im Unternehmen.
- Muss ich es völlig falsch?
- Gibt es da draußen irgendwelche Standards (und wo kann ich sie finden)?
- Sollte es Standards sein, oder wäre eine „gut“ Systemarchitektur einfach alle Dokumente in jedem Format gesendet werden, die klar und leicht verständlich und nützlich für die Leser?
- Was würde denken, die erfahrenen Architekten dieses Ansatzes aber?
Ich will nicht einfach auf eine Reihe von SOA im Zusammenhang Muster auflisten, die nützlich sein können ... würde Ich mag es ein wenig mehr konzentriert zu machen, was wir tun, die die Build-Finanzlösungen auf einem Service-Oriented sind Architektur.
Update: Was ist TOGAF (9) . Hat jemand damit Erfahrung überhaupt und es ist die Mühe wert, zu versuchen, es im Detail zu verstehen.
Lösung
legte ich die Frage vor ein paar Tagen, aber durch kontinuierliche Forschung und nach dem Lesen littlegeek 's reponse, I glaube, ich habe ein interessantes Whitepaper gefunden, die ich sehr informativ und interessant gefunden.
Lesen: Ein Vergleich der Top Vier der Enterprise-Architektur Methodiken Von: Roger Sessions
ein Ausschnitt ...
- - - - - - - - - - - 8 <- - - - - - - - - - - -
Viele der Enterprise-Architektur-Methoden sind gekommen und in den letzten 20 Jahren verschwunden. An dieser Stelle vielleicht 90 Prozent des Feldes eine dieser vier Methoden verwenden:
- Das Zachman Framework für Enterprise-Architekturen: Obwohl als Rahmen selbst beschrieben, ist eigentlich genauer als Taxonomie definiert
- Die Open Group Architectural Framework (TOGAF) -Obwohl einen Rahmen genannt wird, ist eigentlich genauer definiert als ein Prozess
- Der Bund Enterprise Architecture-kann entweder als eine implementierte Enterprise-Architektur oder eine proscriptive Methodik für die Erstellung einer Unternehmensarchitektur eingesehen werden
- Die Gartner-Methodik-am besten als ein Unternehmen architektonische Praxis beschrieben wird
Dieses Whitepaper werden diese vier Ansätze zur Unternehmensarchitektur. Er tut dies im Rahmen einer fiktiven Firma, die einige sehr fiktionalen Operationen Probleme konfrontiert ist. Zu diesen Problemen gehören:
- IT-Systeme, die unüberschaubar komplex geworden sind und immer teurer zu halten.
- IT-Systeme, die die Fähigkeit der Organisation zu Strom reagieren behindern und zukünftige Marktbedingungen in einer fristgerechten und kosteneffektive Art und Weise.
- Mission-kritische Informationen, die konsequent out-of-date und / oder einfach falsch ist.
- Eine Kultur des Misstrauens zwischen dem Geschäfts- und Technologie Seiten der Organisation.
- - - - - - - - - - - 8 <- - - - - - - - - - - -
Das Weißbuch hat mir geholfen, in mehrfacher Hinsicht.
- Es gab mir eine gute Einführung und Geschichte der Architektur (Enterprise Architecture speziell)
- Sie führte mich zu dem, was der Autor schlägt die vier führenden Enterprise-Architekturen zur Verfügung.
- Und dann geht sie in einer logischen und einfachen Art und Weise zu vergleichen mit guten Beispielen, die ich in Zusammenhang stehen könnte.
Ich kann nicht sagen, dass alle meine Fragen beantwortet sind, und ich bin jetzt bereit :-) zu sterben, aber viel hat sich klarer werden und somit dachte ich, dass jemand anderes da draußen auch diese nützlich finden können.
Ich würde immer noch Wert auf zusätzliche Kommentare, Anregungen und Fragen, die Sie zu diesem Thema haben.
Andere Tipps
Sie scheinen ein wirklich gutes Verständnis für die Situation und das Verständnis für das Reich der artchitecture zu haben.
„Systems“ Architecure ist etwas schwerer zu definieren - für „Lösung“ aussehen werden, oder „IT“, aber es klingt wie Sie auf der Suche nach, wie Sie Ihre Software-Architektur bezieht sich auf die physischen Server-Welt, mit ein bisschen in geworfen networking
„Wir haben viele klug Leute, die richtigen Dinge zu tun, aber eben nicht konsequent und wiederholbar.“
Dann TOGAF sind 8 zertifziert mich, - ich würde sagen, dass TOGAF auf verschiedene Aspekte der Definition der Architektur und eine Möglichkeit, ein Gefühl der „Methodik“ bringt ein variours Fach technische Gruppen zusammen zu bringen und fest mit den Geschäftszielen feststecken. TOGAF hilft auch die Notwendigkeit für Architektur Governance zu verstehen und bringt fest die Idee der Veränderung (aus allen Teilen technische, Daten, Systeme, Software und Business) in den Prozess einzubeziehen.
Das
- Architektur Entwicklung Methode
- Technisches Referenzmodell
- Standards Information Base
- Unternehmen Continuum
Alle helfen Informationen über den Archtecture Aufwand zu sammeln und einen konsequenten Ansatz zur Entwicklung und EA zur Verfügung stellen.
Es hilft auch, den Kunden zu verstehen, was Sie tun und wie Sie TOAGF als Methode zu zeigen, darstellen kann, wie es passt zusammen.
PS -. Ich nur TOGAF angeben als nützlich Sie, dass das Zitat i als TOAGF gezogen haben würde für Sie diese Adresse
Es gibt auch andere Architekten Framworks gibt.
Ich habe keine praktische Erfahrung auf EA, aber ich bin tatsächlich an Bord mit. Unter den Top-4 EA-Methoden habe ich die ersten drei angetroffen. Ich weiß einfach nicht die Gartner ein, vielleicht wegen des Ausfalls seiner Dokumente. IMHO, wenn wir über EA sprechen, sprechen wir eigentlich über das Geschäft mit der Technik auszurichten. So alle EA-Methoden müssen Unternehmen ausgerichtet sein. Wenn nicht, ist es nicht bei allen EA.
Ich denke, TOGAF sehr nützlich und verständlich ist. Ja, es ist ein Prozess, die aktuelle Grundarchitektur in Zielarchitektur zu entwickeln. Architekturprinzipien wirken als die hohe Führung von EA Entwicklung. Die Kernkomponenten von TOGAF sind Business-Architektur, Informationsarchitektur und Technologie-Architektur. Und jeder von ihnen kann seine eigenen Architekturmuster hat. NIH ein EA mit FEAF umgesetzt hat. Es ist ein gutes Beispiel für EA zu implementieren. Ich denke, es zu TOGAF Ansatz sehr ähnlich ist, zumindest aus Sicht der zu erbringenden Leistungen.
Der einzig sinnvolle Versuch, einen Rahmen für die Modellierung für EA zu schaffen bisher Archimate gewesen: https: // en.wikipedia.org/wiki/ArchiMate
Archimate ist ein technischer Standard von The Open Group und basiert auf den Konzepten des IEEE 1471-Standard.
Auch hierzu finden Sie auf den folgenden Link zu EA Artefakte und Rückverfolgbarkeit zwischen ihnen:
