Northern Electronics シナリオ: IT 組織におけるビジネス オペレーション要件のサポート

  • [アーティクル]

アーキテクチャ クロニクル

動的モデリング: ビジネスと IT の連携

Max Morris
Frederick Chong、Jim Clark、Dave Welsh

September 2005

日本語版最終更新日 2006 年 2 月 3 日

適用対象:
   エンタープライズ アーキテクチャ
   ソリューション アーキテクチャ
   Service Oriented Architecture (SOA)
   Service Oriented Management (SOM)
   アプリケーション統合
   ビジネス プロセス
   ビジネス オペレーション モデリング

要約: アーキテクチャ クロニクル「動的モデリング: ビジネスと IT の連携」では、ビジネス、ソリューション、およびインフラストラクチャのアーキテクトに対して、動的モデリングによってビジネスと IT を融合する全体的かつ統合されたアプローチを提示し、実績、説明責任、および業績の向上への道を模索します。Northern Electronics がビジネス パートナーと連携して製品出荷プロセスを改善するというストーリーを使用して、多数のドメインからの情報を再利用可能な構造化された連携モデルに形式化するための体系的なアプローチについて説明します。このアプローチによって、ビジネス オペレーションと IT オペレーション相互の交流の促進が可能になり、その結果、業績が向上し、パートナーとの関係が強化されることを示します。この記事には英語のページへのリンクも含まれています。

目次

このドキュメント
概要
謝辞
はじめに
シナリオの背景
製品出荷アクティビティのモデリング
製品出荷のビジネス オペレーション要件
製品出荷ソリューションを構築する
まとめ

このドキュメント

このドキュメントは、アーキテクチャ クロニクル「動的モデリング: ビジネスと IT の連携」の一部です。このシリーズでは、ビジネス、ソリューション、およびインフラストラクチャのアーキテクトに対して、動的なモデリングによってビジネスと IT を融合する全体的かつ統合されたアプローチを提示し、実績、説明責任、および業績の向上への道を模索します。「Microsoft Architecture Resource Center」に、最新情報と相互参照を含むこのシリーズの案内が掲載されています。

概要

組織の境界を越えてビジネス オペレーションを効率的に運営することは、難しい課題です。しかし今日のネットワークで接続された世界では、この課題に取り組むことがますます重要になってきています。この課題を解決する秘訣は、組織内のビジネス オペレーション チームと IT オペレーション チームの密接な連携を確保することです。この論説では、実世界のビジネス上の問題を詳細に検討し、連携の作成と課題への対応に伴う問題を明らかにします。特に、IT 組織でのビジネス オペレーション要件のサポートが、問題解決の重要な要素になり得ることを示します。

謝辞

ご支援、ご協力いただいた Nelly Delgado (テクニカル ライティング)、Claudette Siroky (グラフィックス スキル)、Tina Burden McGrayne (原稿の整理、編集) に、大いに感謝いたします。

また、Northern Electronics ソリューションの実装に寄与していただいた Gajanan Phadke、Vishal Kapoor、Amol Wankhede、Aziz Matheranwala、Amit Kumar Srivastav、Bhushan Pawade、Bhasha Johari、Avadh Jain、Mughda Gadre、Maneesha Nalawade、Sonika Arora、Anil Sharma、Anurag Katre (Tata Consulting Services の皆様) に厚くお礼を申し上げます。

また、このドキュメントを説明するために使用したビジネス オペレーション モデリングの概念実証ワークシート ツールの開発およびドキュメントに寄与していただいた Klaus-Dieter Naujok および Allyson Winter (Global e-Business Advisory Council) に対してもお礼を申し上げます。

はじめに

このドキュメントでは、Northern Electronics がビジネス パートナーと連携して製品出荷プロセスを改善するというストーリーに従って展開します。このシナリオと論説は、バリュー チェーンの中でのビジネス相互の交流についての共通の特徴を描写するためにデザインされ、まとめられています。シナリオは物語風に描かれています。全体を通じて 1 つの例を取り上げることにより、IT ソリューションによってビジネス オペレーション要件を満たそうとするとき、人とテクノロジが直面する主な問題と可能な解決策を示します。この論説では、多数のドメインからの情報を再利用可能な、構造化された連携モデルに形式化する体系的なアプローチに従うと、ビジネス オペレーションと IT オペレーション相互の交流を促進でき、社内およびビジネス パートナーとの実績が向上することを示しています。IT ドメイン内で発生するビジネス アクティビティやビジネス例外の管理では、この促進された交流を効率的かつタイムリーに使用することが重要となります。

ビジネスと IT の融合による迅速なオペレーションの達成については、「Microsoft Architecture Resource Center」でアーキテクチャ クロニクル「動的モデリング: ビジネスと IT の連携」を参照してください。

このドキュメントでは、Northern Electronics シナリオを利用したこのシリーズの中の他のドキュメントについても言及しています。これらの他のドキュメントでは、シナリオを使用して、動的モデリングによってビジネスと IT を融合する方法をさまざまな観点から詳細に説明しています。

シナリオの背景

Northern Electronics は、ワシントン州エバレットに本社を置く電子機器メーカーであり、中国の南京に一部出資の製造子会社があります。

会社は、動きの速いグローバルな競合会社と対抗して、ますます厳しくなる市場で活動し、顧客からは幅広い種類の製品を効率的に納品する柔軟性を要求されています。経営陣は、バリュー チェーンの管理を迅速に実現することを可能にして、競争に対する明確な競争的優位を確立することが、会社の収益の増加にとって重大であるという結論に達しました。実際的な言い方に置き換えると、機会を発見し、それを活用して、バリュー チェーン内のビジネス アクティビティを一体化および自動化する必要があるということです。

この課題への取り組みで、経営陣は、トップダウン形式でビジネス アクティビティを再構築しないことに決定しました。このようなアプローチは既存プロセスに混乱を生じさせ、ビジネス全体に悪影響を及ぼす可能性があると判断しました。また、このアプローチは、事実上不可能であると考えました。ボトムアップ アプローチも却下されました。その主な理由は、目標を設定し、それがかなうことを期待するのは希望的観測であると判断したためです。経営陣は、結果を出す必要がありました。

代わりに、経営陣は、中間的なアプローチを策定して変更の戦略を実装することにしました。管理職のレベルで明確な目標を設定し、バリュー チェーンの効率を改善するプロジェクトの必要性、サポート、および報酬について幅広く伝えました。彼らは、この機を活用して価値あるプロジェクトを積極的に開始し、さまざまなビジネス ユニットから独立して出現するプロジェクトをサポートするようになりました。

Northern Electronics での製品の集配

Northern Electronics の受注処理部門では、注文を受けた製品を顧客に届けることを中心に集配アクティビティを調整しています。これらのアクティビティには、営業部門との発注書 (PO) の確認と検証、経理部門とのクレジットの確認、さまざまな倉庫にわたる製造部門との在庫管理の調整、顧客への製品の輸送の管理、売掛金部門の納入状況の更新などがあります。

輸送機能の製品出荷領域で、会社は問題を抱えていました。製品の出荷は、適切なコンソリデータからの輸送の注文、適切な倉庫から発送センターへの適切な数量の製品の移動、適切なトラックへの待機中の製品の積載など、重要な調整を伴います。適切な運転手がトラックを運転し、適切なコンソリデータからのエージェントとして適時に到着する必要があります。

