日本は先進国である
ミドルアウトにチェンジする
10/07/2010
日米財界人会議
沖縄は日本国自衛隊九州分隊が守ります － 九州国王・ホリエモン
日本国の自衛隊は州政府分隊に分割して、それぞれの国を守る － 総司令官首相、参謀防衛大臣
これをヤチマタの陣形と呼ぶ － 諸葛孔明
指令本部から、八首のキングギドラへ、指令を発する － 総司令官
指揮系統を明確化しないと、国防はムリ
総司令官＋参謀 ＝＞ 陸海空司令官へ
陸海空司令官 ＝＞ 八首へ
敵がどこから攻め込んでも、八首がそれぞれの地域を守る
これを万全の防衛と呼ぶ － 諸葛孔明
参謀へ
指揮系統を整備して、コンパクトな自衛隊を編成せよ － 総司令官
アメリカのシティ・バンクのCOOの観点は？
アメリカ経済は、財政政策で、回復できるまでには、至っていない
よって、FRBの金融政策に頼らざるを得ない
つまり、
金融緩和と元の切り上げ
財政政策で、回復できない
つまり、アメリカの経済構造の改革が不十分である
という認識である
ここで、中間選挙のテーマになる
１．民主党の改革は？
ひとつ、懸案の情報ハイウェイ、グラスルーツ革命
ひとつ、軍縮ビジネス、重大長高産業から環境ビジネスへ
ひとつ、労働改革、社会保障よりも、雇用を・・・
２．共和党の改革は？
ひとつ、ティーパーティによる情報革命
ひとつ、軍拡競争で雇用の創出？
ひとつ、小さな政府、官から民へ、民活、経営改革
AO
日本はどうすべき？
グラスルーツか？ ティーパーティか？
軍縮ビジネスか？ 軍拡ビジネスか？ 環境ビジネスか？
中くらいの政府？ 親方日の丸を脱却するための労働改革、経営改革
これらに伴う税制改革は必至・・・
視点は？
軽薄短小産業は？
重大長高産業は？
行革は？ 構造改革＋制度改革
個人的な視点は？
情報産業がモノ産業をリードする
つまり、
軽薄短小産業＝情報ネット ＞ 重大長高産業＝物流・交通ネット
行革は？ まずは、構造改革、州政府制を念頭に入れて、地方分権、地方自治
トップダウンの国政、ミドルアウトの州政府、ボトムアップの自治
これじゃないかと思っている・・・
電波塔のみなさんへ
電波塔のみなさんへ
つまり、中堅社員が先頭を切って、改革しろ～～～
つまり、橋下大阪府知事がリードしろ～～～、
分かった？ 言わんとすることが・・・
だから、、、
PC iPad（タブレット） iPhone（スマートフォン）
だから、電子書籍（iPad）は最重要である、新聞、雑誌、本、
これも、ミドルアウトのひとつ
ボトムアップエラーは？ 鳩山劇場
沖縄基地問題を住民問題にすり替えた
トップダウンエラーは？ 小泉劇場
改革～～～、法螺だった・・・
分かった？ 国民のみなさん？
ミドルアウトとは？
ITRではSOA実現のステップを図1のように4つのステップで定義している。それぞれのステップごとに、課題および留意点とその解決に向けた基本的な考え方を紹介する。
ステップ1：現状調査
このステップでは現状のシステムやアプリケーションについての棚卸しを行う。多くの企業においてシステムは継続的に変化しているため、稼働当初に書かれたドキュメントとシステムの実態が異なっている可能性がある。そのため、システム全体の俯瞰（ふかん）図を作成することは非常に重要だ。俯瞰図にシステム名、所有者、ビジネスプロセス、システム間インタフェース、使用されている技術、現在の利用状況と問題点などの情報を盛り込む必要がある。
さらに、サービス化すべきプロセスを選定するのだが、この判断を行うには幾つかのアプローチが考えられる（図2）。
ボトムアップ型の意思決定は、現場の声を反映するという点では適切であるが、「局所最適」という弊害が生じるリスクがある。システムが縦割り化し、相互運用に困難をきたす状況である。日本企業のほとんどが多かれ少なかれこのような問題を抱えている。ゆえに、アーキテクチャー設計プロジェクトがトップダウン型で推進されるのは当然の流れであろう。
もともと、アーキテクチャーという言葉自体に共通の標準をトップダウンで決定していくというニュアンスがあるのは否めない。しかし、トップダウン志向が強すぎると、別の問題が発生する可能性が出てくる。
まず、大規模企業のすべての情報システムに対して共通の規約や仕様を決定していくことは、その作業負荷を考えると非現実的といわざるを得ないケースが多い。また、各現場の状況を無視した全社的標準を強制することは、かえって変化への迅速な対応を妨げるおそれがある。さらに、現場の特殊事情を無視し、重要な例外処理が見逃されたり、アーキテクチャーから排除されたりすることで、現場の効率や顧客サービスの質をかえって悪化させることもある。
どちらのアプローチにも一長一短があるとすると、アーキテクチャー設計においては、トップダウンとボトムアップを組み合わせたアプローチが必要となる。このアプローチは「ミドルアウト」と呼ぶことができる。各アプリケーション内ではトップダウン的な厳密なアーキテクチャーを適用し、複数アプリケーション間ではボトムアップ的な柔軟なアーキテクチャーを適用するという考え方である。
ミドルアウト型アプローチの留意点
ミドルアウト型のアプローチでサービスを抽出する際には、以下の点に注意することを推奨する。
- 業務上の重要性が高い
- 利用頻度が高い
- 使用ユーザーが多い
- 変化の頻度が高い
- 複数のシステムで使用されている
また、以下のような、サービス化に向いていないシステムやアプリケーションを無理にサービス化しないことも重要となる。
- ほかのシステムとの関係がなく単一のシステム内のみで利用されているプロセス：これは、将来的にも単一システムのみで利用されている場合はサービス化するメリットはない。
- 非常に高いパフォーマンスを要求されるプロセス：SOAはサービス間を疎結合とするために、サービス間での転送は非同期通信を採用する。そのためにサービス間でのデータの受け渡しにオーバーヘッドが発生する。
- 一括大量のバッチ処理：サービス化するとは、固有のプロトコルを標準のプロトコルに変換して接続することであるので、単一のフォーマットやコードの変換を一度に大量に行うような処理には向かない。
ステップ2：サービス要件の定義と管理体制の確立
サービスは複数のプロセスからの利用を前提とするので、変更の手続きを明確にしておかないと障害が発生してしまう可能性がある。また、サービスは再利用を前提とするため、カタログ化とカタログの更新に関する責任と手続きを明確化しておくことも重要となる。SOAの実践において、技術の実装は1つのステップにすぎず、注力すべきはライフサイクルにわたってサービスを管理維持していくためのルールと体制の構築である。
0 件のコメント:
コメントを投稿