はじめに

今回は「アーキテクチャはレイヤー構造じゃない」という話しをしていきたいと思います。これ、人によっては「なんの話？」という話題かと思いますが、アーキテクチャはレイヤー構造だ、というのは結構頻繁に出会う言説なので、この切り口で記事化してみました。

結論から言うと「アーキテクチャはレイヤー構造ではありません」が「アーキテクチャをレイヤー構造で捉えると有益な場合がある」が正確なところだと思います。そして重要なことは「アーキテクチャ設計をレイヤー構造で行うのはまずかなり難しい」し、だからこそアーキテクチャって凄く便利であるということです。具体的にどういうことなのか、またどういった場合にレイヤー構造で捉えると有益なのかの例を書いていきたいと思います。

これを説明するにあたって、今回はちょと前段が重くなり恐縮ですが、標準を引用させてください。（違う、というからには根拠を示さねば）

アーキテクチャの定義（ISO/IEC/IEEE 42010:2011）

最初にアーキテクチャの定義を確認していきます。ISO/IEC/IEEE42010:2011 Systems and software engineering―Architecture description では以下の通り定義されています。

"fundamental concepts or properties of a system in its environment em
bodied in its elements, relationships, and in the principles of its design and evolution“ 

ということで、アーキテクチャの定義にはレイヤー構造や階層性は含まれていません。せっかくなので、もう少し見ていきます。42010で有名な図がFigure2 Conceptual model of an architecture description です。私はこの図がとても好きなので、スマホの待受やPCの壁紙にしています。ここで説明する主要なところを日本語にしました。

まず図の左上、System of Interest（SoI）は、ここで対象とするシステムです。（日本語だと意中のシステムという表現をとることがあります）
SoIは１つのアーキテクチャを持っています。アーキテクチャは1つのアーキテクチャ記述によって表現されます。
SoIには、それに関心を持つ利害関係者（ステークホルダ）が1つ以上います。そして利害関係者は1つ以上の関心事を持っています。関心事はアーキテクチャビューポイントで捉えられ、アーキテクチャビューを統制します。（governsというのが微妙に解りにくいですが、簡単に言うと関心事をアーキテクチャビューポイントで分類して捉え、その範囲でアーキテクチャビューを表現するということかと思います。ここのイメージはアーキテクチャ超概要②を読んで頂くとよりイメージが湧くと思います）そしてアーキテクチャビューは関心事に対応します。
アーキテクチャ記述はアーキテクチャビューの集合で構成され、利害関係者と関心事を特定します。図中でにに日本語化が出来ていませんがCorrespondence Rule（対応とか関係のルール）、Correspndence（対応とか関係）といった、ビューをどう対応付けるか等もアーキテクチャ記述に含まれます。

つまり、ISO/IEC/IEEEの標準では、利害関係者の持つ関心事を幾つかのビューポイントで分類して捉えたものの表現がビューで、ビューの集合とその関係性でアーキテクチャ記述を構成し、アーキテクチャを表現するということになります。
アーキテクチャそのものに「レイヤー構造である」という前提は存在しないことが分かりました。

ビュー間の関係性はレイヤー構造で表せるのか？

さて、アーキテクチャ記述の構成要素について説明してきましたが、ここでの論点はアーキテクチャを表現する上で必要な「要素」と「要素間の関係性」、特に「ビュー」や「ビュー間の関係性」をレイヤー構造として表現できるのか？という事かと思います。結論としては「表現できる場合がある」ということかと思います。

そもそも、なぜビュー間の関係性を示す必要があるのかというと、「複数のビューがどういう関係なのか？」ということを示すことで、このアーキテクチャがどの様に目的を達成しようとしているのかがトレーサビリティを確保した形で表現され、その妥当性が確認できるからです。（余計なものがない、足りないものがない状態）
つまり、アーキテクチャを描くということは、今考えてているものが単なる思いつきではなくて、全体として整合がとれた形で目的を達成する仕組になっているのだ、ということを示すための手段になります。

では、レイヤー構造とは何でしょうか。検索してみたところ、IT用語辞典e-Wordsでは以下の通り「レイヤー」が説明されています。

レイヤーとは、層、階層、層にする、層をなす、などの意味を持つ英単語。何かの構造や設計などが階層状になっているとき、それを構成する一つ一つの階層のことをレイヤーという。

その上で、「機能階層」と「画像処理」とで詳細の説明が分かれていますが、簡単にまとめると機能階層の場合は下位層を前提とし上位層が成立するもの、画像処理の場合は各レイヤー間に関係がないもの、となっていました。（詳細は原文をご参照ください）
ですのでレイヤー構造と呼ばれるものには、①下位層と上位層に関係があるもの、②レイヤー間には関係性がないものの２つがある前提で考えてみたいと思います。

まず説明の簡単な②に関してですが、こちらはそもそもレイヤーの間に関係がないのでビューをレイヤーとして表現するとビュー間の関係性が表現できません。なので、アーキテクチャの表現としては不足することが分かります。

では①下位層と上位層に関係があるレイヤーを考えた場合ではどうでしょうか？
アーキテクチャ超概論①で、アーキテクチャには「目的」、その目的を実現するための「やるべきこと」、そのやるべきことの「実現手段」がアーキテクチャの基本と書きました。この３つを考えた場合にはレイヤー構造として成立しそうです。