製品出荷は、Northern Electronics の中核を成すビジネス プロセスです。ビジネスでは、問題の発生を予測して、対処のための手順が整備されています。簡単な処理や調整によって、例外の影響を最小限に抑えることが可能な場合もあります。また別のケースでは、深刻な影響を受け、罰金や取引上の損失が発生する場合もあります。倉庫の観点から見ると、時間どおりに到着しないトラック、間違ったトラックの到着、またはトラックの荷物が一杯で注文を積載できないなどの問題があります。顧客の立場からすると、製品の不着、製品の誤送 (製品または数量の間違い)、製品の配達の遅れなどの問題があります。

最新の計画と長年の経験を活用すると、ビジネス レベルでの例外処理の難しさは、どう対応するかを認識することではありません。ほとんどの問題は予測可能であり、まったく予想外の問題についても、優れた計画には何らかの対処方法が含まれています。むしろ、例外処理の難しさは、適切な時期、または前もって、発生した例外についての有益な情報を適任者に提供し、問題が発生した時点、または発生する以前に、問題に関して何らかの対策を取ることができるようにすることです。正確な情報を適切な時期に担当者に提供できれば、担当者がどのような介入を実施した場合でも、大幅な軽減効果が生じる可能性が高くなります。こういった行動をとらなかった場合、1 つの未解決の問題から、他の一連の問題が続いて発生し、やがてアクティビティの調整が中断される可能性があります。問題が発生した場所と時期を解明し、再び軌道に乗せる (可能な場合) には、多くの時間、労力、および費用がかかる可能性があります。

製品出荷を変更する

会社は、製品出荷プロセスで継続的な問題を抱えていました。トラックは、いつも時間どおりに到着するとは限りません。また、到着した場合でも、トラックの要件がいつも満たされているとは限りません。さらに、間違った貨物が発送センターに届けられることが頻繁にあります。これらの物流の問題はすべて高額なオーバーヘッド コストをもたらし、特に、時間どおりの到着を予期している顧客に対して遅れが生じます。

Northern Electronics では、製品出荷の分野での改善を決定しました。会社は、製品出荷プロセスに関する 2 つの側面に取り組むことに決めました。

製品出荷におけるビジネス パートナーとの連携の効率化

製品出荷ビジネスで例外が発生した場合の処理の効率化

まず、Northern Electronics の会社組織に注目し、製品出荷プロセスの改善に関与する担当者を調べます。

Dd297813.msarcseriesmcs01(ja-jp,MSDN.10).gif
図 1. 製品出荷に関与する Northern Electronics の社員

Barbara は、ビジネス オペレーションの部長であり、COO に報告します。彼女が実施した製品出荷プロセスの最初の調査が、改善の提案を生み出す結果となりました。COO は Barbara の提案を承認したため、彼女はチームと共にプロジェクトを進めています。Barbara は、チームのプログラム責任者である Pam に、日常作業の実行を割り当てました。IT アーキテクチャの部長の Zack は、CIO である Sara に報告します。Zack は、Barbara や Pam と共に、改善ソリューションの IT コンポーネントを実装する全体的な責任を割り当てられました。Zack は、ソフトウェア ソリューションのデザイン全般を受け持ち、Pam と共同でビジネス オペレーション要件を満たし、Jackie と実装の調整を行います。Jackie は、IT 側のプログラム責任者であり、Zack の仕事を手伝います。Jackie はプロジェクトの実装を管理し、主にソリューション アーキテクトの Tom と作業します。Sam は主要開発者、Kim はテスト リーダー、Dan はアプリケーション サポート アナリストです。

製品出荷アクティビティのモデリング

仕事に取り掛かると、Pam はまず製品出荷プロセスを把握する必要があると判断しました。彼女が考えた最善の方法は、製品集配の既存プロセスの形式的な記述をまとめて、製品出荷の何が問題であり、どこを変更する必要があるかを適切に判断することでした。ある意味では、製品出荷の方法についての形式的なモデルの作成を開始しました。

製品の出荷について

ドメインを理解するために、Pam は Northern Electronics および関連サードパーティの熟練者と会談します。彼らの役割は、次のとおりです。

  • "ビジネス アナリスト" は、何のデータを収集する必要があるか、および物理的現実を反映するためのデータの処理方法など、製品出荷に関するビジネス上の知識を提供します。**これには、商品の取り扱いと梱包の要件、サードパーティ輸送サービスの要件、および出荷スケジュールが含まれます。
  • "財務アナリスト" は、出荷予算、通関手数料、その他の税金、運送料 (関税率)、および保険料に関する財務計画を提供します。**
  • "出荷責任者" は、物流を監督し、法的な要求事項を実施します。**
  • "コンソリデータ" は、サードパーティに属し、梱包、配送方法、スケジュール、および関連書類に関する要件の情報を提供します。**
  • "法律家" は、製品出荷のベスト プラクティスや法規定など、業界の標準や規則に関するガイダンスを提供します。**

特に重要なことは、上記の担当者が必ずしも Northern Electronics の社員ではないという点です。たとえば、コンソリデータは、Northern Electronics が多くの取引をするサードパーティ会社です。製品出荷プロセスの改善は、Northern Electronics が単独で実行できるものではありません。後でこのドキュメントで詳しく説明するように、バリュー チェーン全体が関与します。

Pam は、それぞれの担当者との対話および市場や規制に関する情報を使用して、製品出荷プロセスのしくみに関する最適なモデルの開発に着手しました。

製品出荷プロセスを含む、より広範な製品集配プロセス、つまり製造現場から客先への製品の移動方法の例を見ると、Pam が発見した内容を理解するのに役立ちます。図 2 は、大規模な製品集配プロセスに関連する高度なビジネス エンティティを示します (この例のエンティティは、このドキュメント中の他の説明でも使用されます)。

Northern Electronics の製品の一部は、中国の工場で製造された後、エバレットの倉庫に発送されます。このような製品品目の 1 つに、リモコン飛行機の電子制御装置があります。Northern Electronics の顧客に、Wingtip Toys という卸売業者があり、テキサス州のダラスでリモコン飛行機を組み立てた後、飛行機を小売会社に販売しています。Northern Electronics は、オレゴン州ポートランドに本社がある貨物輸送のコンソリデータである Acme Consolidation Company に依頼して、エバレットの倉庫からダラスの卸売業者の倉庫まで電子制御装置の輸送を手配させています。

Acme Consolidation Company では、以下を含む多数の作業を行います。

  • Northern Electronics から適切な書類を収集する。
  • 運送費を提供する。
  • 運送会社に対し貨物用のスペースを予約し、貨物を目的の倉庫に配達するため運送会社と連携する。
  • 輸送中の貨物に対する保険を Northern Electronics に提供する。

この例では、Acme Consolidation Company は、地域のトラック運送会社である Blue Yonder Truckers に商品の集荷と輸送を依頼しています。

Dd297813.msarcseriesmcs02(ja-jp,MSDN.10).gif
図 2. 製品の集配に関連するエンティティの例

