InfoQ

News

ソフトウェアアーキテクチャでありがちな間違いトップ10

作者 Niclas Nilsson, 翻訳者 編集部 投稿日 2007年10月17日午前4時28分

コミュニティ: Architecture
トピック: エンタープライズアーキテクチャ
タグ: Checklists and Guides

IASA Fellows(サイト・英語)の一員であるEoin Woods氏(サイト・英語)は、ソフトウェアアーキテクチャにおいて一番ありがちで大変厄介な間違いが何であるかという事に関する記事を書いている。下記はその10個のポイントを簡潔に引用したものである(source)。

スコープの問題　”シンプルな予約システムだが多大なる構築コストがかかってしまった状況では、当然プロジェクトのコストや時間軸や品質に影響が出てくる。シンプルなログイン以外にはセキュリティが必要ないのは本当だろうか？システムに一度ログインしたらユーザーは本当にどんなシステム動作でも行うことができるのだろうか？"
ネットワークを幅広く把握できていないこと　”私たちがよく犯していた過ちは数人のシステムステークスホルダーだけに注目していた事である。従来的にその取得者（システムのコストを負担する人）とエンドユーザーのみに焦点を当てていたことである。"
機能のみに集中していること　”システムが幅広い領域で品質（パフォーマンス、セキュリティ、保持性等）を証明していな限り成功は見込めないだろう。"
ボックスとライン解説　”巨大なVisioの図がアーキテクチャ解説と同じように、効率良く働かないのには二つの理由がある。一つ目は単一の表示に過度の情報を表示しようとしていることである。二つ目は誰も自分が描いた画像がそれぞれが何を意味しているかあまり把握していないことである。”
構築されるべきであることを忘れていること　”システムの構築に関して気を付けなければいけないのはデベロッパやテスターがあまり理解していないデザイン、彼らがあまり思い入れのなく学ぶ時間もないテクノロジー、そしてまだ良いツールサポートがない、またはあまり馴染みのない働き方を強要されるような新たなテクノロジー等が含まれていることである。"
プラットフォーム正確性の欠如　”プラットフォームを特定する時、単純に「UnixとOracleが必要です。」と言うだけではもう十分ではないのです。自分が必要とするものを的確に得るには、特定のバージョンとそれぞれの部分の設定に関して忠実でならなければならない。こうすることによって他の何かが機能しなくなるということを知らずに、誰かがご親切にプラットフォームの一部のライブラリをアップグレードしてしまったために自分がシステムをデプロイできないという状況を防ぐのである。"
パフォーマンス作成とスケーラビリティ想定　”早いうちにパフォーマンスとスケーラビリティに関して考慮し、キーパフォーマンスメトリックを予想してパフォーマンスモデルを作り、デザインのアイデアを形成するのと同時に障害を発見し、実際に可能である何らかの作業に没頭するのだ。こうすることによって、あなたのデザインにパフォーマンスやスケーラビリティの障害が潜んでいないという自信に繋がるのである。"
DIYセキュリティ　”たくさんのシステムにおいておかされてきた過ちは、"自家製"セキュリティテクノロジーを使用してセキュリティをシステムに導入しようとしていたことである。カスタムされた組み込みアルゴリズムでも、開発者の独自の監査システムか全体的なDIYアクセスコントロールシステムでも、自分で開発したセキュリティ解決策が良い案であることは稀である。一方ほとんどの人々が効率の良いセキュリティテクノロジーを瞬時に作り上げることができると考えているが、それは間違っているのである。”
障害回復の欠落　”DRメカニズムをシステムに実装するためのリソースを取得するコツは、たくさんのシナリオを想定してシステムの非有効性コストを具体的に数量化することである。もしもシナリオが実現する可能性を見積もることができたら、DRが重要であることを人々に納得させるのと、またそれを実装するのに必要な予算を正当化するためにこの二つの数字を使用することができる。”
障害回復プランの欠落　”システム、もしくはアップグレードのデプロイメントの間に何が起こっても良い様に、デプロイメントを始める前にその環境をステートにリストアするのを可能にするドキュメント、レビュー、同意された障害回復プランを用意すること。”