<< ITシステムにおけるツールの利用について | main | セッション共有について >>

スポンサーサイト

一定期間更新がないため広告を表示しています

| - | - | - |

ITシステムにおけるアーキテクチャについて

ITシステムの構築にあたっては、リファレンスシステムを選定して、真似ることから始めるべきだ。

リファレンスシステムとのFit&Gapを評価し、変化点・新規要素となるGap部分に注力して検討を行う。この、Gap部分の検討及び、プロジェクト期間中から保守・運用期間中に発生するインシデントや変更要求に対応していく中で、複雑さが高まり、拡張性・保守容易性が極端に低下してしまうことがある。アーキテクトは、システムが複雑になりすぎないよう、常にシンプルさが保たれているように、常に心がけている必要がある。

複雑さが増していく要因は、個々の要件に対する個別的な対応が積み重なることにある。変更要求やインシデントなどの起因となる要件に対して、コスト要因、構築中の環境遷移・テスト要件などで、「こうすればこうできる」、「このためにはこうすれば良い」という技術的な判断を個別に行うことで、機能的には個々の要件を実現できるものの、全体として複雑さが増してしまうことがある。

技術的な決定を下すに当たっては、「できるかどうか」だけではなく、以下のような観点を踏まえて、「やってよいか」という評価を実施する必要がある。

  • 新規の技術的構成要素が増えないか
  • 後続フェーズでの保守体制・コストの増加要因にならないか
  • 既存のアーキテクチャの連続線上に存在するか
  • 既存の他システム実績があるか(もしくは、他システムでも流用可能な仕組みか)
  • 局所的な例外要素とならないか
  • 普通はどうするものなのか
  • 業界トレンドに沿っているか

少人数で、頭を悩ませて考えることは、危険な兆候である。考えることは重要であるが、頭で考えたことは、多くの場合、机上の空論になりがちであり、複雑化し過ぎる傾向にある。何故ならば、机上で、現実的に遭遇し得るあらゆるケースを見切れるだけの検討を施すことは、非常に困難なことであり、微視的な課題・困難・要件については、技術的に「こうすれば、こうできる」という解決策が必ず策定できてしまうためだ。

考えることは重要であるが、そのためには、事例に基づく必要がある。イノベーションは、実現されて初めてイベーティブになるのであって、実現できなかった机上の空論には何の価値もないからだ。事例に基づけない場合は、机上で策定したソリューションが、現実的に効果があるかどうかを、小規模に検証してみることが有効となる。この取り組みは、PoCとかプロトタイピングとか呼ばれる。

また、、システムのTCOに責務を持つステイクホルダーに対して、トレードオフ(Pros&Cons)を提示して意思決定してもらうように計らう必要があるかもしれない。なぜならば、現場の担当者は、全体最適に対して、局所的な責務しか帯びていないことがあるからだ。例えば、構築・更改案件の初期投資コストに対してのみ責務を負っており、その後の保守・運用フェーズへの技術的負債の蓄積による負の影響についてはスコープ外となっているような場合が挙げられる。

アーキテクティングは、「あれも、これも」できるようにすることではなく、「あれか、これか」を選択して制約を設けることである。

| 日記 | comments(0) | trackbacks(0) |

スポンサーサイト

| - | - | - |
コメント



この記事のトラックバックURL
http://msugai.jugem.jp/trackback/1080
トラックバック
CALENDAR
Sun M T W T F Sat
1234567
891011121314
15161718192021
22232425262728
293031    
<< October 2017 >>
WATCH
SEARCH THIS BLOG
LATEST ENTRIES
CATEGORIES
SELECTED ENTRIES
RECENT COMMENTS
RECENT TRACKBACKS
Twitter
MY WEB SITES
PROFILE
ADMIN
MOBILE
qrcode
ARCHIVES
SPONSORED LINKS