ITアーキテクチャ構築の勘所（3） － ＠IT
ITアーキテクチャ構築の勘所 第3回 機能的なアーキテクチャの設計 日本IBM ICP-エクゼクティブＩ/Ｔアーキテクト 河野紀昭 2006/1/6 アーキテクチャ要件の洗い出しに続くITアーキテクチャ設計のステップは、機能的なアーキテクチャ設計である。ここでは、システムを構成する機能をコンポーネントとして切り出して構造化するが、役割分担を明確にしたシンプルな構造を作ることが、良いアーキテクチャへの近道である。 今回から、ITアーキテクチャを具体化していくステップに入る。ところで、ITアーキテクチャというのは、そもそもどのようにとらえたらよいのだろうか。 私は、ITアーキテクチャを「ビジネスの要求にIT技術を用いて応えるための青写真であり、システムを構成する要素とその構造を、静的および動的に表したもの」と考えている。例えば、魅力的なWebサイトをオープンし、お客さまにたくさん買い物をしても
第2回 アーキテクチャ要件の洗い出し
連載記事「ITアーキテクトを探して」の第1回目「ITアーキテクトが備えるべきスキル標準」では、ITアーキテクトの役割を、『ビジネスの要求』に的確に応える整合性の取れたアーキテクチャの構築、としている。ビジネスの要求に応えるというのが重要なポイントで、ここがずれていては、いかに「かっこいい」ITアーキテクチャも無意味なものとなってしまう。 では次の2つの例では、どちらが良いアーキテクチャだろうか。 Aのアーキテクチャは、ネットワークにクラスタリングしたUNIXサーバを接続してWeb画面の処理を行い、ここから、必要に応じてバックエンドの既存のメインフレームの業務ロジックが呼び出すというもの。これは、典型的な3階層アーキテクチャであり、通常のオンライン・バンキングなどでは、「正しい」アーキテクチャである。これに対して、BはメインフレームとUNIXサーバの配置が逆になっており、一見、「変な」アーキ
開発現場の天国と地獄（5） ― ＠IT
短納期のJ2EE基幹プロジェクトの成功例。多数の汎用機の基幹システムとの連携を実装。短納期でのプロジェクト運営と設計実装の手本としてもよい。ただし、メンバーの負荷は高め、土日出勤、徹夜あり。ミッションクリティカルな場面でのMQ基幹連携や、短納期な大型プロジェクトにおける運営方法などの実績の場として最適。今後基幹（汎用機）システムのマイグレーション案件が多数出てくると予想される中で、先鞭的な案件。プロジェクトメンバーも良質、顧客もシステム理解・経験は豊か。 実は、システム開発という作業はツールやフレームワークの充実、IT業界自体の錬度の上昇により、かなり効率化されており、「短納期でお願いします」という要件に対して、以前より大分応えやすくなっています。ただし、そこには大きな誤解があります。ツールが充実したことで、「顧客が欲しいものを作る」時間が速くなったわけではないということです。プロジェクト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