Wingtip Toys が Northern Electronics に注文を出すときは、Wingtip Toys の購買担当者が Northern Electronics の販売担当者に電話を掛けることを Pam は知りました。Pam は最初の電話で、次のやりとりを確認しました。

  1. Wingtip Toys の購買担当者である Frank は、Northern Electronics の販売担当者である Koji に、制御装置 1,800 台が必要であると伝えます。
  2. Koji は Frank に、コストは $17,316 (1 台あたり $9.62) に送料と取扱手数料を加えた金額であると伝えます。
  3. Frank は、申し出をすぐには受け入れません。
  4. Frank が上司に相談すると、上司は Frank に料金を安くするように伝えます。
  5. Frank は Koji に折り返し電話し、1 台あたり $5.25 までなら払えると言います。「注文数量を増加すれば可能でしょう」と Koji は答えます。
  6. Frank は同意し、注文数量を 4,000 台に増加します。
  7. Koji は上司に相談し、Wingtip Toys に 1 台あたり $6.74 で提供することを決めます。
  8. Koji が Frank に新しい価格を伝えると、「送料と取扱手数料を無料にすれば了承する」と Frank は言います。
  9. Koji と Frank は、4,000 台の制御装置の代金合計 $29,960 (送料と取扱手数料は無料) で合意しました。
  10. 次に、Koji は情報を収集し、注文が 6 ～ 8 週間で到着することを Frank に伝えます。
  11. 後で、Koji は注文情報を Frank に Fax で送信します。
  12. Koji は、発注書 (PO) の番号、卸売業社の名前と住所、製品コード、注文件数、予定日 (期間の開始)、予定日 (期間の終了)、注文状況など、発注書の詳細を書き留めます。

このような情報のやりとりから、広範囲の製品集配プロセスのうち、狭い範囲での製品出荷ビジネス プロセスは、PO を作成した時点で開始することを Pam は理解できました。"ビジネス プロセス" は、ビジネスの目標を達成するために行われる、1 つまたは複数のビジネス アクティビティで構成されます。ここでの目標は、注文を顧客に届けることです。

Pam はビジネス アナリストとの会談で、Northern Electronics は他の関係者、つまり貨物輸送コンソリデータおよび運送会社とのコラボレーションによって、製品出荷ビジネス プロセスのアクティビティを遂行していることを理解します。したがって、Pam は、自分が実際にドキュメント化しているのは、特定の種類のビジネス プロセス、つまりビジネス コラボレーションであると判断します。"ビジネス コラボレーション" は、ビジネスの目標を達成するために複数の関係者が関与する一連のアクティビティです。******実際に、高いレベルの製品の集配を彼女は実現しています。

この例のケースから、今日の製品出荷ビジネス コラボレーションは、次のように機能することを Pam は突き止めました。

  1. Northern Electronics の出荷事務員である Richard は、毎朝彼のデスクで新しい PO を取得します。彼の日常業務の 1 つは、倉庫の品目の在庫を確認することです。在庫がない場合、PO は入荷待ちになることを顧客に通知します。彼は PO を "入荷待ち" 書類に積み重ねます。
  2. 在庫がある場合、Richard は在庫割り当てを行って注文を処理します。彼は Acme Consolidation Company の貨物輸送コンソリデータの事務員である Julie に電話して、Wingtip Toys への商品の配達を手配します。Richard が電話したとき、Julie は昼休みで外出していたため、彼はボイス メールにメッセージを残し、PO を "保留中" 書類の山に積み重ねました。Julie は休憩から戻ると、Richard に折り返し電話を掛けて詳細情報を得ます。Richard のデスクには、多数の書類の山が積み重ねられているため、必要な PO が見つかるまでに数分かかります。彼はやっと PO を探し出し、要件を伝えます。Julie はその要件を検討し、商品の輸送に合意します。次に、Richard は新しい輸送注文書を書き上げ、その PO を "進行中" 書類の山に積み重ねます。彼は情報を更新し、倉庫から製品を必要な件数だけ取得し、商品の梱包を準備できるように、集荷リストを発送センターのクラークである David に渡します。梱包の準備には、品目を荷台の上に置き、ラベルを貼るなどの作業があります。
  3. Julie には、電話をする運送会社のプールがあります。彼女は、出荷品をワシントン州エバレットからテキサス州ダラスまで運搬できるトラックを手配するためにリストに目を通します。その仕事を遂行できる会社がやっと見つかりました。Blue Yonder Truckers は、翌週の火曜日の午前 10 時に到着してトラックに荷物を積み込むことができます。Blue Yonder Truckers の事務員はトラックのライセンス番号を Julie に伝え、Julie は輸送注文の詳細を運送会社に送ります。Julie は Richard に、特定のトラックの詳細が記述された輸送通知書を Fax で送信します。
  4. Richard は、貨物の集荷スケジュールを管理し、トラックが到着したときに商品をいつでも積載できるように準備します。彼は、事務所のホワイトボードにある集荷スケジュールに、新しい要件を書き込みます。
  5. 集荷予定日の朝、トラック運転手の Bob は、午前 10 時 5 分に到着したことを Richard に報告します。Richard は、注文書を引き出し、Bob の書類をチェックします。彼は到着時刻を書き留め、どの発送センターにトラックを寄せればよいかを Bob に伝えます。
  6. Bob は、トラックを適切なセンターに寄せます。David は Bob の書類を要求し、梱包済みのラベルが貼られた注文品をトラックに積載します。Bob は品目をカウントして、書類に記載された数量と同じであることを確認します。David が最終的な積荷の重量を輸送書類に書き込むと、Bob は書類にサインし、輸送中の商品に対する責任を負います。Bob がトラックを運転して去ると、David は時刻を調べて記入し、書類のコピーを Richard に渡します。
  7. Richard は書類を受け取ると、Wingtip Toys と Acme Consolidation Company に Fax を送信して、トラックの運転手が出荷品を集荷し終わったことを伝えます。次に、PO を更新し、PO と輸送注文の書類を "進行中" 書類に積み重ねます。
  8. トラックが顧客の倉庫に到着すると、顧客は Richard に、到着の確認の Fax を送信します。Richard は、PO と郵送注文を "完了" 書類の中に保管します。

出荷のすべてが発生している間に、Northern Electronics は Wingtips Toys に請求書を送り、Acme Consolidation Company は Northern Electronics に請求書を送ります。

図 3 に示すように、Pam はフローチャートを使用して、製品出荷のビジネス コラボレーションを中心にした情報の流れのモデルを作成します。

Dd297813.msarcseriesmcs03(ja-jp,MSDN.10).gif
図 3. 製品出荷ビジネス コラボレーションの情報フロー

最初の製品出荷の改善への提案の中で Barbara が指摘したように、Pam は製品出荷ビジネス コラボレーションを取り巻く多くのプロセスが、人的介入や手動プロセスに依存していることを具体的に確認することができました。電話で転送される情報、手書きで書き込まれる書類、Fax の送受信、人から人へと手渡される書類があります。Pam は、メッセージが受信されなかったり、書類が失われたりする回数はどのくらいか疑問に思いました。これは社員の時間や会社の資金を浪費し、すべての関係者に大きなストレスを生じさせます。また、会社が成長し始め、競争力を高めようとするとき、このプロセスはどの程度に評価されるでしょうか。書類の処理と電話応対のために、あと何人の社員を雇用してトレーニングを与える必要があるでしょうか。最終的な関心事は、顧客および顧客サービスへの影響です。

