エンタープライズ疎結合アプリＭＡＰ
今回は企業内アプリ”全体”を疎結合化した際に、どのような形になるかをご紹介するとともに、そのポイントがどこにあるかについてお話したい。小生、全社システムの絵を描くのは久しぶりである。今後何かに使えるかも知れないので、少し気合いを入れて書いてみたのでご覧いただきたい。 既にバックナンバー”2015.4.6“で、ER図を用いて疎結合化の勘所を説明したが、今一つ具体例が足りないという読者のために、局所的な例ではなく全社システムのいたる所に疎結合化を施したエンタープライズモデルを作成してみた。 ご紹介するモデルは架空の企業（業種はメーカー）であるが、各アプリケーションに登場するエンティティは定石通りに描いたつもりである。各アプリは独立して機能し、それらが緩やかにシンクロナイズしながら、全体で整合性を保って機能する自立分散型システムとなっている。 読者の方は既にお気付きと思われるが、同じ名前のエンテ
メタデータのさらなる汎化
メタデータを添えて初めて意味のある情報となるのだ（性別区分“1“や部門コード”312”はさらにマスタテーブルを参照して意味が分かる）。 このようにメタデータとはデータを補足説明するデータである。企業に存在するあらゆるデータを眺めてみると、このメタデータにも類似性を見て取ることができる。 図1の左側は従業員台帳と給与明細の簡易な人事系サンプルデータモデルで、図中の四角で囲われたエンティティの中身は“メタデータ“で記述されている。ちなみに、メタデータ名の右側に（）書きで記された”DD-XnnNN”はメタデータを完全にユニークに識別するために番号付けしたものであり、エンティティ略番”Xnn“に紐付いて付番されている。 このデータモデル上に記載されたメタデータを、再び、所属エンティティを意識せずに、データの型、桁数、及び原始的な意味が同一のものを”ドメインデータ”として括り出してみる。図1右下にD
マスタモデルでの四次元の扱い
今回はマスタ系データモデルにおいて時間軸をどのように扱えば良いのかについてお話したい。バックナンバーでも何度か触れているが、我々が実社会をシステムに落とし込む際に最も苦手なのが、この時間軸（四次元目）である。企業システムのマスタモデルを設計する際に度々ぶつかるのが、マスタデータの有効開始日、失効日に関する物理設計の課題である。論理設計の段階では、この課題に触れることが少ないので、いわゆる教科書ではあまりお目にかからない。この課題は大規模企業システムにおけるマスタデータ管理の“実運用”を意識した際に、初めて発生するといえる。 具体的にはこうだ。通常は“今”をベースとしたリアルタイム・システムでは、取引先や品目などの最新のレコードのみが存在すれば事足りる。しかし、今より過去を扱うバッチ・システムや、予期される将来を取扱う計画系システムでも、マスタデータを何らかの形で活用する必要が発生してくる。
オンバッチの薦め（リアルタイム性の誤解）
今回のブログは再び疎結合アーキテクチャに着目してみたい。今後の企業システムにとって“疎結合化“が重要なキーワードである事は、本ブログシリーズで度々提言してきた（バックナンバー2015.3.20「疎結合アーキテクチャへの転換」を参照）。しかし、システム間を疎結合にする事は、開発保守の生産性向上をもたらす一方で、データの一貫性をどう保てば良いかという課題が新たに発生する。最近注目の”マイクロサービス”を企業システムに適用する際にもこの事が最大の障壁となる。本ブログではこの疎結合システム間のデータ一貫性の課題解決の１つをご紹介したい。 かつて企業の基幹系システムはその拡大期において、ビジネスのスピードアップとともに、執拗に”リアルタイム性”にこだわり続けてきた。DBMSと対になったTPモニターの登場によってACID特性*を堅持するべく、リモートデータベースアクセス、2フェーズコミットといった高度
ユーザ企業がおかした3度の過ち
今回のテーマは、企業の情報資源管理の重要性についてである。何を今さらデータ中心？目新しいパラダイムでもないのに…と思われる読者が多いだろう。本ブログでDOAを語るつもりはない。言わんとする所は、EAは多面的であり一部が欠けては成り立たないということ。あー、ザックマンね…と言われるかも知れないがフレームワークの話でもない。「DA（Data Architecture）をないがしろにしてはならない」という、ちょっと辛口の話である。 幸か不幸か私は1982年から33年間、ひたすら姿、形が見えない企業システムの全体像と向き合ってきた。今振り返ってみると、日本のユーザ企業は、自社の情報資源管理を軽視する3回の重大な過ちをおかしたと言える。そしてその事が既存システムのメンテナンス課題に直結していると言っていいだろう。なお、最初にお断りしておくが、“過ち”とは書いたもののソフトウエアは時間をかければ修復可
Ｍ＆Aの肝となるデータＨＵＢ
今回のテーマは、リーマンショック以降ここ数年再び活況を呈しているＭ＆Ａのシステム対応に言及してみたい。本ブログシリーズでは、バックナンバー2014.10.5「モデルドリブンM&A対応とCIOの振舞い」で、M&A対応ではまず両社のシステムのモデリングありきである事をお話した。今回はさらに踏み込んで、両社のシステムを結合するポイントに“データHUB”を用いる手法について具体的にお話したい。以前からデータHUBが大規模な企業システムにおける複数システム間I/Fとして有効機能する事をお話してきたが、M&A時の企業システム統合は、歴史も文化も異なる究極の複数システム間I/Fと捉えることができる。 ここでは、一般的なセオリーとしての“ビジネス統合スキームに従ったシステムの片寄せ”については説明を省略することとし、大規模システムを段階的に統合してゆく際に必須となるブリッジングに焦点を当ててみたい。図１は
大規模＆疎結合アーキのかなめ（その２）
前回のブログではHUBアーキテクチャのメリットと基本的メカニズムについてお話したが、今回はさらにHUBアーキテクチャの進化形についてお話したい。以下の図１は前回ブログに掲載したものと基本構造は同様であるが、HUBの左肩部分にREPOSITORY（リポジトリー）の存在を加えたものになっている。今回はこの部分について言及してみたい。（バックナンバーに一般的な[REPOSITORY]の意義が書かれているので参照されたい） 前回ブログでは、HUBのメリットがI/Fのデータや処理を可能な限り汎化し1箇所に束ねることで、エンタープライズ全体の類似したコード量を減らしメンテナビリティを高めることであることを説明した。では、アプリからHUBを介して集配信されるデータやレコードの汎用フォーマット定義や、データ変換処理のマッピング定義はHUB上に生成されるI/F毎に毎回ソースコードをCOPY&PASTEして書
移行の常設化としてのデータＨＵＢ
今回のテーマは、”移行”について取り上げてみたい。通常は、システム開発のクライマックスに位置するこの”移行”であるが、理想的な移行とは、一世一代の清水の舞台から飛び降りるようなものではなく、限りなく平常時に近い波風の立たないものでありたい。この事は、バックナンバー2013.12.16 DevOpsで言わんとする事に通じる。システムの新機能がどんなに期待多きものであったとしても、移行のビジネスリスクを最小化できるに越したことはない。 近年私は、移行設計をシステム開発後の切替え手順設計という狭い意味で捉えるのではなく、最小リスクでの切替えを何時でも可能とするシステムアーキテクチャの設計と捉えるようにしている。このことは、前職32年のシステム部門生活を通じて一時も開発は止まる事なく、マイグレーション（移行）の連続であったという経験から来ている。若い皆さんは大規模開発が終われば、やがて安定期が訪れ
クラウド時代のデータアーキテクチャ
今回のブログでは久しぶりに、今では当たり前となった感が強いクラウドコンピューティングについて言及してみたい。そして話の主題は、今後クラウド環境に移行しようとされる企業にとって、ぜひともクリアーしておきたい“データ統合”の課題に焦点を充ててみたい。お断りしておくと、ここで取り扱うクラウドはＩＴを生業としていない一般ユーザ企業に大きなコストメリットをもたらすクラウドであり、その対象は業務サービスを数か月という速さで構築することを目的としたSaaSを代表とするパブリッククラウドである。 話は若干それるが、今からかれこれ7年程前の2008年頃、クラウドの技術的方向性がほぼ確立し、世間は“所有から利用へ“と新しいSaaSの登場を待ち望んでいた。当時の私は、前職のM&A対応でヨーロッパの子会社を訪問し、業務アプリの７割がSaaSだったのに驚いたものだ。その後、日本でも中小企業向けのSaaSメニューは増
あるべき姿はＩＴをネックに！
今回のブログは、TA（Technical Architecture）に焦点をあて、システムのあるべき姿を描く際の勘所についてお話したい。簡単に”あるべき姿を描く“とは言ったものの、このこと自体に確立した手法は存在しない。そして数あるITアーキテクトの仕事の中で最も創造的で、”アーキテクト“らしい右脳を用いる作業と言える。本ブログでは私の経験上うまくいった例を参考にセオリーらしきものを探ってみたい。 一般的EAの世界では、①現行（ASIS）業務⇒②あるべき（TOBE）業務⇒③あるべき（TOBE）システム⇒④現行（ASIS）システムからの移行 という流れをたどる。“業務を見据えてシステムを設計する”ということに誰しも異論はないだろう。問題は②から③を考える際に④に引っ張られ、“つまらないシステム”になり下がってしまうことが多いということである。良いシステムは、［②TOBE業務］を実現する［③T
アーキテクチャ反面教師
今週のプログテーマは、反面教師としてダメなアーキテクチヤにフォーカスしてみたい。ご承知の通り、ソフトウェアアーキテクチャーは目に見える形がない。そこで、企業システムのダメな構造を建造物に例えてみたい。 最初に思い浮かんだのが、故ジェームズマーチンの1994年の著書「データベース環境の実現と管理」にも出てくるバベルの塔である。同じく、継ぎ接ぎだらけのシステムを例えた日本の”温泉旅館”がすぐに頭に浮かぶ。どちらも10年以上前から引用してきた例えであるが、最近、これらは“まだましな方”ではないかと思う。そして近年の企業システムに相応しい例として最も近いイメージがジブリの“ハウルの動く城”である。これらの三つのうち最初と最後は地球上には実在しない。二番目の温泉旅館も近年の消防法のおかげでいずれ消えようとしている。バベルの塔はもとより温泉旅館も最近の若い人には何のことかよくわからないであろうが、“ハ
データ辞書の整理法
今週のブログは企業システムのあらゆるモデルの出発点となる“データの意味”の整理法について書いてみたい。“意味”と言った瞬間に何か小難しい話？と感じる読者の方も多いのではと思われるが、姿、形のないソフトウエアにおいて、曖昧な”意味“を出来る限り明確にすることは、品質を向上させるために避けては通れない。 バックナンバー[2014.5.7 REPOSITORY]で記載した通り、プログラム製造の主原料はメタデータ*であり、“形式（型、桁）”と“意味”から構成される。今回はその“意味”の部分に焦点を当ててみたい。業種に関わらず企業のシステム部門では、何らかのかたちで、この意味を“管理”している。そのレベルは、社員の頭の中に記憶されている（管理とは呼べない）レベルから、リポジトリ・データベースに全てのメタデータ定義が格納されている（理想的な）レベルまで様々である。テーブル定義書やＣＯＰＹ文の中のデータ
ＩＴアーキテクチャと不易流行
数回にわたりマイグレーション（移行）に関するテーマが続いたので、今回は原点に戻り“ITアーキテクチャーの正体“に迫ってみたい。これまでＩＴアーキテクチャは業種や企業の特性によってオンリーワンであると説明してきたが、さらに言えば、建築様式がそうであるのと同様にＩＴアーキテクチャは時代や社会的背景によって変化する。従って、アーキテクトは社会的風潮に敏感でなければならない。 図１はＥＡ（エンタープライズアーキテクチャ）の各レイヤを表した”よく見かける三角形の図”である。ここで着目したいのは抽象的なビジネス、データの下側に、より物理的な特性を持つ技術、アプリケーションの層があることである。特筆すべきは、最下層に位置するＴＡ（Technical Architecture）の進化が目ざましく、これに連れてＡＡ（Application Architecture）も影響を受けて数年毎に変化する点にある。Ｉ
ゴールデンレコード
今回はＭＤＭ（マスタデータ管理）の世界における“ゴールデンレコード”についてお話したい。直訳すれば、黄金のような（価値ある）レコードということになるが、いったいどういうものであろうか？バックナンバー2014.3.12“マスタＨＵＢ”では、ＭＤＭ環境下では中央に位置するデータＨＵＢに格納された唯一の正本マスタから、複数の個別アプリケーションへデータが同期されることでマスタデータの一貫性が保持されることが説明されている。この“正本“がゴールデンレコードそのものであり、全社システムの情報の鮮度、精度を保つ源（みなもと）となる。ゴールデンレコードの条件は、全社システムへブロ－ドキャストされても問題ないデータ品質であるということになる。これにはレコードが必要十分なデータ項目を保有しているかいうメタデータ的観点と、各データ項目の値そのものが正しいかどうかというインスタンス的観点を満たす必要がある。 そ
グロ－バル対応モデル
近年、国内マーケットの飽和により殆どの経営者が”グローバル化”を口にするようになった。これにより、その業務処理を支えるIT・システムのグローバル対応が必然的に取り沙汰されるようになってきた。まず、ITベンダーが、ここぞとばかりに“ITのグローバル対応には欧米製ERPに統一しましょう！”というプロモーションを仕掛ける。なにか変では？IT以外で考えてみるとこの不自然さは歴然である。グローバル化とは世界を一色に塗りつぶす事ではなく、お互いの国や民族のカルチャーを認めながらも不要な垣根を取り払い共存共栄しようというもの。まさにダイバーシティ（多様性）に相通じるものである。そこに求められるものは、インターオベラビリテイ（相互接続性）でありユニフィケーシヨン（統一）ではないと思われるからだ。 話しをITに戻し、ではグローバル対応にはどのようなシステムのモデルが適しているのだろうか。上述した同一ＥＲＰに
緩やかなマイグレーション（その１）
今回から２回連続で、マイグレーション（移行）にフォーカスを当てたお話をしたい。１回目は、近年の複雑化した企業システムが抱える”汚れたマスタデータ環境”を少しずつ浄化する移行方法についてお話したい。ずばりその解決策は、ＭＤＨ（マスタデータＨＵＢ）の構築により、スパゲッティ＆サイロ状態のシステムを綺麗にすることである。既にこの環境をお持ちの企業の方は、軽く読み流していただければ良い。 仕掛はいたって簡単で、無秩序に散乱したマスタ群から共有度合の高いものを選別しこれをＨＵＢ上に一元管理し、利用する周辺システムに配信＆同期することだ。このマイグレーションの特徴は、一気に最終形に持ってゆくのではなく、移行リスクの最小化を念頭に徐々に綺麗にして行くところにある。今回はその道程をご理解いただくため簡単な動画を作成してみた。アニメーションの１秒が現実世界の半年～１年程度と思って見ていただきたい。 動画に沿
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
