Den Wert von Referenzarchitekturen verstehen
Architekten lieben es, über Definitionen zu streiten. Wenn Sie jemals Leerlauf in einem Raum von Architekten haben, fragen Sie nach einer Definition von „Service“ oder „Architektur“ und sehen Sie, welche Art von kreativem Nahkampf Sie beginnen können. Davon abgesehen sind Definitionen in der Tat sehr wichtig, damit wir eine gemeinsame Sprache haben, um die Absicht und den Nutzen genau der Dinge zu kommunizieren, in die wir Unternehmen zu investieren versuchen. Aus dieser Perspektive sind in den letzten zehn Jahren eine Reihe von Konzepten entstanden, die für selbsternannte Unternehmensarchitekten an erster Stelle stehen: Architektur-Frameworks und Referenzarchitekturen. In früheren ZapFlashes haben wir Architektur-Frameworks diskutiert, wodurch das Thema Referenzarchitekturen von ZapThink unberührt bleibt. Da wir kein gutes Argument hinter uns lassen können, werden wir diesen ZapFlash verwenden, um zu untersuchen, worum es bei Referenzarchitekturen geht und welchen Wert sie für die serviceorientierte Architektur (SOA) haben.
Was ist eine Referenzarchitektur?
Eine allgemein akzeptierte Definition für Referenzarchitektur ist, dass sie eine Methodik und / oder eine Reihe von Praktiken und Vorlagen bereitstellt, die auf der Verallgemeinerung einer Reihe erfolgreicher Lösungen für eine bestimmte Lösungskategorie basieren. Referenzarchitekturen bieten Anleitungen zur Anwendung bestimmter Muster und / oder Praktiken zur Lösung bestimmter Problemklassen. Auf diese Weise dient es als „Referenz“ für die spezifischen Architekturen, die Unternehmen implementieren, um ihre eigenen Probleme zu lösen. Es ist nie beabsichtigt, dass eine Referenzarchitektur so implementiert wird, wie sie ist, sondern entweder als Vergleichspunkt oder als Ausgangspunkt für die Architekturbemühungen einzelner Unternehmen verwendet wird.
Andere verfeinern die Definition von Referenzarchitektur als Beschreibung, wie eine Klasse von Artefakten erstellt wird. Diese Artefakte können in vielen Formen verkörpert werden, einschließlich Entwurfsmustern, Methoden, Standards, Metadaten und Dokumenten aller Art. Um es kurz zu machen: Wenn Sie Anleitungen zur Entwicklung einer bestimmten Architektur auf der Grundlage bewährter Verfahren oder maßgeblicher Sätze potenzieller Artefakte benötigen, sollten Sie sich eine Referenzarchitektur ansehen, die den Umfang der Architektur abdeckt, die Sie erstellen möchten.
Eines der beliebtesten Beispiele für Referenzarchitekturen in der IT ist die Java Platform Enterprise Edition (Java EE) -Architektur, die eine mehrschichtige Referenzarchitektur und Vorlagen für eine Reihe von Technologie- und Geschäftsproblemen bereitstellt, die viele Java-basierte Unternehmenssysteme geleitet haben.
Referenzarchitekturen vs. Architektur-Frameworks
Während die obige Definition (en) ziemlich geschnitten und getrocknet erscheinen mag, gibt es eine Menge Gemeinsamkeiten zwischen den Konzepten der Referenzarchitekturen und Architektur-Frameworks. Für einige, Hier werden die Dinge heikel und Definitionen verschwommen. Architektur-Frameworks wie das Zachman-Framework, das Open Group Architecture Framework (TOGAF) und das Department of Defense Architecture Framework (DoDAF) bieten Ansätze zur Beschreibung und Identifizierung notwendiger Inputs für eine bestimmte Architektur sowie Mittel zur Beschreibung dieser Architektur. Wenn eine bestimmte Architektur ein Kochbuch ist, das Anleitungen zur Lösung bestimmter Probleme mit einem bestimmten Ansatz enthält, ist ein Architekturframework ein Buch zum Schreiben von Kochbüchern. Architektur-Frameworks geben Unternehmensarchitekten also die Werkzeuge an die Hand, die sie benötigen, um Anforderungen angemessen zu beschreiben und zu sammeln, ohne einen bestimmten Architekturtyp vorzuschreiben. Genauer gesagt beschreiben Architektur-Frameworks eine Beispieltaxonomie der Arten von architektonischen „Ansichten“, die ein Architekt entwickeln könnte, und warum, und bietet Richtlinien für die Wahl für die Entwicklung bestimmter Ansichten.
Dies unterscheidet sich vom obigen Konzept einer Referenzarchitektur dadurch, dass eine Referenzarchitektur einen Schritt weiter geht, indem sie den Prozess für einen bestimmten Architekturtyp beschleunigt, dabei hilft, zu identifizieren, welche Architekturansätze bestimmte Anforderungen erfüllen, und herauszufinden, welche minimal akzeptablen architektonischen Artefakte erforderlich sind, um die „Best Practices“ -Anforderungen für eine bestimmte Architektur zu erfüllen. Um unsere Analogie zu Kochbüchern fortzusetzen: Wenn ein Architektur-Framework ein Buch zum Schreiben von Kochbüchern ist, ist eine Referenzarchitektur ein Buch, das Anleitungen und Best Practices zum Schreiben von Kochbüchern enthält, die sich beispielsweise auf die Gewichtsabnahme konzentrieren. Dies würde dann bedeuten, dass die spezielle Architektur, die Sie für Ihre Organisation entwickeln, ein spezifisches Kochbuch ist, das Gewichtsverlustrezepte für Ihre Organisation bereitstellt. In der Tat, wenn Sie mit den Definitionen verwirrt sind, ist es hilfreich, den Begriff „Architektur“ durch „Kochbuch“ zu ersetzen: kochbuch-Frameworks, Referenz-Kochbücher und Ihr spezielles Kochbuch.
Darüber hinaus betonen die meisten Referenzarchitekturen den „Template“ -Teil der Definition einer Referenzarchitektur. Sowohl Frameworks als auch RAs bieten Best Practices, und obwohl argumentiert werden könnte, dass RAs eher eine Methodik als ein Framework bieten, zeichnen sich RAs immer noch nicht wirklich durch ihre Methodenkomponente aus. Die meisten können jedoch durch ihre Template-Komponente charakterisiert werden. Aus dieser Perspektive sind Muster in diesem Zusammenhang Instanzen von Vorlagen. Tatsächlich sind mehrere Referenzarchitekturen für dieselbe Domäne zulässig und sehr nützlich. Referenzarchitekturen können komplementär sein und Anleitungen für eine einzelne Architektur, z. B. SOA, aus mehreren Blickwinkeln bieten.
Der Wert einer SOA-Referenzarchitektur
In vielerlei Hinsicht benötigen SOA-Projekte dringend durchdachte Referenzarchitekturen. ZapThink sieht eine hohe Variabilität in SOA-Projekten. Einige gedeihen und Erfolg haben, während andere Flunder und scheitern. Oft kann der Grund für das Scheitern auf schlechte Architekturpraktiken, vorzeitigen Infrastrukturkauf und unzureichende Governance und Management zurückgeführt werden. In anderen Fällen ist das Scheitern in erster Linie organisatorisch. Was jedoch bei den meisten Erfolgen üblich ist, sind gut dokumentierte und / oder kommunizierte Architekturpraktiken und eine systematische Methode, um aus den Fehlern zu lernen und niedrige Kosten für das Scheitern zu haben.
Darüber hinaus stellen wir fest, dass viele Architekten einen erheblichen Teil ihrer Zeit damit verbringen, architektonische Entscheidungen zu erforschen, zu untersuchen, (neu-) zu definieren, darüber nachzudenken und darüber zu streiten. In vielen Fällen erfinden diese Architekten das Rad neu, da ihre Kollegen in anderen Unternehmen oder sogar in derselben Firma bereits Zeit und Mühe darauf verwendet haben, ihre eigenen Architekturpraktiken zu definieren. Dieser zusätzliche Aufwand ist nicht nur ineffizient, sondern verhindert auch, dass das Unternehmen aus seinen eigenen Erfahrungen lernt und dieses Wissen für eine erhöhte Effektivität anwendet.
Aus dieser Perspektive können SOA-Referenzarchitekturen denjenigen helfen, die mit ihren SOA-Bemühungen zu kämpfen haben oder darüber nachdenken, eine neue zu starten. SOA-Referenzarchitekturen ermöglichen es Unternehmen, von den Erfolgen und Misserfolgen anderer Architekten zu lernen und bewährte Best Practices zu übernehmen. Referenzarchitekturen können fehlende Architekturinformationen bereitstellen, die den Projektteammitgliedern im Voraus zur Verfügung gestellt werden können, um konsistente Best Practices für die Architektur zu ermöglichen. Auf diese Weise bietet die SOA-Referenzarchitektur eine Basis von Assets, auf die SOA-Bemühungen während des gesamten Projektlebenszyklus zurückgreifen können.
Um die versprochenen SOA-Vorteile der Wiederverwendung, der reduzierten Redundanz, der reduzierten Integrationskosten sowie der erhöhten Transparenz und Governance zu erzielen, müssen Unternehmen ihre SOA-Bemühungen konsequent umsetzen. Dies bedeutet mehr als den Kauf und die Etablierung der Infrastruktur eines Anbieters als Unternehmensstandard oder die Einhaltung des neuesten WS- * -Standardstacks. SOA-Referenzarchitekturen können als Grundlage für unterschiedliche SOA-Bemühungen im gesamten Unternehmen dienen, auch wenn sie unterschiedliche Tools und Technologien verwenden. Gute SOA-Referenzarchitekturen bieten SOA-Best Practices und -Ansätze auf hersteller-, technologie- und standardunabhängige Weise. Gehen Sie daher nicht auf die Jagd nach einem Anbieter Ihrer Wahl. Wenn Sie Ihre SOA-Referenzarchitektur von diesem Anbieter erhalten haben, sollten Sie sie möglicherweise anstelle von etwas Herstellerneutralerem ablegen.
Insbesondere bietet OASIS eine SOA-Referenzarchitektur (RA) an, die „die abstrakten Architekturelemente für eine SOA unabhängig von den Technologien, Protokollen und Produkten modelliert, die zur Implementierung einer SOA verwendet werden. Einige Abschnitte der RA verwenden gemeinsame abstrahierte Elemente, die von mehreren Standards abgeleitet sind.“ Ihr Ansatz verwendet das Konzept der „Muster“, um verschiedene Methoden und Ansätze zur Implementierung verschiedener Teile des Architekturbildes zu identifizieren. Während die OASIS SOA-Referenzarchitektur sicherlich nicht die einzige gültige auf dem Block ist, ist sie sicherlich ein guter Ausgangspunkt für diejenigen, die eine herstellerneutrale SOA-Referenzarchitektur suchen, auf der sie ihre eigenen architektonischen Bemühungen aufbauen können.
Die ZapThink-Gruppe
Enterprise Architects benötigt alle Hilfe, die sie bekommen können, um sicherzustellen, dass sie zuverlässige, agile, belastbare und herstellerneutrale Architekturen für ihre Organisation bereitstellen, die den sich ständig ändernden Anforderungen des Unternehmens gerecht werden. Während die Kunst und Praxis der Unternehmensarchitektur sicherlich weiter reift, sollten Unternehmen so viele Best Practices wie möglich ausleihen und von anderen lernen, die bereits den EA- und SOA-Weg eingeschlagen haben. Wenn Sie vorhaben, SOA oder irgendeine Form von EA zu lernen, oder noch schlimmer, von einem Anbieter, dann riskieren Sie den gesamten Erfolg Ihrer SOA-Bemühungen. Nutzen Sie stattdessen (kostenlose) SOA-Referenzarchitekturen, damit Sie schneller und mit geringerem Risiko vorankommen können. Bernard von Chartres hat es am besten in dem bekannten Sprichwort ausgedrückt: „Wir sind wie Zwerge auf den Schultern von Riesen, so dass wir mehr sehen können als sie und Dinge in größerer Entfernung, nicht aufgrund einer Schärfe des Sehens unsererseits oder einer physischen Unterscheidung, sondern weil wir von ihrer riesigen Größe hoch getragen und erhoben werden.“ Stellen Sie sich auf die Schultern anderer Giganten der Unternehmensarchitektur und lassen Sie sie Ihre Vision und Ihren Erfolg steigern.