Pam は、製品出荷のいくつかの面は引き続き手動で行う必要があるが、プロセスの他の部分は確実に自動化できることを認識しました。Pam は Zack と共同で、自動化できる領域を特定しました。

Pam と Zack は、製品出荷ビジネス コラボレーションを構成する個別の "ビジネス サービス" を明らかにする必要があると考えました。"ビジネス サービス" は、ビジネス目標を達成するために提供されたビジネス アクションのセットです。****

製品出荷ビジネス コラボレーションのビジネス サービスを可能な限り自動化すれば、Northern Electronics とビジネス パートナーの交流、連携、およびコラボレーションを向上する手段が提供されます。ビジネス サービスの自動化は、次の点で Northern Electronics に役立ちます。

  • 営業実績の管理
  • 公認されたビジネス ルールの明記
  • 主要業績評価指標によるリアルタイムのビジネス インテリジェンスの取得
  • サービスの再利用性とスケーラビリティの確保

ビジネス サービスの自動化によって生み出される重大な改善の 1 つは、製品出荷ビジネス コラボレーションに関与するビジネス パートナーと Northern Electronics が同時に作業を進行できる点です。前述のとおり、製品出荷の主要な問題領域の 1 つは、例外のタイムリーかつ効率的な対処方法です。多くの場合、例外処理の課題は、適切な時期、または前もって、発生した例外についての有益な情報を適切な担当者に提供し、問題が発生した時点、または発生する以前に、問題に関して何らかの対策を取ることができるようにすることです。正確な情報を適切な時期に担当者に提供できれば、担当者がどのような介入を実施した場合でも、重大な軽減効果が生じる可能性が高くなります。

Pam は Richard と面談し、「製品出荷で心配なことは主にどのようなことですか」とたずねました。彼は Pam に、製品出荷プロセスの円滑な流れを実現するには、発生する必要がある重要なイベントがあることを伝えました。最も重要なものは以下のとおりです。

  • トラックは、正しい日の指定された時間帯に到着する必要があります。集荷時間は、月曜～金曜の午前 10 時～ 10 時 30 分です。トラック運転手が指定された時間内に到着しなかった場合は、翌営業日に商品を集荷する必要があります。

  • トラックは、"適切な" トラックでなければなりません。**つまり、書類で同意したとおりの正しいナンバー プレートの番号を持ち、サイズが適切で、保険に加入し、トラック輸送許可を持ち、良好な走行状態である必要があります。

  • トラックの運転手は、"適切な" トラック運送業でなければなりません。**トラックの運転手は、Northern Electronics が割り当てた出荷参照番号が記述された適切な書類を所持している必要があります。

  • 発送センターでは、トラックが到着したときに商品の準備ができている必要があります。

  • トラックは、指定された時間内に発送品を積載して出発する必要があります。

    これらの条件の 1 つ (または複数) が満たされなかった場合、プロセスに遅れが生じます。最悪のケースでは、雪だるま式の影響によって、1 件の遅れが他の出荷にも影響を及ぼす場合があります。これは、ビジネスに重大な悪影響を与えます。

    Pam は、これらの重大なイベントのいくつかを IT インフラストラクチャで管理できないかどうかを Zack に問い合わせました。Pam は、これらの条件の 1 つ以上を満たすことができなくなる前に、Richard が事前に警告を受け取ることができれば、問題になる前に状況に対する計画を立てることが可能になると判断しました。

製品出荷ビジネス コラボレーションを形式化する

Northern Electronics の製品出荷のしくみの調査によって、Pam はエキスパートになりました。彼女は、多くの組織を投入して収集した情報を整理しました。その情報の多くは、多数の異なる情報源から得たものでした。ただし、現状の全体像を実際に把握しているのは彼女だけでした。課題は、Northern Electronics (および Acme Consolidation Company) の他の多くの社員が、プロセスのしくみと改善する箇所について、一部またはすべての詳細を理解する必要があることです。Pam にとって重要なのは、情報が相互に関連し合っている状況を説明できるような方法で、情報を形式的に捕らえることです。そのために、Pam はビジネス プロセス モデリングのアプローチを使用します。

ビジネス プロセスは、ビジネスの目標を達成するために実行される、1 つまたは複数のビジネス アクティビティで構成されていることを Pam は思い出します。ビジネス プロセスのモデルを作成するには、関係者を分類し、それぞれが何を実行しているかを説明する必要があります。彼女は Northern Electronics から開始して、これを製品出荷ビジネス プロセスの関係者として特定します。"製品出荷ビジネス プロセス" は、PO が作成された時点で開始し、梱包を配送用のトラックに積載した時点で終了します。その間に、多数のビジネス アクティビティが発生します。**図 4 に示すように、Pam はこの情報のモデルをビジュアル化します。

Dd297813.msarcseriesmcs04(ja-jp,MSDN.10).gif
図 4. 製品出荷ビジネス プロセス

Pam は、図 4 のビジュアル化されたモデルは自分が表現しなければならない詳細を捕らえていないことに気付きます。前に特定したように、Pam が説明しようとしているのは、製品出荷プロセスを確実に行うための Northern Electronics とそのビジネス パートナーの共通の関心事であるアクティビティについてです。これらのアクティビティが計画どおりに実行されないと、Northern Electronics またはいずれかのビジネス パートナーが、高いコストを被るような問題を経験することになります。製品出荷を Northern Electronics だけのビジネス プロセスとしてモデリングするのではなく、関連するビジネス パートナーを含めたビジネス コラボレーションとして製品出荷モデルを作成する必要があります。

Pam は、図 5 のように、製品出荷ビジネス コラボレーション内で実行されるビジネス アクティビティを書き込みました。

Dd297813.msarcseriesmcs05(ja-jp,MSDN.10).gif
図 5. 製品出荷ビジネス コラボレーションおよび関連コラボレーション

図 5.2 に、Acme Consolidation Company との製品出荷ビジネス コラボレーションを示します。Pam は、彼女が求めているエンドツーエンドの例の一部として、Northern Electronics には、最初に製品を注文する Wingtip Toys とのビジネス コラボレーションも存在することを認識しています (図 5 を参照)。また、Pam は、ビジネス パートナーとの作業を通じて、Acme Consolidation Company には貨物運送会社である Blue Yonder Truckers とのビジネス コラボレーションが存在することも認識しています (図 5.4 を参照)。このビジネス コラボレーションの一部のビジネス アクティビティは、製品出荷ビジネス コラボレーションと並行して実行されますが、Pam は Blue Yonder Truckers を Acme Consolidation Company のエージェントとして処理するため、その点を考慮する必要はありません。

製品の出荷という目的のために、Pam は製品出荷ビジネス コラボレーションだけを考慮に入れ、この例では、Northern Electronics と Acme Consolidation Company が関与しているビジネス コラボレーションだけを取り上げています。

