 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||
|
||||||||||||
| 個別のアーキテクチャの設計から個別へのアーキテクチャの徹底 | ||||||||||||
|
変更に柔軟であること。昨今の案件のRFPでことさら重視されるようになったのが、この点ではないでしょうか。このため開発プロセスを問わず、システムアーキテクチャに注目が集まっています。アーキテクチャをタイトルの一部に冠する本も書店で増えてきましたし、職種でもITアーキテクトなるものが技術者の目標のようにいわれています。 しかしこれまでのアーキテクチャ論は、個別のシステム単位で将来の拡張性を担保するという視点が強かったのではないでしょうか（それさえも、十分に難しいわけですが…）。SOA型の場合には、ESBで連携される際の全体アーキテクチャが必要であり、そのルールの中で個別のシステムを構築するという、「トップダウン的アーキテクチャ」の重みが増えてきます（それに従わないと、SOAを構成するサービスの1つとして機能しない）。 極論をすれば、「個別のシステム案件で、全体アーキテクチャでの位置づけを維持する仕組みをいかに構築するか？」ということが重要になってきます。 |
||||||||||||
| 利害関係者の多様化 | ||||||||||||
|
ビジネスへの貢献やビジネス課題との関連がより重視されるにつれ、要件定義のためのインタビュー相手にすぎなかった「業務のプロ」が、システムそのもののビジネスへの貢献を評価する人へと役割が変貌していきます。それにつれて、システム開発で関与する非技術系の人たちの範囲の関わり具合も変わっていきます。 |
||||||||||||
| 新しいベストプラクティス | ||||||||||||
|
前述の変化をふまえて、Rational Unified Processも変貌を遂げました。ベースになる基本原則が次のように変わります。その各々を見てみましょう。
表3：ビジネス駆動型のベストプラクティス
|
||||||||||||
| プロセスの適合（Adapt the process） | ||||||||||||
|
開発プロセスはチーム開発での成功のキーとなります。しかし多くの組織では、1つプロセスを決めるとプロジェクト形態の多様化を無視して強制適用する傾向があります。結果として非公式なバリエーションが増え、プロセスを決めることによって複数プロジェクト全体の底上げをはかるはずが、逆に管理しきれなくなります。 新しい原則では、プロジェクトの形態にあわせてプロセスも変更すべし、となります。製品としてのRational Unified Processでは、これをにらんでプロセスも編集可能な形態で提供しています。 |
||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
