Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

アーキテクチャ主導の情報システムへ

2.942 Aufrufe

Veröffentlicht am

オープンコミュニティ「要求開発アライアンス」(http://www.openthology.org)の2013年10月定例会発表資料です。 Open Community "Requirement Development Alliance" 2013/10 regular meeting of the presentation materials.

  • Als Erste(r) kommentieren

アーキテクチャ主導の情報システムへ

  1. 1. アーキテクチャ主導の 企業情報システムへ 2013.10.22 要求開発アライアンス 今後の企業情報システムは、より俊敏にビジネスのROIへの貢献が求 められる。一方で、肥大化、複雑化したシステムはメインテナンス上の 多くの課題を抱えている。このような背景で、進化し続けるIT-SEEDS の積極的な導入と、安定的なシステム運用を両立する為には、ITアー キテクチャ主導のシステム化に切り替えていく必要がある。 株)アイ・ティ・イノベーション ビジネス・テクノロジー戦略部 中山 嘉之 1
  2. 2. ITアーキテクトとは? 2
  3. 3. ITアーキテクトの定義 ・ ITアーキテクトとは・・・ 「組織の情報戦略に基づき、ITシステム全体のアーキテクチャを 設計する人。さまざまな技術・製品から、ビジネス上の要求を満た す最適な組み合わせを選び出すことが求められる。これにはビジ ネスと情報技術の両方の広範な知識が必要となる。」 アーキテクチャ設計:日本国内において、システム開発工程の業務要件 定義の後、“どのようなITを活用して、どのような構造で構築するかを決め る”方式設計”がこれに近いが、システム化企画、構想段階から必要となる 意味でより広範囲である。  業種は異なるが、製図や模型を用いてデザインする“建築士”が最も近い。 ※近年、プログラムの構造に代表される一部の下流工程の設計に限定したアーキテ クチャを言うケースがあるようだが、柱や壁や屋根の専門技師は建築士とは呼ば ない。 3
  4. 4. ITアーキテクチャ設計とは? ・ビジネスのROI向上のため企業にとって最適なITアーキテクチャを設計する Business ビジネスの 特性分析 Business ITの課題 Analyze Describe IT-Architect ToBe AsIs MODEL(Blue-Print) System MODEL MODEL Migration Plan 4
  5. 5. ITアーキテクチャ 不在の結末 5
  6. 6. ITアーキテクチャ不在の典型例 手組みシステムの増改築で Spaghetti化、無政府状態 システムc MST b MST SYSTEMa ERP、パッケージ、手組みの 乱造によるSilo化、膠着状態 MST TR TR TR パッケージ プロセスA1 プロセスB2 i/f TR TR TR i/f TR i/f プロセスA2 プロセスC1 プロセスB3 TR システムa TR プロセスC2 TR TR TR システムc システムb ERP パッケージ MST MST MST i/f プロセスA3 TR プロセスB4 i/f プロセスC3 パッケージ TR TR TR MST MST 6
  7. 7. EA(Enterprise Architecture)の成熟度 ・あなたの会社はどのレベル? B.競争力あり C.悪戦苦闘 D.創世記 ・まだビジネス のIT依存度合い が低い ・ITコストのコンロー ルが不能 ・IT部門は巨大なコ ストセンター ・しばしばプロジェク トが炎上する ・ITコストはコントロー ル下にある ・ITがビジネス活動を 支えている ・ITの青写真が存在す る ・ITガバナンスができ ている A.成熟状態 ・ビジネスとITが融合 している ・ITアーキテクチャフ レームワークがある ・ITアーキテクチャ組 織が存在する ・ITがビジネスに価値 をもたらす(プロフィット センター化) ⇒少なくともBランク以上にはなりたいもの! 7
  8. 8. EA(エンタープライ ズ・アーキテクチャ) 8
  9. 9. EA(エンタープライズアーキテクチャ)と普遍性 • 普遍性(抽象的、概念的、本質重視) BA DA AA TA メインフレーム “お金で調達”はできない お金で“調達”は難しい (汎化すれば可) ”調達”が可能 領域拡大中 オープン BA DA Business Archi. Data Archi. AA Application Archi. TA Technical Archi. Web クラウド • 特殊性(物理的、視覚的、外見・操作性重視) ⇒ITアーキテクチャの特徴は、表層部(TA)の移り変わりの早さにあり、ま た、そこにパラダイムチェンジをもたらすパワーがある点 9
  10. 10. EAとITアーキテクチャの関係 • 普遍的なものを中核に据える必然性 ⇒周辺は壊れても中心(柱)は保全 • 変化の多いものを中核に据えると ⇒周りも影響を受け全体が壊れる BA TA AA BA DA DA AA TA(ベンダー)中心モデルは ユーザ企業では成立しない TA ビジネス(ユーザ企業)中心モデル ⇒ITアーキテクチャを考える際に、変わらないものは頑丈(Rigid)に設計し、 周辺は柔軟(Flexible)な構造にしておく。その順序は、ライフサイクルの長 さに対応し、BA>DA>AA>TAとなる。 10
  11. 11. ビジネスからアーキテ クチャへの落とし込み 11
  12. 12. 事業毎の共通コンポーネントの考慮 事業の類似性に応じ たアプリ共有 事業競争力 【事業毎のアプリマップ例】 事業A 営業 生産 販売 事業B 事業C SFA-a SFA-b SFA-c SCM-a SCM-b アプリより小さい 部品共有 【さらなる共通部品化】 SFA 共通 SCM 共通 会計 グループのガバナンス 強化を狙って統一 ガバナンス 人事 インフラ、OAアプリ ⇒可能な限り大きな部品の共有を図ることで生産性、品質の向上を図る 12
  13. 13. BA(ビジネスアーキテクチャ)の中のメリハリ ①コア業務/ノンコア業務の識別 販売 SCM SFA CRM プ ロ セ ス R&D SFA 研究 CRM 管理 PLM SCP* 債権 管理 開発・ 安全性 SCE* LIMS* 購買 戦略 購買 調達 (製薬事業の例) 会計 管理会計 制度 会計 人事 人材管理 発令・ 給与 計算 *SCP(Supply Chain Planning) *SCE( Supply Chain Execution) *LIMS(Laboratory InformationManagement System ) コア ノン コア 業務ドメイン 競争力 強化 ガバナンス 強化 ⇒実現方式(パッケージ/手組み、クラウド/オンプレミス)等の選択に活用! ②今後の経営が向う方向の確認 ガバナンス重視か/事業競争力強化か?どちらの軸か? どの事業を伸ばし/どの事業を縮退の方に向うか? ⇒アプリ開発を実行する優先順位の決定に活用! 13
  14. 14. アプリ実現方式4象限(BA⇒AA⇒TA) ③自社の業務アプリを下記のような4象限にマッピング 変更が多い(コア) カスタム・パッケージ 開発、 安全性 (バ ガッ バク ナオ ンフ スィ )ス SCE、 LIMS 調達 手組み 人材管理 PLM、 SCP SFA、CRM 戦略購買 債権 管理 研究管理 フ (ロ 競ン 争ト 力エ )ン ド 管理会計 非構造化データ 制度会計 文書管理 SNS 発令・ 給与計算 OA BI 一体成型・パッケージ 汎用ツール 変更が少ない(ノンコア) 14
  15. 15. 理想的なアーキテク チャの一例 15
  16. 16. 適材適所なアーキテクチャ ・日本古来の“アーキテクチャ:”適材適所“ ・意味: 「人の能力・特性などを正しく評価して、ふさわしい地位・仕事につけること」 ・英語: The right person in the right place. ⇒伝統的な日本家屋や寺社などの建築現場での木材の使い分けがその語源 ☆豊富な森林に囲まれた日本では針葉樹・広葉樹など実にさまざまな木材 が建築に使われてきた歴史がある。 建物を支える柱や梁などにも、実に適切 で理にかなった使い分けがなされてきた。 例えば土台には腐りにくく耐久性の高い 檜(ヒノキ)や栗(クリ)を、内装の一部にな る柱には木目の美しくやさしい肌合いの杉 (スギ)を、また屋根や二階以上の重量を 支える梁には強靭な松(マツ)をといった具 合である。 また、家具であるたんすには桐(キリ)が 最適とされるのも同様である。 - Wikipediaより 16
  17. 17. Data-Centricな疎結合アーキテクチャ ・自社のデータモデルを中核とし、適材適所なアプリを疎結合する ・プロセス中心のアーキ TA APPL.4 (EXCEL) APPL.5 (PaaS) TA Master APPL.2 (ERP) DATA1 MDM* APPL.1 AA TDM* APPL.3 (Scratch) Transaction DATA2 Enterprise Data-Hub APPL.1 (SaaS) AA DA DA DA AA APPL.6 (Scratch) TA *MDM:Master Data Management * TDM: Transaction Data Management (造語) DATA3 DA DATA4 DA AA中心:サービスベンダー のモデル DA中心:ユーザ企業のモデル 17
  18. 18. 先端的TAに対応したインフラ・アーキ ・クラウドとオンプレミスのハイブリッド環境を構築し、順次クラウドへ 各種クラウドサービス Internet 共通認証サービス 徐々にクラウドへ移行 HUB 自社DataCenter On-Premise 企業のセキュ リティポリシー シーに基づき、 予め移行の順 序を決めおく 事が良い。 自社網 自社網からインターネット網へ移行 拠点 拠点 拠点 ・クラウド移設の優先順は他システムとのI/Fの少ない順! ①インターネット共通認証サービスの加入 ②オンプレにある各種OAツール(電話含む)をクラウド化 ③業務アプリを出し易い順からクラウド化(各I/FはHUB経由が好ましい) 18
  19. 19. マイグレーションプラ ンニングの具体例 19
  20. 20. マイグレーション・プランニング(STEP1) 【状態A】手組みスパゲッティ化や、 ERP、パッケージ等のサイロ化 【状態B】共通マスタを一元管理し マスタデータガバナンスを確立 Package MST MST Enterprise-Hub ERP MST Scratch MST MST MST ERP MST MST Office-Tool MST MASTER TRANSACTION 自社のマスタモデル ⇒まずはマスターに着目しMDM環境を構築。 組織、アイテムなどの主要なマスタから1つずつ 中央のEnterprise-Hubに寄せて行く! 20
  21. 21. マイグレーション・プランニング(STEP2) 【状態B】共通マスタを一元管理し マスタデータガバナンスを確立 【状態C】共通トランザクションを一元 管理しデータガバナンスを完成 Package パッケージ Enterprise-Hub MDM Scratch MST Scratch ERP MST ERP TRN Office-Tool Office-Tool MST TRN MASTER TRANSACTION TRN汎化モデル ⇒次にTransactionに着目しTDM環境を構築。 複数アプリに跨る主要なTransactionを汎化し、 徐々に中央のEnterprise-Hubに寄せて行く! 21
  22. 22. マイグレーション・プランニング(STEP3) 【状態C】共通トランザクションを一元 管理しデータガバナンスを完成 【状態D】Data-Centricで、Platformフ リーな、Service疎結合の世界へ Package Package Cloud-Service Enterprise-Hub MST Scratc h ERP Cloud-Service TRN Enterprise-Hub Scratch MST ERP TRN Office-Tool MODEL MST TRN MASTER TRANSACTION Office-Tool Cloud-Service 自社でKEEPすべきもの ①適材適所にビジネスにマッチしたアプリケーションをマッピング。 ②ベンダーロックインから完全に解放されたアーキテクチャ。 ③Cloudをはじめ各種外部サービスを多用できるソーシングモデル。 22
  23. 23. ・企業システムの歴史は全てがマイグレーションの連続と言ってよ いでしょう。しかし、向かうべき青写真があってこそ、最初の1歩 をどこに踏み出すかが決まります。 END 23

×