読者です 読者をやめる 読者になる 読者になる

勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

ITアーキテクチャの定義

以前「ITアーキテクトとは何か」という生煮えの頭の体操のような記事を公開したのだけれども、いただいた意見の中になるほどというものがあった。『「ITアーキテクト」という職種がエンジニアの上位職種みたいに定義されるからおかしいことになる。ITアーキテクチャを作る仕事をする人がITアーキテクトと呼ばれればいいだけのこと』 ・・・なるほど。
では、ITアーキテクチャとは何かについて、いまさらながらに整理をしてみる試み。この記事も生煮えでオチも無い予定。
http://www.flickr.com/photos/23266521@N02/3512395271
photo by Francisco Sánchez

書籍「システムアーキテクチャ構築の原理」による定義

システムアーキテクチャ構築の原理では、ソフトウェアアーキテクチャについて以下のように説明している。

コンピュータシステムを理解しようとする場合、関心を持つのは、その個々の部分が実際に何をし、どのように一体となって働いたり、周囲の世界と相互作用したりするか、言い換えれば、そのアーキテクチャについてである。文献にあって、アーキテクチャの社会で広く受入れられているアーキテクチャ最高の定義は、米国ペンシルバニア州ピッツバーグにあるカーネギーメロン大学ソフトウェア工学研究所(SEI)のソフトウェアアーキテクチャグループによるものだ。

定義 ソフトウェア集約システムのアーキテクチャとは、システムの1つまたは複数の構造のことで、それはソフトウェア要素と、その要素の外部から見てわかる特性、およびそれらの関係から成り立つ。

システムアーキテクチャ構築の原理 ITアーキテクトが持つべき3つの思考 (IT Architects’Archive ソフトウェア開発の実践) 第2章 ソフトウェアアーキテクチャの概念

同書ではこの定義についての解説が続く。ざっくりとまとめると次のような構造である。

  • システム構造
    • 静的
    • 動的
  • 外部特性
    • 外部から見てわかる振る舞い
    • 品質特性

ソフトウェアシステムアーキテクチャ構築の原理 第2版 ITアーキテクトの決断を支えるアーキテクチャ思考法

ソフトウェアシステムアーキテクチャ構築の原理 第2版 ITアーキテクトの決断を支えるアーキテクチャ思考法

  • 作者: ニック・ロザンスキ,オウェン・ウッズ,榊原彰,牧野祐子
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2014/09/26
  • メディア: 大型本
  • この商品を含むブログを見る

IEEE 1471による定義 (=ISO/IEC 42010による定義)

システムの構成要素、それら相互や環境との関係性、及びその設計と発展をガイドする原則を包含するシステムの基本的構造
IEEE 1471 - Wikipedia

IEEE 1471ではITアーキテクチャ記述の概念モデルも定義されている。
f:id:kent4989:20150407213838p:plain
なお不勉強で知らなかったのだけど、現在はIEEE 1471はISO/IEC 42010:2007「ソフトウエア集約システムのアーキテクチャ的記述のための推奨指針」に標準化されている。アーキテクチャ記述の概念モデルも変更されている。ITアーキテクチャ定義そのものは、IEEE 1417から変化はない模様。
f:id:kent4989:20150407213854p:plain
アーキテクチャ記述の概念モデルについては以下資料も興味深く、参考になった。

TOGAFでの定義

実はあまり勉強していないTOGAFでの定義も念のためチェック。

「システムの形式記述、あるいはシステムのコンポーネントレベルの実装を補助する詳細な計画」または「コンポーネント群の構造、それらの関係、設計と改良を常に管理制御する原則とガイドライン
TOGAF - Wikipedia

この2つの定義を文脈によって使い分ける、というのがTOGAFにおけるアーキテクチャの定義であるとのこと。

共通フレーム(SLCP-JCF2013)の定義

そういえばと共通フレームを確認してみたら、似て非なる定義がされていた。

システムのある境界(例えば、入出力系、プロセッサ、ネットワークなど)に対して、それらの外側から見た場合の概念的あるいは論理的な属性又は構造。「方式」と訳される場合が多い。
SECBOOKS 共通フレーム2013 (SEC books)

IEEE1471やIEC 42010とはすこし距離を置いている印象。

そもそも不可視で正確な表現をしにくいソフトウェアシステムの構造の話であって、明解な定義ができるものでもない。ただ、通常アーキテクチャを議論するということは、合意形成を目標としたものであるはずである。合意形成を目標にするのであれば、いったい何の議論をしているのか、という点を明確にすべきである。そういう意味で、いずれであったとしても、論じているITアーキテクチャのかたちについては一考したほうが良いのだと思う。