Pam はエンティティ全体を把握できたので、今度はシナリオ中の以下の関係者とその責任を明確にすることによって、ビジネス コラボレーションをもっとよく理解したいと考えました。

  • "サプライヤの出荷事務員" は、新しい PO を受け取り、倉庫に在庫があるかどうかを確認します。**この事務員は、商品を卸売業者に届けるために必要な輸送を注文することに対して責任を負います。輸送通知の詳細を調べて、要件が満たされているかどうかを確認し、必要に応じて修正処置をとる責任があります。製品の梱包を手配し、いつでも商品を発送できるように発送センターの準備をする責任を負います。事務員は集荷スケジュール アプリケーションを使用して、関連する輸送通知を持つ PO を決定します。発送センターでは、商品が先入れ先出しの順番で保管されます。
  • "貨物輸送コンソリデータの事務員" は、サプライヤからの輸送要求を処理することに対して責任を負います。**事務員は、契約運送会社を調べて、サプライヤ クライアントに対して使用できる運送会社を見つけます。運送会社が特定できると、事務員は輸送通知書に記入してサプライヤに送ります。
  • "トラック運転手" は、サプライヤからの商品の集荷に対して責任を負います。**集荷の当日、トラック運転手は指定された時刻に到着して手続きを行います。積載が完了すると、トラック運転手は集荷完了フォームにサインし、輸送中の商品に対する責任を負います。
  • "サプライヤの発送センターの事務員" は、集荷の詳細が記述された最終的な輸送書類を準備します。**積載が完了すると、事務員は書類を貨物輸送コンソリデータに送って商品の集荷の確認を行います。

図 6 に示すように、Pam はアクティビティ図を使用して、製品出荷ビジネス コラボレーションのビジネス アクティビティをドキュメント化します。

Dd297813.msarcseriesmcs06(ja-jp,MSDN.10).gif
図 6. 製品出荷ビジネス コラボレーション アクティビティ図

一部のビジネス アクティビティは、Northern Electronics だけに関連のある社内アクティビティです。ただし、他のビジネス アクティビティは、Northern Electronics と Acme Consolidation Company のコラボレーションの成功に依存します。

製品出荷のビジネス オペレーション要件

ビジネス環境での製品出荷のしくみを確実に理解した Pam は、今度は、IT 組織がソリューションをデザイン、実装、および運用するために使用できる形式に情報を変換する必要があります。特に、Pam は、製品出荷ビジネス コラボレーションの実行時に発生するビジネス例外を検出および修正できるような方法で、IT ソリューションが設定および運用されるようにしたいと考えました。

Pam は、収集した情報を使用して、ビジネス アナリストである Mark と共同で、ビジネス オペレーション モデリング ツールに情報を入力します。彼らが使用する特定の種類のツールは、ワークシートのセットを利用して、ビジネス コラボレーションに関する情報を取得します。納税申告用紙の背後に複雑な税法が存在するのと同様に、これらのワークシートの背後には、ビジネス コラボレーションで発生する事象に対応した定義済みの、相互関係のある、形式的な情報構造が存在します。Pam のビジネス コラボレーションは非常に一般的であるため、ワークシート モデリング ツールの使用は、彼女が収集した情報を整理するのに便利かつ十分な方法となります。

彼らが使用するビジネス オペレーション モデリング ツールには、情報が入力された後、その情報を IT で使いやすい形式に変換する機能があります。このツールは、ビジネス コラボレーションの構想を中心にデザインされているため、ビジネス アナリストにとって明らかでないデータのつながりを選択および関連付ける機能があります。また、これらの関係の構造を、IT アーキテクト、プログラマ、およびオペレータが操作しやすい他の構造に変換する機能もあります。

具体的には、Pam はこのようなツールを使用して次のことを実行できます。

  • 形式的なビジネス コラボレーション定義を電子的な形式で取得できます。
  • ビジネス コラボレーションの関係者の間で交換されたビジネス ドキュメントおよびそれらの交換のセマンティクスを含めて、ビジネス コラボレーション全体を説明するビジネス オペレーション仕様を取得できます。IT スタッフはこの仕様を、デザインおよび実装の両方で有効に使用できます。
  • ビジネス コラボレーションで管理する重大なビジネス例外、および可能な修正処置を説明するビジネス オペレーション仕様を取得できます。IT スタッフはこの仕様を、デザイン、実装、および運用で有効に使用できます。

図 7 に、Pam が使用するツールのユーザー インターフェイスの例を示します。

Dd297813.msarcseriesmcs07(ja-jp,MSDN.10).gif
図 7. 製品出荷についての情報を取得するビジネス コラボレーション モデリング ツール

Pam はこの仕様を使って、IT 組織の Zack と彼のチームの他のメンバに対して、IT 組織で行う作業に合致した方法で要件を伝えることができます。

特に、管理要件を指定するビジネス オペレーション仕様によって、Zack とそのチームは、システムをデザインするとき、ビジネス オペレーション要件をサポートするためにどの管理機能を設定する必要があるかを理解しやすくなります。システム インフラストラクチャは、適切なビジネス アクティビティを管理またはログできるように設定および構成する必要があります。ビジネス オペレーション仕様は、"ビジネス オペレーション状態モデル" の作成に使用できるような方法で要件を IT に提示します。ビジネス オペレーション状態モデルは、ビジネス コラボレーションで管理可能な条件の検出、検証、診断、解決、および再検証アクションの仕様です。当然、ビジネス例外は必ずしも予測可能ではなく、管理可能な条件は必ずしもビジネス例外ではありません。ただし、ビジネス コラボレーションに悪影響を及ぼす既知のビジネス例外は、Pam が収集した情報に含まれています。また、その情報には、証拠レコードの出力のために発生する特定のアクティビティのログなど、他の管理可能な条件に対する要件も含まれます。ビジネス オペレーション仕様は、これらの管理可能な条件を形式的なビジネス コラボレーション モデルから引き出し、Zack とその他の IT 組織のユーザーが操作できるような方法で提示します。

たとえば、Northern Electronics で細心の注意を払う必要がある製品出荷ビジネス コラボレーションの管理可能な条件の例は、トラックの定刻どおりの到着に関連があります。ビジネス オペレーション仕様は、次のように、この要件を形式的に呼び出します。

  • ビジネス オペレーション要件 (BOR): トラックは、指定された SuggestedPickupTime かそれ以前に、サプライヤの倉庫で商品を集荷するために到着します。

    以下の 2 つの表は、このビジネス オペレーション要件についての詳細を示します。

    表 1. ビジネス オペレーション状態モデル (情報の検出)

    問題 状態およびオペレーションの条件 インジケータ オペレーションに関する警告 重大度
    BOR 違反 低下、整合性の問題 Event (ID = EVENT_TRUCK_ARRIVAL_DELAYED)

    このイベントは、イベント ログに記録されます。

    		 電子メール通知が Business Operations Managers 通知グループに送信されます。 イベント処理ルールによって、重大度が [Severe] に設定された警告が生成されます。

    表 2. ビジネス オペレーション状態モデル (情報の検証、診断、解決、および再検証)

    問題 検証手順 診断情報 解決および最終的な望ましい状態 再検証
    BOR 違反 手動によるチェックで、トラックが到着していないことを確認します (TRUE を返す)。オペレーションの条件は、整合性の問題として確定されます。 手動によるチェック。貨物輸送コンソリデータに電話をしてトラックがどこにいるかを確認します。 手動による解決。サプライヤは、コンソリデータとトラックの到着時刻を再交渉し、システムに保存された時刻を更新します。サプライヤは、SuggestedPickupTime を更新します。ログおよびデータベースが最新情報に更新されます。 手動によるチェックで、トラックが到着していないことを確認します (FALSE を返す)。

