BSA
ターキテクチャによるビジネスモデルのサポート（Tarchitectural Support for the Business Model） †
- あなたの製品が複数のビジネスモデルから成り立っているなら、それらの主要な相互作用をチェックしよう。
- ビジネスモデルに変更がある度に、それらの要素を見直すこと。ビジネスモデルの変更は、それまでの前提条件や決定を無効化し、ターキテクチャの変更を促すことがあるから。
一般的な検討事項（General Issues） †
必要なデータを集める（Capturing the Necessary Data） †
- そのビジネスモデルを実現するために必要なデータをシステムが集めているか。
- 直接 - そのシステム自身が収集するデータ
- 間接 - そのシステムが他の連携システムを通して取得するデータ
- トランザクション、メーター式のビジネスモデルなら、自分でデータを集めるか他のシステムからデータを取得する。
- サービスベースのビジネスモデルなら、たいていは支払処理システムやCMSなどの他システムと連携する必要がある。
請求書／送金の要求（Reporting/Remittance Requirements） †
- ビジネスはどこかで請求する必要があるので、その請求処理に求められる形式、セキュリティ、監査の要求を定義しておくと後が楽である。
ビジネスモデルの施行（Business Model Enforcement） †
- もしユーザがライセンス違反をしたらどうするか？ システムを止めるか？ ログに記録すべきか？ Eメールを担当者に送るか？ 新たな請求／ライセンシングのサイクルを自動的に開始するか？
ilityの強化（Forcing ility Efforts） †
- ターキテクトが ility に費やした努力は、本来はビジネスモデルの主要目標と一致しているはず。
- 例えば、様々な金融取引を処理する金融サービスでは、信頼性、正確性、パフォーマンスが、システムのインストール／アップグレード容易性よりも優先される。
- サービスベースのビジネスモデルでは逆に、テクニカルサポートへの電話を減らすために、パフォーマンスよりもインストール／アップグレードの容易性が優先されるかもしれない。
収益向上またはコスト削減（Increased Revenues or Decreased Costs） †
- ビジネスモデルの定義後は、ターキテクチャへの投資を収益向上に集中させがちだが、ターキテクチャが顧客に課すコストも忘れないように。
- 顧客へのコストを減らせれば、潜在的に収益向上の可能性が増える。例えば、インストール／アップグレードの容易化やパフォーマンス／後方互換性を向上することで、ユーザがアップグレードの度に新しいハードウェアを買わなくて済むようにする。
コピー防止／海賊行為防止（Copy Protection/Antipiracy Protection） †
- ハードウェア依存でコピーされにくいソフトウェアもあるが、ほとんどは違法なコピーと配布の脅威に晒されている。
- そうした海賊行為にいくらの損害が出てるかに応じて、どれだけのコピー防止機構を導入するかを検討すべき。（後で詳説）
ビジネスモデル／ライセンスモデルのパラメータ検証（Verifying Business Model and License Model Parameters） †
- 多くのビジネスモデル／ライセンスモデルはパラメータを持っている。
- 年間ライセンスは期限、同時ユーザ数ライセンスは同時ユーザ数、消費型時間ベースライセンスは残りの時間、など。
- 重要な検討ポイント：
- いつ、どこで、どのようにその値をセットするか
- 誰がそのパラメータを変更できるか
- どうやってその値を検証するか
- この話題は簡単な話ではないので、本章後半で詳しく述べる。第16章のSecurityも参照。
時間ベースのアクセスまたは利用（Time-Based Access or Usage） †
- 時間ベースのアクセスまたは利用によるビジネスモデルは、厳密に時間を管理する必要がなければ、ターキテクチャへの特別な要求はほとんどない。
- もし厳密な時間管理をしたいなら、許容された時間を超過したらソフトウェアを無効にする仕組みが必要になる。
- 多くのサブスクリプションモデルは、サブスクリプションを更新しなかったら単にアップデートが受けられなくなるだけ。（永久ライセンス）
