戦う現場に贈る分散システム構築−開発現場編(10):
既存システムという制約とアーキテクチャ――どうつなぎ、うまく再利用するか
複数システムを統合するプロジェクトを任された若手技術者の豆成くん。机上の空論よりも検証が重要であることを認識した豆成くんだったが、その目の前には既存システムという伏魔殿がそびえていた……。(2010/4/26)
戦う現場に贈る分散システム構築−開発現場編(9):
システムアーキテクチャとSOA製品選定――分散するシステムをつなぐ製品について
中堅メーカーの複数システムを統合するプロジェクトで開発チームの主力に祭り上げられてしまった若手技術者の豆成くん。豆成くんは懸命に先行事例や関連製品の研究を始めたのだが……。(2010/1/7)
戦う現場に贈る分散システム構築−開発現場編(8):
悩ましき分散システムのアーキテクチャ――要件に合致したシステムを設計するために
中堅メーカーの複数システムを統合するプロジェクトで開発チームの主力に祭り上げられてしまった若手技術者の豆成くん。そんな豆成くんに先輩の蔵田は“アーキテクチャ”を決めろというのだが……。(2009/9/28)
戦う現場に贈る分散システム構築−開発現場編(7):
これから始めるサービス指向型設計――単独システムとは違う世界へようこそ
中堅メーカーで、複数システムを統合する大役に悪戦苦闘を続けてきた豆成くん。そんな豆成くんは自分が発注する作業を、自分で実行する羽目になろうとしていた!(2009/7/24)
戦う現場に贈る分散システム構築−情報部門編(6):
その分散システムは、正しく作られているか?――開発後の検証・受け入れを考えよう
豆成くんの分散システムに関する作業もいよいよ大詰め。そんな豆成くんのところにやってきた先輩社員・蔵田が告げたセリフは驚愕(きょうがく)の内容だった。(2009/5/25)
戦う現場に贈る分散システム構築−情報部門編(5):
ここが核心! 各サービスの抽出とサービス統合――SOAサービスの切り出し方とその統合方法
業務分析の結果を既存システムと関係付け、SOA型アーキテクチャを実現するためのキモは、概念データモデルにあった。(2009/3/2)
戦う現場に贈る分散システム構築−情報部門編(4):
理想像と現実のフィット&ギャップを知る――業務分析の成果をシステム統合に活かす
業務分析の結果は、実装独立の業務モデルとして描き出される。この既存業務モデルをSOA型アーキテクチャに結び付けていく段階に大きな問題が潜んでいるのだ。(2009/1/16)
戦う現場に贈る分散システム構築−情報部門編(3):
システム統合になぜ業務分析が必要なのか?――作業の理由とITガバナンス
システム統合プロジェクトでは冒頭、業務分析が行われる。業務分析は一般の個別システム開発でも実施されるが、システム統合におけるそれはまた違った意味合いがあるのだ。(2008/12/1)
戦う現場に贈る分散システム構築−情報部門編(2):
システムを統合するために必要な事前知識――必須となる技術要素の整理と整合性について
SI会社からあるユーザー企業に転職した豆成くんは、入社早々点在する複数のシステムを統合する大役を押し付けられてしまった。これまで経験したのは独立したシステム開発だけで、業務知識もシステム統合技術も持たない豆成くんは、無事成功できるのだろうか?(2008/11/7)
戦う現場に贈る分散システム構築−情報部門編(1):
緊急課題! 点在する複数のシステムを統合連携せよ――問題山積! 乱立する情報システムの解法とは?
「サイロ化したシステム群を統合しよう」という掛け声はよく聞かれるが、実際にそれを推進しようとするとさまざまな問題に直面する。システム統合プロジェクトに求められる情報システム部門の役割やスキルから考えてみよう。(2008/10/2)