表 1 は条件の検出方法を示し (このケースでは、ビジネス例外)、表 2 は検出後の対処方法を示します。このケースでは、IT ドメインからの最終的な解決は、ビジネス オペレーション マネージャにフィードバックを提供するだけです。システムの状態を変更するための IT 管理システムによる制御アクションは不要です。

ビジネス オペレーション モデリングによる IT へのビジネス オペレーション要件の伝達の詳細については、「Microsoft Architecture Resource Center」でアーキテクチャ クロニクル「動的モデリング: ビジネスと IT の連携」を参照してください。

製品出荷ソリューションを構築する

仕様でのビジネス オペレーション要件の詳細な記述、および Zack とビジネス オペレーション チーム間の通信手段の向上によって、Zack は IT ソリューションのデザイン、実装、およびロールアウトに向けてチームと共に取り組むことが可能になりました。

Zack のチームは、Pam とは別々に作業します。ビジネス部門にプログラム責任者が存在するように、IT 側にも Zack の指揮下で作業するプログラム責任者が存在します。彼女の名前は Jackie です。

今度の作業は、製品出荷ビジネス コラボレーションをサポートする IT ドメインのインフラストラクチャをデザイン、実装、および構築することです。Jackie は、ビジネス オペレーション仕様に含まれている要件を出発点として、それらの要件を満たすプランの作成を開始します。プロジェクトの全期間にわたって、彼女はプロジェクトの状態を監視し、以下に示すスキルやタスクを持つ個人と作業を行います。

  • Tom: "ソリューション アーキテクト" です。専門知識を提供し、実際のソリューション デザインを推進します。**Tom は、さまざまなビジネス システムが連携して動作していることを理解しています。彼は、テクノロジの機能とその制限事項について理解しています。彼はビジネス システム アナリストと連絡を取って、サポートおよび構築する必要があるビジネス機能、および期待されるビジネス ユーザー エクスペリエンスを把握します。彼は、ソフトウェア開発者に対してアプリケーション デザインを作成および伝達し、プロジェクトのタスクを割り当てます。また、ソフトウェアの開発方法やツールの決定に対しても責任を負います。
  • Sam: "主要開発者" です。機能要件および非機能的な要件を満たすソフトウェアを開発します。**Sam は、単体テストの作成および実行、コード分析の実行、読み込みテストの作成、および動作の確認を行います。バグが報告された場合、Sam はバグを診断および修正し、動作の確認を行います。
  • Kim: "テスト リーダー" です。アプリケーションのテスト ケースを生成します。**彼女は、構築の状態を確認し、テストを読み込んで実行し、バグを報告します。
  • Dan: "アプリケーション管理者" です。サーバーおよびネットワーク インフラストラクチャの機能と制約を理解しています。**Dan はソリューション アーキテクトと共同で作業して、アプリケーション デザインを理解し、必要なオペレーション要件をアプリケーションのデザインおよび開発に取り込みます。Dan はオペレーション ツールを使用して、監視用の管理スクリプトおよび自動化されたタスクにオペレーション要件を盛り込みます。彼は、適切なコンピュータにアプリケーションを展開します。また、高度なオペレーション エラーのトラブルシューティングを行い、修正します。
  • Craig: "アプリケーション サポート アナリスト" です。サービスのパフォーマンスと状態を監視します。**彼は、基本的なオペレーション エラーのトラブルシューティングを行い、修正します。

Zack のチームでは、図 8 に示すサービス ライフ サイクル アプローチを使用して連携し、ビジネス オペレーション要件を満たします。

Dd297813.msarcseriesmcs2f08(ja-jp,MSDN.10).gif
図 8. サービス ライフ サイクルの使用

サービス ライフ サイクル アプローチは、以下の点でチームに役立ちます。

  • 非機能的な属性について検討して、長期にわたるサービスの運用、維持、およびアップグレードを可能にします。
  • サービス ライフ サイクルに含まれるロールを識別し、各ロールが実行する管理タスクを明らかにします。
  • 管理モデルのコレクションを使用して、管理タスクの概念的な要素や制約について説明します。
  • 製品やテクノロジを使用して、管理モデルのソリューションを構築します。結果として生じたツールおよびアプリケーションは、組織の個々のロールのニーズに合わせてカスタマイズされます。

動的モデリング、サービス ライフ サイクル アプローチ、および IT システムの管理を使用したビジネスと IT の連携の問題の詳細については、「Microsoft Architecture Resource Center」でアーキテクチャ クロニクル「動的モデリング: ビジネスと IT の連携」を参照してください。

デザイン フェーズ

Tom のアーキテクトとしての主な仕事は、ソリューションのデザインです。彼は、次の点を考慮してソリューションをデザインします。

  • Pam と Zack が仕様で提供したビジネス オペレーション要件
  • 長期にわたるサービスの運用、維持、およびアップグレードを可能にする非機能的な属性

Tom は、Pam と Zack から与えられたビジネス オペレーション仕様および IT 組織のポリシーを分析して、ソリューションのデザインを作成します。彼は、Web サービス ソリューション デザインと Web サービス状態モデルの 2 つのデザイン領域に焦点を当てます。

Tom はデザインを開発するとき、多くの問題を考慮します。

  • サービス メタデータ:
    • サービスの構成 (システムとネットワーク パラメータ)
    • メッセージ セキュリティ ポリシーとビジネス ルール
  • ID と権限
  • サービス構成
  • ディレクトリ サービスのロール:
    • セキュリティ データの管理 (資格情報と権限)
    • サービス構成とポリシーの管理
  • インフラストラクチャとの整合性
  • オペレーション プロセス

Tom は、高度に構造化された情報モデルを使用するモデル駆動型の開発アプローチに従って、Pam や Zack などの関係者の意図および希望する結果を取得します。特にビジネス オペレーション要件については、このアプローチを使用すると、期待された結果を得るために必要なインストルメンテーションおよびタスクについて Tom は事前に考慮できます。また、彼はビジネス例外が発生した場合の対応策についても考えます。

Web サービス ソリューションのデザイン: ビジネス サービスから Web サービスへ

Tom のデザイン アプローチは、Web サービスに依存して、製品出荷ビジネス コラボレーション内の自動化できるビジネス サービスを実装することです。Tom は、一部の Web サービスは Northern Electronics の社内で使用され、その他はビジネス パートナーによって直接使用されるだろうと予想しています。

Tom は、Pam と Zack と連携して、製品出荷ビジネス コラボレーションの候補となる Web サービスを見つけます。彼らは現在の出荷方法を確認し、自動化によって何を改善できるかを考えました。Pam と Zack は、製品出荷に関連のあるビジネス サービスに注目した時点で、ビジネスの観点からこの問題を既に検討済みでした。ビジネス オペレーション仕様は、この分析の詳細を形式的な方法で捕らえますが、Tom は Pam と Zack にアドバイスを求めて、何が起きているのか、およびなぜ仕様にこのような要件があるのかを十分に理解する必要があります。

彼らが合同で検討する事項の 1 つには、たとえば、どの時点で製品出荷ビジネス コラボレーションが開始するかということがあります。通常、Northern Electronics の顧客との交渉は、電話を通じて口頭で行われます。これは製品出荷ビジネス コラボレーションの範囲外にあります。また、仕入れの交渉には人的交流が必要になる可能性があるため、交渉は自動化の候補として最適ではありません。PO を作成するときが、製品出荷ビジネス コラボレーションの開始点となります。PO は、紙ではなく、電子的に保存可能なアーティファクトです。