「目的」は「やること」を通じて実現され、やることは「実現手段」で実現される構造になっています。「目的」が「やること」を介さず直接「実現手段」に繋がることはなさそうです。（実現手段がやることのenablerであり、やることが目的のenabler）
しかしアーキテクチャ超概要②で示したように、アーキテクチャを設計する上では他のビューも必要になります。以下、些末ですが「焼き鳥の串」の例で説明します。

　例えばこの「焼鳥の串」において、「機能」は「物理」により実現されますし、「長さ」「価格」「耐燃性」も「物理」で実現されています。では「長さ」は「価格」によって実現されるのか、もしくは「価格」は「長さ」で実現されるのでしょうか？これらはそれぞれ別なビューポイントの話しであり、どちらかがどちらかの実現手段となっているレイヤー構造で表現するには無理があることが分かります。まさに、観点が異なると言えます。
ちなみに上図の機能のビューの４つの要素は実現手段の３つの要素や長さの３つの要素に割り当てられることで、この機能がどの様に実現されようとしているのかが説明されています。これにより、この実現手段や長さに決定した根拠のトレーサビリティが取れる状態となっています。

他の例で説明します。例えばSociety5.0のリファレンスアーキテクチャというものがあります。（システムアーキテクチャとリファレンスアーキテクチャは別なものですが、そこは別途説明します）

これを先程の焼鳥の串と同じ様に考えてみます。例えばビジネスは組織を実現するものでしょうか？それとも組織はビジネスを実現するのでしょうか。もしくは戦略・政策を実現する上でルールは必要なものかもしれませんが、ルールは組織がなければ実現しないでしょうか？ルールは組織の在り方を規定するものとも考えられますが、同時に、組織だけではなくビジネスやデータ連携の在り方など、色々なところに掛かってくるビューポイントではないでしょうか。これらは隣り合ったレイヤーだけが関係している訳ではなく、それぞれのレイヤー間で関係性が発生していると見えます。つまり、このレイヤー構造ではビュー間の関係性を表すことは難しいことになります。

アーキテクチャの「ビューポイント」「ビュー」の概念を説明する際に、三面図が使われることがありますが、３次元の物体を表現する時に正面から見た図、上から見た図、側面から見た図は、それぞれ別なものを定義しているのであって、その関係性はenablerの関係性やレイヤー構造で説明することは出来ません。

まとめると、システムのアーキテクチャを示すときにenablerとなるレイヤー構造以外を使って全体像を表現することは、まず難しいと言えます。複雑なシステムである程、表現できない関係性が増えます。アーキテクチャの要素間の関係性を示せないということは、そのアーキテクチャの妥当性を説明する上で不足がある、という状態になります。

では、アーキテクチャをレイヤー構造で説明することは不可能かというと、全く不可能な訳ではありません。例えば特定のビューに絞ってenablerの関係を表現する場合、システムの内部を説明せずに、システム間の関係性（もしくはサブシステム間の関係性）を説明する場合には、レイヤー構造を用いて表現することが出来ます。

アーキテクチャをレイヤー構造で捉えると有益な場面とは？

では、敢えてアーキテクチャをレイヤー構造で捉えると方が良い時とは、どの様な時でしょうか？これは主にシステム間もしくはサブシステム間の接続性、相互運用性を検討する場面だと考えられます。
アーキテクチャでレイヤー構造を用いている例として有名なものにOSI 7階層モデルやスマートグリッドリファレンスアーキテクチャがあります。

これらは、接続するシステム同士がちゃんと繋がる為に必要なレイヤー構造を示しています。つまりシステム同士の接続性を表現するうえで必要な要素を表しているだけで、システムの全体像を表しているものではありません。しかし、これらレイヤーの全てで接続性、相互運用性が担保できないと、他のシステムとうまく繋がらないという意味でアーキテクチャにおける重要な要素を示していると言えます。

先程ご紹介したSociety5.0のリファレンスアーキテクチャも同様に、複数システム間の相互運用性や横並びでの比較検討のために必要なビューポイントを示しているものと考えられます。

まとめ

今回は、アーキテクチャはレイヤー構造ではないし、レイヤー構造でシステム全体を表現するのは難しい。しかし、レイヤー構造を使って説明した方が良い場合がある、という話をしていきました。

システムアーキテクチャを使って何かを表現する時、例えば、これから実現しようと考えているシステム全体のコンセプトを誰かに説明する時、もしくはシステム間の相互運用性を示そうとしている時、アーキテクチャを表現する上での優先順位は目的によって異なります。レイヤー構造を使うとシステム間の相互運用性を説明する場合に役立つことはありますが、システム全体のコンセプトをアーキテクチャとして示す上では不十分ですし、また「設計したアーキテクチャのあるビューを切り取って説明する」上では使えますが「レイヤー構造のままアーキテクチャ設計を行うこと」はかなり難しいです。もちろん他システムとの相互運用しを考慮するためのビューポイントを意識して設計することは有用です。

今回の記事では、未だアーキテクチャ設計をレイヤー構造で行うことができない理由の十分な説明と、また関連して紹介しておいた方が良いと思われる「システムアーキテクチャ」「リファレンスアーキテクチャ」と、ついでに「アーキテクチャフレームワーク」の違についての説明までたどり着きませんでした。
この辺りについては次回、少し丁寧に説明してみたいと思います。