参照アーキテクチャの価値を理解する
定義について議論するよりも、建築家が好きなことは何もありません。 建築家の部屋でアイドル時間を見つけた場合は、”サービス”または”建築”の定義を求めてみて、どのような創造的な混戦を開始できるかを確認してくださ そうは言っても、定義は確かに非常に重要なので、ビジネスに投資するように説得しようとしているものの意図と利益を伝えるための共通言語を持 そのような観点から、過去十年ほどでいくつかの概念が浮上しており、自称エンタープライズアーキテクトにとって心のトップとなっています。 以前のZapFlashesでは、参照アーキテクチャのトピックをZapThinkがそのまま残したアーキテクチャフレームワークについて議論しました。 良い議論を残すことはできないので、このZapFlashを使用して、参照アーキテクチャがどのようなものであり、サービス指向アーキテクチャ（SOA）ストーリーにどのような価
参照アーキテクチャとは何ですか？
参照アーキテクチャの一般的に受け入れられている定義の一つは、ソリューションの特定のカテゴリのための成功したソリューションのセットの一般化に基づいている方法論および/またはプラクティスおよびテンプレートのセットを提供するということです。 参照アーキテクチャは、特定のパターンやプラクティスを適用して特定のクラスの問題を解決する方法に関するガイダンスを提供します。 このようにして、企業が独自の問題を解決するために実装する特定のアーキテクチャの”リファレンス”として機能します。 参照アーキテクチャをそのまま実装することは意図されていませんが、むしろ比較のポイントとして、または個々の企業のアーキテクチャ努力の出発点とし
他の人たちは、参照アーキテクチャの定義をアーティファクトのクラスを構築する方法の説明として洗練しています。 これらの成果物は、設計パターン、方法論、標準、メタデータ、およびあらゆる種類の文書を含む多くの形式で具体化することができます。 簡単に言うと、ベストプラクティスや潜在的な成果物の権威あるセットに基づいて特定のアーキテクチャを開発する方法に関するガイダンスが必要な場合は、構築しようとしているアーキテクチャの範囲をカバーするリファレンスアーキテクチャを検討する必要があります。
ITにおける参照アーキテクチャの最も一般的な例の一つは、java Platform Enterprise Edition(Java EE)アーキテクチャであり、多くのJavaベースのエンタープライズ-システムを導いてきた
参照アーキテクチャとアーキテクチャフレームワーク
上記の定義はかなりカットされて乾燥しているように見えるかもしれませんが、参照アーキテクチャとアーキテクトフレームワークの概念の間には多くの共通点があります。 いくつかのために、これは物事がdiceyを取得し、定義がぼやけて取得する場所です。 Zachman Framework、Open Group Architecture Framework(TOGAF)、Department of Defense Architecture Framework(DoDAF)などのアーキテクチャフレームワークは、特定のアーキテクチャに必要な入力を記述し、識別するためのアプローチと、そのアーキテクチャを記述するための手段を提供する。 特定のアーキテクチャが、特定のアプローチで特定の一連の問題を解決する方法に関するガイダンスを提供するクックブックである場合、アーキテクチャフレームワークはクックブックを書く方法についての本です。 したがって、アーキテクチャフレームワークは、特定のアーキテクチャタイプを強制することなく、エンタープライズアーキテクトに要件を適切に記述して収集 具体的には、アーキテクチャフレームワークは、アーキテクトが開発を検討する可能性のあるアーキテクチャの”ビュー”の種類とその理由の例の分類法を記述し、特定のビューを開発するための選択を行うためのガイドラインを提供します。
これは、参照アーキテクチャが特定のアーキテクチャタイプのプロセスを加速し、特定の要件を満たすアーキテクチャアプローチを特定し、特定のアーキテクチャの”ベスト-プラクティス”要件を満たすために最低限許容できる一連のアーキテクチャ成果物が必要であることを理解することによって、参照アーキテクチャがさらに一歩進んでいくという点で、上記の参照アーキテクチャの概念とは異なります。 クックブックとの類推を続けるために、アーキテクチャフレームワークがクックブックの書き方に関する本である場合、リファレンスアーキテクチャは、例えば、減量に焦点を当てたクックブックの書き方に関するガイダンスとベストプラクティスを提供する本である。 これは、組織のために開発する特定のアーキテクチャが、組織を対象とした減量レシピを提供する特定のクックブックになることを意味します。 確かに、定義に困惑した場合は、”architecture”という用語を”cookbook”に置き換えると便利です: クックブックフレームワーク、参照クックブック、およびあなたの特定のクックブック。
さらに、ほとんどの参照アーキテクチャは、参照アーキテクチャの定義の”テンプレート”部分を強調しています。 フレームワークとRAsの両方がベストプラクティスを提供し、RAsはフレームワークよりも多くの方法論を提供すると主張されるかもしれませんが、RAsはまだその方法論のコンポーネントによって実際には特徴づけられていません。 しかしほとんどは型板の部品によって特徴付けることができる。 この観点から見ると、パターンはこの文脈でのテンプレートのインスタンスです。 実際には、同じドメインの複数の参照アーキテクチャが許容され、非常に便利です。 参照アーキテクチャは、SOAのような単一のアーキテクチャに対する複数の視点からのガイダンスを提供する補完的なものである可能性があります。
SOA参照アーキテクチャの価値
多くの点で、SOAプロジェクトはよく考え抜かれた参照アーキテクチャを必死に必要としています。 ZapThinkは、SOAプロジェクトに高度の変動性を見ています。 いくつかは繁栄し、他の人がヒラメし、失敗しながら成功します。 何度も失敗の理由は、悪い建築慣行、時期尚早のインフラストラクチャの購入、不十分なガバナンスと管理に追跡することができます。 他の回は、失敗は主に組織的です。 しかし、ほとんどの成功で共通しているのは、よく文書化され、/または伝達された建築慣行と、自分の過ちから学び、失敗の低コストを持つための体系的
さらに、多くの建築家は、建築上の決定を研究、調査、（再）定義、熟考、議論するのにかなりの時間を費やしていることがわかります。 多くの場合、これらの建築家は、他の企業や同じ会社の仲間がすでにその時間と労力を費やして独自の建築慣行を定義しているため、車輪を再発明し この余分な努力は非効率的であるだけでなく、会社が自分の経験から学び、その知識を有効性を高めるために適用することを妨げます。
この観点から、SOA参照アーキテクチャは、SOAの努力に苦労したり、新しいものを立ち上げることを考えている人にいくつかの助けを提供することがで SOA参照アーキテクチャにより、組織は他のアーキテクトの成功と失敗から学び、実績のあるベストプラクティスを継承できます。 参照アーキテクチャは、一貫性のあるアーキテクチャのベストプラクティスを可能にするために、プロジェクトチームメンバーに事前に提供 このようにして、SOA参照アーキテクチャは、SOAの努力がプロジェクトのライフサイクル全体から引き出すことができる資産の基盤を提供します。
確かに、再利用、冗長性の削減、統合コストの削減、可視性とガバナンスの向上という約束されたSOAの利点を得るためには、企業はSOAの取り組みを一貫 これは、ベンダーのインフラストラクチャを企業標準として購入して確立するか、最新のWS-*標準スタックを遵守する以上のことを意味します。 SOA参照アーキテクチャは、異なるツールやテクノロジを使用している場合でも、組織全体で異なるSOA努力の基礎となることができます。 優れたSOA参照アーキテクチャは、ベンダー、技術、および標準に依存しない方法でSOAのベストプラクティスとアプローチを提供します。 したがって、選択のあなたの好きなベンダーからのもののために狩りに行ってはいけません。 実際、そのベンダーからSOA参照アーキテクチャを取得した場合は、よりベンダーニュートラルなものの代わりにsoa参照アーキテクチャを削除することを検討す
特に、OASISはSOA Reference Architecture(RA)を提供しており、”SOAを実装するために使用される技術、プロトコル、および製品とは独立したSOAの抽象的なアーキテクチャ要素をモデ RAの一部のセクションでは、いくつかの標準から派生した共通の抽象化された要素を使用します。”彼らのアプローチは、”パターン”の概念を使用して、建築画像のさまざまな部分を実装するためのさまざまな方法とアプローチを識別します。 OASIS SOA参照アーキテクチャは確かにブロック上の唯一の有効なものではありませんが、ベンダーに依存しないSOA参照アーキテクチャを探している人にとっては、
Zapthink Take
エンタープライズアーキテクトは、ビジネスの継続的に変化する要件を満たす信頼性が高く、俊敏で、弾力性があり、ベンダーニュートラルなアーキテクチャを組織に提供するために、彼らが得ることができるすべての助けを必要としています。 確かにエンタープライズアーキテクチャの芸術と実践は成熟し続けていますが、企業はできる限り多くのベストプラクティスを借りて、すでにEAとSOA SOA、またはそのことについてのEAのいずれかの形式を学ぶことを計画している場合は、ベンダーから、またはさらに悪いことに、SOAの努力の成功全体を危 むしろ、(無料で)SOA参照アーキテクチャを活用して、より速いペースで、より低いリスクで進めることができます。 シャルトルのバーナードは、よく知られている言葉でそれを最高に置きます：”私たちは巨人の肩の上の小人のようなものです。”他のエンタープライズアーキテクチャの巨人の肩の上に立って、彼らはあなたのビジョンと成功を高めましょう。