別の例として、輸送の注文も彼らが合同で検討する事項の 1 つです。PO を作成した後、サプライヤの出荷事務員は、在庫があるかどうかを確認します。在庫がある場合、サプライヤの出荷事務員は貨物輸送コンソリデータの事務員と連携して、出荷品を集荷して顧客に配達するための運送を手配します。

もう一つ例を挙げると、セキュリティ要件も彼らが合同で検討します。Web サービス ドメイン内では、ビジネス コラボレーションの関係者の ID をデジタル ID で表す必要があります。サービスのアクセス、使用、および管理を制御するための認証および承認のプロセスが必要です。これは特に、管理の境界を越える場合に必要です (この例では、サプライヤと貨物輸送コンソリデータ間)。Tom は、輸送の注文情報を作成または変更する権限を与えられているのはだれか、輸送の承諾を確認できるのはだれかといった事項を、確実に知っている必要があります。これらの事項は、厳密な法規定を示すビジネス オペレーション要件を満たす場合に、特に重要となります。ビジネス オペレーション要件では、たとえば、貨物輸送コンソリデータに実際に輸送注文を出す (結果的に、その会社に注文の輸送に対する支払いを委ねる) ことができるのは、Northern Electronics のだれの役割であるかを指定します。特定のロールによって実行される具体的なアクティビティのログなど、セキュリティや ID に関連するその他の要件は、ビジネス オペレーション仕様で表現されます。

Pam と Zack は、サプライヤと貨物輸送コンソリデータ間の対話が Web サービスを使用して自動化および実装するための最適な候補であるという結論に達し、Tom もそれに同意しました。それには、次のような根拠があります。

貨物輸送コンソリデータの Web サービスがあれば、サプライヤの出荷事務員は電話ではなく Web サービスを使用して要求を送信でき、要求に関して混乱が生じることはほとんどなくなります。また、サプライヤの出荷事務員は、要求が受信されたことを確認できます。貨物輸送コンソリデータの事務員は、要求を処理し、要求を承諾することができます。

同様に、サプライヤの Web サービスがあれば、貨物輸送コンソリデータは Fax ではなく Web サービスを使用して輸送注文の承諾を送信でき、要求に関して混乱が生じる可能性は低くなります。承諾に、製品の集荷についての詳細や条件を含めることもできます。貨物輸送コンソリデータの事務員は、承諾の受信および条件への合意を確認できます。

Tom は、ビジネス コラボレーションについて詳しく調査した後、サプライヤの出荷事務員と発送センターの事務員が社内 Web サービスを使用して、トラック運転手の予想到着時刻に合わせて出荷品を適切な順序で荷積み台に準備できれば、作業の効率が高まるだろうと判断しました。この社内 Web サービスを使用して、トラック運転手の資格情報を記録でき、貨物の集荷も確認できます。また、社内 Web サービスを使用して、集荷の確認を Acme Consolidation Company の Web サービスに自動的に送信できます。

この分析に基づいて、ビジネス オペレーション仕様に示された要件を満たし、彼が発見した社内の効率化を作成するため、Tom は製品出荷ビジネス コラボレーションの促進に向けて 3 つの Web サービスを含むデザインを提案します。

  • ShippingService Web サービス: サプライヤの Web サービスです。貨物の集荷に関する詳細を送受信するために使用します。

  • PickupService Web サービス: サプライヤの社内用の Web サービスです。製品の集荷について通知を受け取り、集荷の確認を行います。

  • TransportService Web サービス: 貨物輸送コンソリデータの Web サービスです。サプライヤはこの Web サービスを使用して、最初の輸送の注文を行い、最終的な貨物の集荷確認を行います。

  • 当然ですが、TransportService Web サービスは貨物輸送コンソリデータの所有物であるため、Northern Electronics が実装できるものではありません。ただし、Tom のデザインの一部として必要となります。

  • Tom は Zack と Pam の協力を得て、TransportService Web サービスの開発について、選択された貨物輸送コンソリデータ ビジネス パートナーの Acme Consolidation Company と調整を行います。このアプローチが成功すれば、Pam と彼女のチームは、他の貨物輸送コンソリデーション ビジネス パートナーとも同様の連携を計画できます。

    注: このドキュメントでは、Acme Consolidation Company との調整の詳細を省略し、単純に調整が成功したものと見なします。

  • Tom は、ビジネス オペレーション仕様を使って、Web サービスの実際のインターフェイスを定義します。

  • Web サービス ソリューションの設計の詳細については、「Microsoft Architecture Resource Center」でアーキテクチャ クロニクル「動的モデリング: ビジネスと IT の連携」を参照してください。

Web サービス状態モデル: オペレーションのデザイン

提案された 3 つの Web サービスを使用すると、メッセージを体系的かつ検証可能な方法で送受信できます。Tom は、ビジネス オペレーションのインターフェイス要件を満たすことに加えて、サービス インストルメンテーションを使用して Web サービスの実行中のインスタンスをビジュアル化および制御する方法も考える必要があります。Web サービス インストルメンテーションは、次のような形式をとることができます。

  • デバッグ トレースは、コードの実行動作の診断に役立ちます。
  • イベントを使用して、特定の管理条件に一致することを警告します。
  • パフォーマンス カウンタを使用して、サービスの状態を反映した統計情報を生成します。
  • プローブは、管理アプリケーションでクエリおよび制御できる内部サービス状態です。

Tom は、Northern Electronics が実装する 2 つの Web サービスをオペレーション向けにデザイン可能であることを確認する必要があります。つまり、さまざまなレベルのパフォーマンスの目標が達成されるように Web サービスをデザインする必要があります。

IT 組織は、状態モデリング アプローチを使用して、Web サービスをどのように実行するか、実行方法についてどのように学習するか、および計画に従って実行していない場合にどのような対策をとるかについて理解を深めます。

状態モデリングは、正常なシステムとは何か、および正常でないシステムとは何かについて、システム デザイナの理解を形式的にドキュメント化するためのサービス ライフ サイクルのデザイン フェーズ内のプロセスです。デザイナが予想できるすべての管理可能な条件を事前に検討します。結果として生じた状態モデルには、識別方法や対処方法など、予想される管理可能な条件ごとの詳細な検討事項が含まれます。状態モデルには、次の方法の詳細が含まれます。

  • 管理可能な条件を検出する。
  • それが本当の条件であるかどうかを検証する。
  • 必要に応じて、条件の原因を診断する。
  • 必要に応じて、修正処置によって条件を解決する。
  • 条件を再検証して、システムが良好な状況にあるかどうかを確認する。

Tom は、IT 組織内の他のメンバと連携し、既存のポリシーやプロシージャに依存して、彼が提案した 2 つの Web サービスの最初の状態モデルを形成します。この最初の計画では、Web サービス向けの会社の標準のシステム レベルおよびアプリケーション レベルの状態モデルを考慮に入れます (たとえば、Web サービスが実行中であることを確認する方法として "ハートビート" チェックを実行する必要がある)。Tom は、ビジネス オペレーション仕様の要件も考慮する必要があります。

Web サービス状態モデリングの詳細については、「Microsoft Architecture Resource Center」でアーキテクチャ クロニクル「動的モデリング: ビジネスと IT の連携」を参照してください。

