アーキテクチャのアンチパターン

2009年5月18日(月)
細川 努

アーキテクチャのアンチパターン~Stovepipe System(ストーブパイプシステム)

 建築の世界では、数千年の歴史の中で、建築家(アーキテクト)という職業が重要な役割を果たしてきました。

 それに比べてソフトウエア開発の歴史はまだ70年ほどしかないのですが、建築の世界と同様に、ソフトウエアアーキテクチャおよびその設計を担当するアーキテクトの役割が重要性を増しています。

 われわれが日曜日に自宅でちょっと作ってみる程度のソフトウエアであれば、アーキテクチャなどは特に関係ないのですが、数百人以上のデベロッパーが参画するような大規模なプロジェクトであれば、アーキテクチャがしっかりしていないと混乱が生じたり、出来上がったシステムの性能や保守性に問題が出たりなどの弊害が発生します。

 そこで、今回はアーキテクチャに関してのアンチパターンについて、説明していきたいと思います。

 少し規模が大きいシステムになると、システムをいくつかのサブシステムに分割して構築することがよく見られます。このように、サブシステム間がつぎはぎだらけで、その場しのぎで統合されたシステムのことを、“ストーブパイプシステム”と呼んでいます。

 以下のような症状があれば、ストーブパイプアンチパターンにかかっている可能性があります。

・アーキテクチャの設計文書と実際に構築・実装したシステムとの間に大きな隔たりがある
・アーキテクトが統合化技術について知識がなく、経験もない
・システムの要件変更を行うと、とんでもない費用が発生する
・サブシステム間で新しいインターフェースを追加するのに大変な調整が必要になる

 特に、メインフレーム全盛の時代には、特定のベンダー固有のプロトコルを用いてサブシステム間を連携することが多く、現在でもその影響が残っているシステムも少なくありません。

 こうしたストーブパイプシステムの症状にかかると、システムの運用・保守や、新しいサブシステムを追加する際に大変な手間とコストに悩まされることになるのです。

 ストーブパイプシステムの解決策としては、サブシステム間の実装の違いに影響されないよう、抽象化したインターフェースで連携できるようにすることなどが推奨されています。

 具体的には、Webサービス(SOAP、WSDL)など、相互運用性が高く、特定のプログラム言語に依存しない技術を用いることなどによって、ストーブパイプシステムの発生を予防できるのです。

Stovepipe Enterprise(ストーブパイプエンタープライズ)

 前述したストーブパイプシステムは、1つのシステムの中で、サブシステム間のインターフェースに混乱がある場合のことを説明していましたが、ストーブパイプエンタープライズは、企業全体のシステムが場当たり的に設計・構築されている場合のことを意味します。

 このように、企業内のさまざまなシステムに統一性がなく、個別に作成されている様を、サイロ(家畜の飼料を保管しておく倉庫)化とか、孤島化とも呼んでいます。

 以下のような症状があれば、ストーブパイプエンタープライズアンチパターンにかかっている可能性があります。

・全社的な技術戦略が欠如している
・システムのデベロッパー間で協力関係がない
・システム開発プロジェクト間でコミュニケーションがない
・社内の技術の標準化について議論がない

 このように、社内のシステムがまったくそれぞれ独立して構築され、そこで使われている技術もそれぞれ異なると、全体としての開発、保守、運用に関するコストが増加します。

 こうした問題を避けるためには、企業全体としての、技術の標準化や、全社レベルでのアーキテクチャの整理が必要になります。

株式会社アーキテクタス
(株)アーキテクタス 代表取締役 技術士(情報工学)大手シンクタンクで金融系システム構築等を経験。現在、総務省CIO補佐官として、総務省内のシステム構築への助言等を担当している。要求開発アライアンス理事 日本Javaユーザー会(JJUG)監事

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています