Enterprise -, System-und Anwendungs-Architektur (Best Practice?)

Ich bin derzeit damit beauftragt, mit der Erstellung eine dokumentierte, konsequente Architektur-Leitfaden für die software-Entwicklung. Wir haben eine Menge kluger Leute, die die richtigen Dinge tun, aber eben nicht konstant und wiederholbar.

Sind wir mithilfe von Microsoft Application Architecture Guide 2.0 als Ausgangspunkt. Daher kommen mit einer Anwendung, die Architektur ist ziemlich (ich sage nicht leicht) straight forward. Vielleicht, weil ich habe ein paar Jahre Erfahrung als Entwickler, so habe ich ein ziemlich gutes Verständnis von diesem Reich, und es gibt auch viele Beispiele und Anleitungen.

Da unsere organisation hat ein paar Anwendungen, dass form 1 oder mehr Systemen, die wir dann zu installieren "unter" Kunden... wir dachten, es würde Sinn machen, erstellen Sie einen System-Architektur und Enterprise Architektur. Und das ist, wo die Probleme beginnen.

Gibt es keine einheitliche Führung gibt. Wenn Sie nach "System-Architektur Beispiele", die Sachen, die Sie zurück bekommen, ist so unterschiedlich, dass ich mich Frage, wenn es eine "Standard" - Weg, dies zu tun.

Aus meiner (Beschränkten - klar) das Verständnis des ganzen, die Architektur des Systems ist eine Abstraktion, die von 1 oder mehr Anwendungs-Architekturen darstellt, wie Sie zusammenarbeiten, um ein system zu bilden. Außerdem, eine Enterprise-Architektur ist eine weitere Abstraktion, die zeigen, wie Sie Ihr system(s) passen in eine Organisationen, Unternehmen und die Interaktion mit der Business-Prozesse, IT-Strategie und wie es Integrats in andere Systeme im Unternehmen.

  • Habe ich es komplett falsch?
  • Gibt es irgendwelche Normen gibt (und wo finde ich diese)?
  • Sollte es sein, Normen oder wäre ein "gutes" System-Architektur einfach jedes Dokument in jedem format übersichtlich und leicht verständlich und nützlich für seine Leser?
  • Was würden die erfahrenen Architekten denken, der Ansatz aber?

Möchte ich nicht einfach Liste eine Reihe von SOA-Verwandte Muster, die nützlich sein können... ich würde es gern machen, ein wenig mehr konzentrierte sich auf das, was wir tun, die für die build-Finance-Lösungen auf einer Service-Orientierten Architektur.

Update: Was TOGAF(9). Hat jemand Erfahrung damit und ist es der Mühe Wert, zu versuchen, es zu verstehen, im detail.