開発フェーズとテスト フェーズ

Tom はデザインが完了すると、それを Pam と Zack と共に再検討して、要件が満たされているかどうかを確認します。次に、Jackie と共同で、主要開発者である Sam と彼のチームにデザインを渡す準備をします。

Sam の仕事の 1 つは、ソリューション デザインをシステムの詳細な仕様を開発するためのベースとして使用することです。仕様では、IT 組織の開発ポリシー、既存インフラストラクチャ、既存コンポーネントなど、他の多数の要素が考慮されます。Sam は、多数の事項を考慮に入れて仕様を開発する必要があります。以下を含みます。

  • アプリケーションをテスト可能にする方法
  • アプリケーションを展開可能および構成可能にする方法
  • バージョン管理の取り扱い方法
  • セキュリティの処理方法
  • 使用されていない要素の処理方法

Sam のもう 1 つの仕事は、状態モデルをソリューションのインストルメンテーションのための詳細な計画として使用して、ソリューションを管理できるようにすることです。インストルメンテーションは、Web サービスの実行中のインスタンスをビジュアル化および制御するために使用されます。インストルメンテーションは、次のような形式をとることができます。

  • デバッグ トレースは、コードの実行動作の診断に役立ちます。
  • イベントを使用して、特定の管理条件に一致することを警告します。
  • パフォーマンス カウンタを使用して、サービスの状態を反映した統計情報を生成します。
  • プローブは、管理アプリケーションでクエリおよび制御できる内部サービス状態です。
  • これらの仕様に基づいて、Sam のチームはソリューションのソフトウェアをプログラムします。Sam は Jackie と共同で、コードの確認のためのスケジュールやテストでの Kim への引き継ぎの日付を考えます。

Kim はチームと共同で、管理機関へのアプリケーションの準拠を確認するためのテストをデザインします。彼女はテスト ハーネスをデザインして、機能、パフォーマンス、ストレス、セキュリティ貫通テストなど、アプリケーションに対してさまざまな種類のテストを実行します。Kim が判定する必要がある主な事項は次のとおりです。

  • 単体テスト
  • データセンターへの展開可能性
  • 状態モデルへの準拠
  • 管理可能性

運用前のテスト環境は、Web サービスのデザイン前提を検証するため、実際の状況をシミュレートします。Kim は Jackie と Sam と共同で、テストの合格およびバグの優先順位についてスケジュールを立てます。

  • Web サービス ソリューションの設計の詳細については、「Microsoft Architecture Resource Center」でアーキテクチャ クロニクル「動的モデリング: ビジネスと IT の連携」を参照してください。

展開フェーズ

すべてのテスト要件を満たしたら、新しい Web サービスをいつでも運用環境に展開できます。Dan は、ネットワーク インフラストラクチャ、ハードウェア、およびオペレーション システムの準備を開始します。彼は、アプリケーションを運用環境に展開します。Dan が判定する必要がある主な事項は次のとおりです。

  • プロビジョニング
  • バージョン管理
  • 検出
  • 更新ロールアウトのウィンドウ化
  • クラスタ管理
  • インフラストラクチャの変更管理との統合
  • Web サービスの展開の詳細については、「Microsoft Architecture Resource Center」でアーキテクチャ クロニクル「動的モデリング: ビジネスと IT の連携」を参照してください。

運用フェーズ

アプリケーションを展開したら、Jackie の作業はほとんど完了します。Craig と彼のチームが引き継ぎ、アプリケーションを監視してオペレーション上の問題がないかどうかを判断します。このフェーズの目標は、状態モデルに基づいて正常なシステムを維持することです。Craig が注目する必要がある主な事項は次のとおりです。

  • 状態、パフォーマンス、およびサービスへの準拠の監視
  • 原因分析
  • メータリング
  • サービスの制御および構成
  • Web サービス状態モデリングの詳細については、「Microsoft Architecture Resource Center」でアーキテクチャ クロニクル「動的モデリング: ビジネスと IT の連携」を参照してください。

変更管理フェーズ

変更管理フェーズでは、Craig、Sam、および Tom が、リアルタイムと後処理を含むサービスのオペレーション データに注目します。このフェーズには、デザインの変更または実装の変更を決定するための意思決定プロセスが含まれます。オペレーション スタッフ、開発者、およびアーキテクトが注目する必要がある主な事項は次のとおりです。

  • 状態モデルのメトリックス
  • 使用されなくなった要素
  • スケーリングのためのインフラストラクチャの調整

長い間に、新しいビジネス オペレーション要件や技術的要件によって、既存の製品出荷ビジネス コラボレーションおよびそれを支持する IT システムは、実装を再評価して、可能な変更を加えることが必要になります。これらの変更が発生すると、Northern Electronics は、ビジネス コラボレーション内の既存の関係者および Web サービスのコンシューマに対する変更の影響を最小化または防止するための課題に直面します。

たとえば、Northern Electronics の製品出荷ビジネス コラボレーションの範囲が、国内のトラック運送だけではなく、海外へも出荷する貨物輸送コンソリデータ パートナーに拡張された場合、形式的なビジネス コラボレーション モデルを調整して、たとえば、国際的な関税規則を考慮に入れる必要があります。これらの新しい要件をサポートするには、サプライヤと貨物輸送コンソリデータ間で追加の入出力データの転送が必要になる場合があります。ビジネス オペレーション要件の変更は、ビジネス オペレーション仕様の改訂によって、明確かつ効率的に IT 組織に伝達できます。

Web サービスを使用してビジネス コラボレーションの一部が有効となっているため、これらの新しいデータ交換を促進するために、いくつかの技術的なオプションを検討することがあります。Northern Electronics では、新しい Web サービス インターフェイスを導入して新しいデータ パラメータをサポートできます。または、Web サービス プロキシを使用して既存インターフェイスをサポートし、プロキシでデータ変換および内部サービス ルーティングを実行して、現在および新しいサービス コンシューマからのメッセージング要求をサポートする場合もあります。Web サービス ソリューションのデザインに応じて、Web サービス インターフェイスまたはメッセージ スキーマへの変更が、Web サービス コンシューマおよび Web サービス プロキシに影響を与えることがあります。どちらの場合でも、コンシューマは、新しい Web サービス定義を発見して新しい Web サービス エンドポイントと対話する必要があります。

製品出荷ビジネス コラボレーションを支持する Web サービスに必要な変更は、必ずしもビジネス オペレーションの変更によって生じるものとは限りません。このような変更には、Web サービスのアクセス アドレスのわずかな変更や、役に立たないか、間違っていることが判明した既存メッセージ スキーマへの大幅な変更などがあります。IT 組織は、単独でこれらを変更できますが、ビジネス オペレーション スタッフと変更について調整を行って、ビジネス オペレーションへの影響を検討し、変更を実施する時間帯に関するフィードバックを提供する必要があります。

まとめ

このドキュメントは、Northern Electronics がビジネス パートナーと連携して製品出荷プロセスを改善するというストーリーに従って展開しました。この中で、IT 組織でのビジネス オペレーション要件のサポートについて説明しました。アーキテクチャ クロニクル「動的モデリング: ビジネスと IT の連携」の他のドキュメントでは、Northern Electronics シナリオを使用して、接続されたシステムを管理する方法をさまざまな観点から詳細に説明しています。