アーキテクチャ設計とは
アーキテクチャ設計は、システムのコンポーネント (構成要素) と、コンポーネント間のインターフェース (連携方法) を決めることに他なりません。アーキテクチャ設計により、システムはコンポーネントの集合体として再定義されます。コンポーネントには責務が与えられ、他コンポーネントとのインターフェースが指定されます。コンポーネントは、この責務とインターフェースを満たすように設計・実装されなければなりません。そのために各コンポーネントはまたそれぞれのアーキテクチャを持つことになります。アーキテクチャ設計は、それが自明、既知、実装済みなレベルに到達するまで、ブレイクダウンされていきます。
アーキテクチャのレベル
アーキテクチャのレベルは例えば次のような形になります。厳密なものではなく、状況に応じて適切なレベル感で記述します。- エンタープライズレベル
- コンポーネント: 部門、部署、顧客、取引先 等
- インターフェース: 手続、連絡手段、様式 等
- インターシステムレベル
- コンポーネント: 社内システム、外部システム 等
- インターフェース: 接続/通信方式、介在業務 等
- インターサービスレベル:
- コンポーネント: サービス
- インターフェース: プロトコル、ファイルフォーマット 等
- フレームワークレベル:
- コンポーネント: フレームワークコンポーネント、ライブラリ 等
- インターフェース: 呼び出し、コールバック、キューイング、メッセージング、バッチ 等
- コードレベル:
- コンポーネント: メソッド、関数 等
- インターフェース: 引数、戻り値、データ構造 等
アーキテクチャ設計と非機能要件
冒頭でも述べましたが、極端なことを言えば、業務要件の実現にややこしいアーキテクチャ設計は必要ありません。極端な話、多くの場合はコンピュータシステムが無くても、人間が紙とペンでがんばれば、出来ないことはないものです。しかし実際には、コンピュータシステムが必要であったり、既にシステム化されていたとしても、新しいシステムに変更する必要性があります。それは、業務要件とは違うビジネス上の要請、非機能要件のためです。非機能要件を実現するためにコンピュータシステムが必要で、そのためにはアーキテクチャ設計が必要なのです。非機能要件は、明確化するのがとても難しい領域です。ある程度高い水準で実現しなければならない一方、少し実現レベルを上げるだけで、コストや期間が一気に増大することが多いので、常に適正水準での妥協が必要です。
非機能要件の観点は、インターサービスレベルから上の粒度であれば、IPA 非機能要求グレードなどを参照すると良いと思います。例えばIPAでは以下の6カテゴリーに分類しています。
- 可用性
- 性能・拡張性
- 運用・保守性
- 移行性
- セキュリティ
- システム環境・エコロジー
これら全てに対して、コスト・スケジュールとの兼ね合いを考えて実現レベルを決める必要があります。フレームワークレベル以下の粒度については、上位で決めた非機能要件を満たせるであろうように考慮して、決めていく必要があります。
特に重要なことは、未知の変更に対する弾力性・包容力
私は、アーキテクチャ設計において特に重要なことは、未知の変更に対する弾力性・包容力だと考えています。これは、コンポーネントが適度に適切に分割されていることと、コンポーネントが入れ替え可能であるように責務とインターフェースが決められていることに帰着します。アーキテクチャ設計の観点
私がアーキテクチャ設計を行う際、以下のような観点を意識しています。
- 非機能要件と、業務要件、コスト、スケジュールの間でコンフリクトが起きそうな事項は、重点的に必要性を確認する
- 非機能要件に以下のようなキーワードが出てきたら要注意
- リアルタイムで
- 直ちに
- 早く
- 同時に
- 必ず
- 確実に
- 絶対に
- 100%
- 永久に
- 無停止で
- 最優先で
- 全てのブラウザで
- 常に最新の環境で
- BCP (事業継続計画)
- DR (災害対策)
- キャパシティの余裕率は増強リードタイムに依存する
- 高い余裕率は当然コストにはねる
- セキュリティ、コンプライアンスは関連部署のチェックを早い段階で入れる
- 代替案の無い変更指示を受けることが多いので、後回しにするとコスト、スケジュールへの影響が出やすい
- 保守性は「テスト可能性」と言い換えると分かりやすい
- テストを分割する境界の構築、ログ、リソース監視、エラー監視、検証環境の有無、……
- 妥協したこと (=残存させたリスク) と、その理由はちゃんと残す
- 複数案作って各案について全部残しておく
- 全体的に「未知の変更に対する弾力性・包容力」のチェックを行うこと