Customer Influences on Deployment Architectures †
要約 †
- 顧客の期待に見合うデプロイメントアーキテクチャを選択するための観点
- 管理と統合
- セキュリティ、プライバシー、ピーク負荷
- コストとベンダーへの信頼
- 顧客のスキルと経験、地理的な分布
- 管理と統合
- マーケテクトはこれらを理解しておかなければならない
- エンタープライズクラスのソフトウェアの管理について求められることはほとんど決まっている
- ソフトウェアを動かしているインフラを管理したいこともある
- ミッションクリティカルなソフトウェアなら顧客サイトで運用しているのと同じくらいの即応性、管理性が求められる
- 信頼できるサービスプロバイダーにはお任せすることもある
- 長期的なデータの保全が問題になることもある
- システムを統合したいがためにデプロイメントが顧客サイトになることもある
- セキュリティ、プライバシー、ピーク負荷
- システムの扱うデータの性質によってデプロイメントアーキテクチャに対する顧客の抱く印象が異なる
- 病院関係者の給与支払い情報と患者の診断情報の取り扱いの慎重さは異なる
- プロフェッショナルサービスファーム
- 弁護士事務所や会計事務所など
- プライバシーを守ることが重要なのできっと顧客サイト
- ピーク負荷が高くなる場合はASPやMSPのほうが費用対効果が高くなるかも
- コストとベンダーへの信頼
- xSPのほうが安く付く場合がある
- 運営している会社のイメージ次第で、顧客から疑いの眼差しを向けられてしまうかもしれない
- マーケティング素材では、自分たちの長期的な生存可能性を示さないといけない
- 古いデータを要求されることに備えて、ちゃんと設計すること
- 顧客のスキルと経験、地理的な分布
- 顧客側の担当者に求められるスキルには幅がある
- ベンダーとしては運用を顧客に全部任せるほうが簡単
- xSPだと顧客の要望を聞いてあげないといけない。ときどき暴走するので面倒
- データセンターを構築できるほどの人材を確保しなければならないかもしれない
- 運用のスタイルは社風にも影響されるので、いきなり切り替えるのは大変
- 顧客の要望に見え隠れする履歴書駆動設計、投資家駆動設計に注意すること
- ある時期に登場したxSPはほとんど失敗した
コラム †
- クレジットカード情報を粗末に扱わないようにしよう
- ディレクターが顧客のクレジットカード番号入りのxlsをどうにかしちゃったインシデントが発生
- やってはいけないこと
- 顧客には、詳細なレビューと、監査を要求する権利がある
- リスクが大きくなりすぎたときは......
- 顧客サイトへのデプロイメントでしばらく上手くいっていたが、費用が掛かり過ぎるのが問題だった
- ASPに切り替えるための検討を始めたところ、扱うデータがセンシティブなのでしっかりとしたインフラ、厳格な規則が必要なことがわかった
- また、グローバル企業な顧客からは世界各地における24/365の可用性とサポートが求められていた
- 顧客としてはMSPを期待していた
- なのに
- ASPモデルが軌道にのるまでMSPに追加投資しないことにした
- その後会社は倒産した
担当者のつぶやき †
みんなの突っ込み †