InformationsquelleAutor Gineer | 2009-04-16
  1. 20

    Legte ich die Frage vor ein paar Tagen, aber durch die weitere Forschung, und nach der Lektüre littlegeek's Antwort, ich glaube, ich habe gefunden ein Interessantes white paper, das fand ich sehr informativ und interessant.

    Lesen: Ein Vergleich der Top Four Enterprise-Architecture Methodologies
    Von: Roger Sessions

    ein snippet...

    -- - - - - - - - - - - 8< - - - - - - - - - - - -

    Viele enterprise-Architektur-Methoden gekommen und gegangen sind in den letzten 20 Jahren. An diesem Punkt, vielleicht 90 Prozent aus dem Feld verwenden Sie eine der folgenden vier Methoden:

    • Das Zachman Framework für Enterprise-Architekturen—Obwohl selbst beschrieben, wie ein Rahmen, ist eigentlich genauer definiert werden, als eine Taxonomie
    • The Open Group Architectural Framework (TOGAF)—Obwohl als framework bezeichnet wird, ist eigentlich genauer definiert als ein Prozess,
    • Die Federal Enterprise Architecture—Kann angesehen werden als entweder eine implementierte enterprise-Architektur oder ein proscriptive-Methodik für das erstellen einer enterprise-Architektur
    • Die Gartner—Methodik-Kann am besten beschrieben werden als ein enterprise-Architektur-Praxis

    In diesem Whitepaper werden diese vier Ansätze zur enterprise-Architektur. Es tut dies im Kontext einer fiktiven Firma, die mit einigen sehr nonfictional Operationen Probleme. Zu diesen Problemen gehören:

    • IT-Systeme, die mittlerweile unüberschaubar Komplex und kostenintensiv zu pflegen sind.
    • IT-Systeme behindern die Organisation die Fähigkeit zur Reaktion auf aktuelle und zukünftige Markt-Bedingungen in einer fristgerechten und kosteneffektiven Art und Weise.
    • Mission-kritischen Daten, ist konsequent out-of-date und/oder schlicht falsch.
    • Eine Kultur des Misstrauens zwischen der business-und Technologie-Seiten der Organisation.

    -- - - - - - - - - - - 8< - - - - - - - - - - - -

    Dem Weißen Papier hat mir geholfen, in mehrfacher Hinsicht.

    1. Es gab mir eine gute Einführung und Geschichte der Architektur (Enterprise-Architektur, die speziell)
    2. Er führte mich zu dem, was der Autor vorschlagen, ist die 4 führenden Enterprise-Architekturen verfügbar.
    3. Und dann weiter zu vergleichen, diese in eine logische und einfache Art und Weise gute Beispiele, die ich in Zusammenhang stehen könnten.

    Kann ich nicht sagen, dass alle meine Fragen wurden beantwortet und ich bin jetzt bereit, zu sterben,: -), aber vieles ist klarer geworden, und so dachte ich, dass jemand anderes heraus dort kann auch das nützlich finden.

    Ich würde immer noch Wert etwaige zusätzliche Kommentare, Anregungen und Fragen zu diesem Thema.

    • +1 für die Freigabe eine gute und informative white paper
    • Toter link, jeder frische?
    InformationsquelleAutor Gineer
  2. 1

    Scheinen Sie ein wirklich gutes Gespür für die situation und das Verständnis der Bereich der artchitecture.

    "Systeme" Architektur ist etwas schwieriger zu definieren - vielleicht suchen Sie nach "Lösung" oder "ES", aber es klingt wie Ihr auf der Suche nach, wie Sie Ihre software-Architektur bezieht sich auf die physikalische server-Welt mit ein bisschen networking geworfen

    "Wir haben eine Menge kluger Leute, die die richtigen Dinge tun, aber eben nicht konstant und wiederholbar."

    Dann,, TOGAF 8 certifed mich, würde ich sagen, dass TOGAF bringt ein Gefühl von "Methodik" auf die verschiedenen Aspekte der Definition von Architektur und einen Weg zu bringen variours-Spezialist technische Gruppen zusammen und pinnen Sie fest, um die Unternehmensziele zu erreichen. TOGAF hilft auch zu verstehen, die Notwendigkeit für die Architektur-governance und fest bringt die Idee der Veränderung (aus allen teilen technische, Daten, Systeme, software und business) in den Prozess.

    Den

    1. Architecture Development Method
    2. Technische Referenz Modell
    3. Standards Information Base
    4. Enterprise Continuum

    Helfen, alle Informationen zu sammeln, die über die Archtecture Mühe und bieten ein einheitliches Konzept zu entwickeln und EA.

    Es hilft auch, die Kunden verstehen, was Sie tun und wie Sie sich präsentieren können TOAGF als die Methode, die zeigt, wie es zusammen passt.

    PS - ich Stelle lediglich fest TOGAF als hilfreich, das Zitat, dass ich gezogen, als TOAGF würde dieses Problem lösen für Sie.

    Gibt es andere Architekten framworks gibt.

    InformationsquelleAutor
  3. 0

    Habe ich keine praktische Erfahrung auf EA, aber eigentlich bin ich an Bord mit ihm. Unter den top-4 EA-Methoden, dem ich begegnet bin, die ersten drei. Ich weiß nur nicht, den Gartner, vielleicht wegen des Ausfalls Ihrer Dokumente. IMHO, wenn wir reden hier über EA, wir sind eigentlich reden über die Angleichung der Wirtschaft mit Technik. Also alle EA-Methoden muss der business-orientierten. Wenn nicht, ist es nicht von EA überhaupt.

    Ich denke, TOGAF ist sehr nützlich und verständlich. Ja, es ist ein Prozess, der sich entwickeln aktuelle baseline-Architektur in die Ziel-Architektur. Architektur-Prinzipien dienen als high-level-Führung der EA-Entwicklung. Die core-Komponenten von TOGAF sind business-Architektur, Informationsarchitektur und technologiearchitektur. Und jeder von Ihnen kann seine eigene Architektur-Muster. NIH umgesetzt hat, einen EA mit FEAF. Es ist ein gutes Beispiel für die Umsetzung von EA. Ich denke, es ist ganz ähnlich wie TOGAF-Ansatz, zumindest aus Sicht der Arbeitsergebnisse.

    • Eine Enterprise-Architektur (IMHO) sollten nicht nur Business-Orientiert. Ich nehme an, es hängt davon ab, was du meinst, von EA. Ich denke EA sollte beinhalten alles, was und nützlich sein, um Unternehmen und Entwickler und alles dazwischen. Ein EA ist nur der business-orientierten enthält nur einen einzigen Standpunkt der gesamten EA.
    • Sicher. Ein EA sollte verkörpern verschiedene Standpunkte, aber Geschäft ist der ultimative Treiber. Bevor Sie etwas über EA, Unternehmensziele sollten deutlich gemacht werden. Und auch alle anderen Sichtweisen entwickelt werden sollten, um die Geschäftsziele zu erreichen. Das ist es, was ich meine business-orientiert.
    InformationsquelleAutor yanky
  4. 0

    Ist die einzig sinnvolle Versuch, ein Modellierungs-framework für EA bisher Archimate: https://en.wikipedia.org/wiki/ArchiMate

    ArchiMate ist ein technischer standard von The Open Group und basiert auf den Konzepten des IEEE-1471-Norm.

    Finden Sie auch unter folgendem link über EA-Artefakte und die Rückverfolgbarkeit zwischen Ihnen:

    https://www.ontario.ca/document/go-its-56-ops-enterprise-architecture-principles-and-artefacts-appendix-ontario-public-service

    InformationsquelleAutor Bran
Schreibe einen Kommentar