Oracle AIAは企業情報システムのMulticsだった――意味統治、BDUF、そして局地戦への後退
これは、以前書いた「意味統治論」の続きである。
前稿では、企業情報システムの歴史を「意味統治」の歴史として読み直した。構造化分析設計は変換を統治しようとした。DOAは状態を統治しようとした。OOADは構造を統治しようとした。DDDは境界を統治しようとした。SAPは意味を標準化しようとした。Oracle AIAは意味を統合しようとした。FEAFや経産省EAは意味を全社的に設計しようとした。
なぜ企業システムは「顧客」の意味統一に失敗し続けるのかーー構造化設計・DOA・OOAD・DDDから考える意味論の連邦制あるいは「ゆるEA」
本稿では、そのうちOracle AIA / Project Fusionを、もう少し別の角度から見る。
きっかけは、Xで見かけたDennis Ritchieについてのポストだった。
その元ポストでは、Ritchieの業績としてC言語、Unix、そしてMulticsへの関与が挙げられていた。CとUnixについては、今さら説明する必要もない。だが、ぼくが引っかかったのはMulticsだった。
Multicsは、有名な失敗として語られることがある。
MIT、Bell Labs、GEが関わった巨大なタイムシェアリングOS構想。高機能で、野心的で、先進的だった。だが、Bell LabsはMulticsから撤退した。その後、Ken ThompsonやDennis RitchieらがUnixを作った。
つまり、Multicsは単なる失敗では終わらなかった。
失敗したから無価値だったのではない。むしろ、その失敗の後にUnixが出てきた。巨大な理想OSの夢が崩れ、その経験が反転され、小さく、単純で、組み合わせ可能なUnix的世界へつながった。
そのとき、ぼくの頭に浮かんだのがOracle AIA / Project Fusionだった。
Oracle AIAも、企業情報システムの世界で似たことをやろうとしたのではないか。
巨大な理想を掲げた。実装もされた。部品や思想も残った。だが、最初の大きな夢は、現実の複雑性に殴られて局地戦へ後退した。
これは、企業情報システムにおけるMulticsだったのではないか。
Oracle AIAは前稿でも頭にあった
Oracle AIAは、今回突然出てきた話ではない。
前稿の意味統治論を書いている時点で、Oracle AIAはすでに頭にあった。実際、前稿ではSAP、Oracle AIA、FEAF/経産省EA、DDDを、企業情報システムにおける意味統治への異なる回答として並べた。
SAPは意味を標準化しようとした。標準パッケージの業務モデルに企業側を合わせることで、全体の意味を統制しようとした。
Oracle AIAは、その反対側にある。OracleはSAPのように単一パッケージで世界を統一しようとしたわけではない。E-Business Suite、PeopleSoft、JD Edwards、Siebelなど、複数のアプリケーション群を前提に、それらを上位の統合理論で接続しようとした。
つまり、SAPが「標準化による意味統治」だったとすれば、Oracle AIAは「統合による意味統治」だった。
前稿では、その範囲で扱えば十分だった。だからAIAを深掘りしなかった。主題はあくまで、企業システムはなぜ「顧客」の意味統一に失敗し続けるのか、という意味統治論だったからである。
ただ、そのときからAIAは気になっていた。
Geminiとの議論でも、Oracle AIAはアメリカでは有名な失敗例であるかのように話が広がった。しかし、それは前稿の本筋ではなかったので、深入りしなかった。前稿では、SAPと反対側にある意味統合の試みとして、必要な範囲でだけ取り上げた。
今回、Ritchie、Multics、Unixのポストを見て、その線がつながった。
MulticsとOracle AIA / Project Fusionは、並べて論じられるのではないか。
この接続は、AIが出したものではない。
ぼくがつないだ。
AIが問題だったのは、その後である。Oracle AIAの失敗が欧米CSでMultics級の定番アンチパターンとして語られているかのように整理されかけた。しかし、別のAIを使って出典を当たりながら確認すると、少なくとも公開Web上で見える範囲では、そう単純には言えないようだった。
Multicsは、OS史、Unix史、コンピュータ史では一定の共有教養になっている。CSの授業や教材で触れられていても不思議ではない。
しかしOracle AIA / Project Fusionは、CS史の典型的アンチパターンとして一般に共有されているわけではなさそうだ。出てくるのは、Oracle公式資料、AIA Foundation Pack、Process Integration Pack、SOA、EAI、ERP統合、業界別ソリューション、既存資産維持の資料である。
つまり、AIAはMulticsほど神話化されていない。
だが、だからこそ論じる価値がある。
Oracle AIA / Project Fusionは、企業情報システムにおけるMulticsだったのではないか。
本稿で論じるのは、この問いである。
Multicsは無駄ではなかった
まず、Multicsについて確認する。
Dennis Ritchie自身の回想では、Bell LabsがMulticsから撤退していく時期について、Multicsが当初期待されたような「使えるシステム」、まして「万能薬」を速やかに提供できないことが明らかになってきた、と書かれている。
日本語で参照しやすいものとしては、日本国際賞の解説PDFにも同じ構図が出ている。Multicsは理想を追うあまり巨大で複雑になり、全体性能にも期待しにくいとBell Labsが判断した、という説明である。
ただし、ここで間違えてはいけない。
Multicsは、単なる死産ではない。
動いた。使われた。商用利用もされた。階層ファイルシステム、タイムシェアリング、セキュリティ、動的リンク、仮想メモリなど、多くの思想や技術を残した。
UnixはMulticsを単に捨てたのではない。Multicsの経験を反転させた。巨大な理想システムではなく、小さく、単純で、組み合わせ可能なシステムへ進んだ。
つまり、Multicsは無駄ではなかった。
しかし、夢を追いすぎた。
ここが重要である。
Multicsの全体構想は、歴史の主導権を取れなかった。だが、部品、思想、経験、反省は残った。
Multicsは消えたのではない。
分解された。
分解され、再利用された。
Oracle AIAとは何だったのか
では、Oracle AIAとは何だったのか。
AIAは、Oracle Application Integration Architectureである。名前の通り、アプリケーション統合アーキテクチャである。
ただし、これは業務アプリケーション本体ではない。Oracle E-Business Suite、PeopleSoft、JD Edwards、Siebelなどを置き換えるパッケージそのものではない。既存のOracle Applicationsや他社アプリケーション、独自開発システムを、SOA、つまりService-Oriented Architectureに基づいて連携させるための統合アーキテクチャである。
より正確に言えば、SOAという一般的な思想を、Oracleが買収によって抱え込んだ巨大なアプリケーション群へ適用するためのアーキテクチャ的思想だった、と言った方がよい。
SOAは、まず製品名ではない。
思想である。
システムの機能をサービスとして切り出し、標準化されたインターフェースで連携させ、業務プロセスをそれらのサービスの組み合わせとして構成する。そうした設計思想である。もちろん現実には、ESB、BPEL、Webサービス、SOAP、XML、WSDL、各種ミドルウェア製品と結びついた。しかし、本質は製品ではなく、統合の思想だった。
Oracle AIAは、そのSOA的思想を、Oracle Applications群の統合へ適用しようとした。
Oracle公式のAIA Process Integration Pack概要では、AIAは直接統合またはプロセス統合パックの形で組込み統合機能を提供し、Oracleアプリケーションやサードパーティアプリケーションにまたがるエンド・ツー・エンドのビジネス・プロセス統合を支援すると説明されている。
PIP、つまりProcess Integration Packもここで定義しておく。
PIPは業務アプリケーション本体ではない。複数アプリケーション間の業務プロセスをつなぐ、事前定義済みの統合パックである。Oracle公式ページでは、PIPはデータ中心統合、Webサービス、参照データの問い合わせ、プロセス中心統合などの統合スタイルを組み合わせた組込み統合アクセラレータであり、AIA Foundation Pack内に定義された設計パターン、方法論、共通オブジェクト、サービスを活用するものとされている。
Oracle AIA Foundation Packについても、公式ページはかなり明確である。Oracle Fusion Middlewareの機能に、アプリケーションに依存しないEnterprise Business Object、Enterprise Business Service、リファレンス・アーキテクチャ、ガバナンスのツールと方法を組み合わせ、全社的な統合フレームワークを迅速に確立できる、と説明されている。
ここで出てくるEnterprise Business Object、つまりEBOが重要である。
AIAは、単にシステムAからシステムBへデータを渡すための配線ではなかった。Oracle Applicationsや他社アプリケーションにまたがる業務プロセスを、共通オブジェクト、共通サービス、共通プロセスモデル、共通ガバナンスで統合しようとした。
だからこれは、前稿の言葉で言えば、意味統治の試みだった。
AIAは出なかったわけではない
ここで、雑なOracle批判に落ちてはいけない。
Oracle AIAは、何も出なかったわけではない。
PIPは実際に提供された。Foundation Packも提供された。リファレンス・プロセス・モデルもあった。Oracle AIA Release 2.5について報じたIT Leadersの記事では、AIAはプロセス統合パック、ファウンデーション・パック、リファレンス・プロセス・モデルの三要素から構成され、合計30種類のプロセス統合パックと4種類のファウンデーション・パックが提供可能になったと説明されている。
Oracle公式ページにも、さまざまな組込み統合が並んでいる。Order to Cash、Lead to Order、顧客マスターデータ管理、製品マスターデータ管理、Siebel CRMとOracle E-Business Suite、PeopleSoft、JD Edwards、SAP、Primavera、Agile PLMなどをつなぐ連携が挙げられている。
つまり、AIAは死産ではなかった。
ここはMulticsと同じである。
Multicsも、動かなかったわけではない。Oracle AIAも、出なかったわけではない。
では、何が失敗したのか。
部品ではない。
夢である。
Project Fusionという夢
Oracleは、2000年代に大規模な買収を重ねた。
PeopleSoftを買った。JD Edwardsを取り込んだ。Siebelを買った。もともとのE-Business Suiteもある。さらに業界別アプリケーションや周辺製品もある。
買収とは、製品ラインを増やすことである。
だが、それは同時に、意味の歴史的堆積を抱え込むことでもある。
PeopleSoftにはPeopleSoftの「従業員」がある。JD EdwardsにはJD Edwardsの「品目」や「プロジェクト」がある。SiebelにはSiebelの「顧客」や「案件」がある。E-Business SuiteにはE-Business Suiteの「取引先」「注文」「請求」「勘定」がある。
同じ言葉でも、意味が違う。
顧客とは何か。
製品とは何か。
注文とは何か。
契約とは何か。
従業員とは何か。
組織とは何か。
これは単なるデータ項目の違いではない。業務の違いであり、組織の違いであり、導入企業の歴史の違いであり、カスタマイズの違いであり、運用の違いである。
Oracleは、この巨大なアプリケーション帝国に対して、一つの物語を提示する必要があった。
それが、AIA / Project Fusionだった。
AIAは、既存アプリケーションをSOA的に連携するための統合アーキテクチャだった。Project Fusion / Fusion Applicationsは、その先にある次世代アプリケーション群の物語だった。既存アプリケーションをすぐに捨てるのではない。Applications Unlimitedとして維持する。しかし、将来的には、より統一された技術基盤、データモデル、プロセス、ユーザー体験へ向かう。
理屈としては分かる。
むしろ、かなり頭のいい構想だったと思う。
Oracleの買収アプリケーション群を、バラバラの製品ラインとしてただ延命するだけでは、統合の物語がない。一方で、顧客に対して「全部捨てて新製品へ移行しろ」とは言えない。そこで、既存資産を活かしながら、SOA的な共通アーキテクチャで接続し、段階的に次世代へ向かうという物語が必要になる。
その意味で、AIA / Project Fusionは、Oracleにとって必要な夢だった。
しかし、夢はしばしば美しすぎる。
企業意味論は、そんなに簡単には統合できない
企業情報システムにおける「顧客」は、単なる顧客ではない。
販売管理の顧客。
請求先。
出荷先。
契約主体。
法人グループ。
見込み顧客。
代理店。
パートナー。
サポート対象。
与信管理上の取引先。
同じ「顧客」という言葉でも、業務ごとに意味が違う。
「製品」も同じである。
設計上の製品。
販売上の製品。
在庫上の品目。
製造BOM。
販売BOM。
保守契約上の対象。
サービス部品。
請求上の品目。
全部が同じ製品ではない。
「組織」もそうだ。
人事組織。
会計組織。
販売組織。
製造拠点。
法的エンティティ。
管理会計上の部門。
権限管理上のロール。
これも一つではない。
もちろん、だからこそ共通ビジネスオブジェクトが必要になる。EBOのような考え方は、問題意識としては正しい。
しかし、共通化は中立ではない。
どの業務の意味を正とするのか。どのアプリケーションの定義を基準にするのか。どの業界の慣行を優先するのか。どこまで抽象化するのか。どこから個別差異として逃がすのか。どの変換を誰が管理するのか。どの差分を許容するのか。
これは技術的問題であると同時に、政治的問題である。
前稿で書いたように、企業システムの問題は、結局「顧客とは何か」という問いに戻ってくる。意味は、一度決めれば終わるものではない。組織が存在し続ける限り、揺らぎ、分裂し、再定義される。
AIA / Project Fusionの夢は、この意味の揺らぎを、上位の統合アーキテクチャによって包摂しようとしたものだった。
ここにBDUFの問題がある。
BDUF、Big Design Up Front。事前に大きな設計を作り、それに従って全体を統御しようとする発想である。
もちろん、設計は必要である。無設計で巨大な企業システムを作れば、ただの事故になる。問題は、設計することではない。問題は、事前の巨大設計が、現実の複雑性を十分に支配できると考えることである。
AIA / Project Fusionは、企業情報システムにおけるBDUFの極北だった。
それは愚かな構想ではなかった。
むしろ、頭のいい構想だった。
だから危ない。
頭のいい人間が、頭のいいアーキテクチャを作り、頭のいい抽象化で、現実の複雑性を上から整理できると考える。これは非常に魅力的である。特に、EA、SOA、EAI、ERP統合の文脈では、ほとんど避けがたい誘惑である。
だが、現実はもっと汚い。
業務がある。データがある。バッチがある。現場がある。例外処理がある。移行できないカスタマイズがある。誰も知らないインターフェースがある。退職した担当者のExcelがある。監査対応のためだけに残された項目がある。制度変更のたびに継ぎ足された処理がある。
そこに巨大な共通意味空間を置く。
理想は分かる。
しかし、現実は抵抗する。
Applications Unlimitedという現実
では、AIA / Project Fusionの夢はどうなったのか。
Oracle AIAは消滅したわけではない。Fusion Applicationsも製品化された。現在のOracle Fusion Cloud Applicationsへつながる流れもある。AIA Foundation Packのドキュメントも残っている。
しかし、Oracle Applications群が、単一のFusion的世界へ自然に溶けて消えたわけではない。
現在のOracle Applications Unlimitedを見ると、Oracle E-Business Suite、Hyperion、JD Edwards EnterpriseOne、PeopleSoft、Siebelが対象として明記されている。Oracleは、少なくとも2037年までApplications Unlimitedを延長するとし、「無理な移行はありません」とも書いている。
これは重要である。
もしProject Fusionの夢が素朴な形で実現していたなら、買収製品群はFusion Applicationsへ収斂し、既存アプリケーション群は歴史的役割を終えていったはずである。
しかし、現実にはそうならなかった。
既存アプリケーション群は残った。
そして、必要なところだけがつながれた。
共存という言葉が象徴的である。
全面移行ではなく、共存。既存のPeopleSoftやE-Business Suiteを残しながら、Fusion側の機能を部分的に使う。全部を一気に置き換えるのではなく、段階的に接続する。
これは敗北ではない。
だが、夢の後退ではある。
全体を統御する巨大アーキテクチャから、局所的な統合へ。
単一の未来像から、共存と段階移行へ。
統合スイートの夢から、既存資産維持とクラウド機能追加へ。
AIA / Project Fusionは、死んだのではない。
分解されたのである。
分解され、再利用された。
MulticsとAIAは何が同じなのか
ここでMulticsに戻る。
MulticsとOracle AIA / Project Fusionは、もちろん同じものではない。
MulticsはOSである。AIA / Project Fusionは、企業アプリケーション統合とOracleのアプリケーション戦略である。技術階層も違う。時代も違う。共同体も違う。失敗の見え方も違う。
だが、失敗形式は似ている。
大きすぎる夢。
複雑性を上位アーキテクチャで統御できるという信念。
先進的な部品。
実装された部分。
現実との摩擦。
局地戦への後退。
分解。
再利用。
そして、後から振り返ったときの、奇妙な有用性。
Multicsは無駄ではなかった。
Oracle AIA / Project Fusionも無駄ではなかった。
どちらも、実装された。使われた。部品や思想を残した。
だが、どちらも夢を追いすぎた。
Multicsは、OSの世界で、複雑性を一つの理想システムとして統御しようとした。
Oracle AIA / Project Fusionは、企業アプリケーションの世界で、買収によって積み上がった製品群と業務プロセスを、SOAベースの共通意味空間へ収斂させようとした。
どちらも、夢としては美しかった。
しかし、現実はそれより強かった。
Multicsの後にはUnixが来た。小さく、単純で、組み合わせ可能なものが来た。
AIA / Project Fusionの後には、Applications Unlimited、共存、Fusion Cloud Applications、SaaS API、iPaaS、個別統合、段階移行の世界が来た。
巨大な全体構想は壊れた。
だが、部品は残った。
思想も残った。
反省も残った。
それが技術史である。
意味統治を諦めるな。巨大な夢を疑え。
ここで誤解してはいけない。
AIA / Project Fusionが巨大統合の夢に敗れたからといって、意味統治が不要になるわけではない。
むしろ逆である。
前稿で書いたように、企業情報システムでは、意味統治は避けられない。顧客、契約、商品、組織、勘定、売上。これらの意味が部門ごと、システムごと、レポートごとに分裂すれば、企業は自分が何をしているのか分からなくなる。
BIの数字が合わない。
MDMが炎上する。
データレイクがData Swampになる。
RAGやAIエージェントが、システムごとに異なる答えを返す。
KPIの定義をめぐる会議が終わらない。
これはAI時代に突然生まれた問題ではない。
企業情報システムが半世紀以上向き合ってきた問題である。
だから、AIAの教訓は「意味統治を諦めろ」ではない。
「巨大な完成モデルで意味統治できると思うな」である。
必要なのは、SAPの再来でもない。Oracle AIAの復活でもない。全社統合EAへの単純回帰でもない。DDD単独主義でもない。
必要なのは、意味論の連邦制である。ゆるEAである。
各ドメインは自律性を持つ。販売は販売のモデルを持つ。物流は物流のモデルを持つ。会計は会計のモデルを持つ。人事は人事のモデルを持つ。分析基盤は分析基盤のモデルを持つ。
それでよい。
ただし、境界で何が起きているかを把握しなければならない。
どのシステムがどの概念の責任を持つのか。
どのシステムがどのデータの正本なのか。
どの概念がどこで変換されるのか。
どの差分は許容されるのか。
どの差分は企業全体を壊すのか。
これを継続的に管理する。
EAは完成図ではない。
継続的な意味統治である。
AIA / Project Fusionの失敗から学ぶべきことは、アーキテクチャを捨てろ、ではない。
アーキテクチャを夢で終わらせるな、である。
AI批評としての技術史
最後に、これはAI批評でもある。
ただし、ここを取り違えてはいけない。
AIがMulticsとOracle AIAをつないだのではない。
つないだのは、ぼくである。
前稿の意味統治論を書いている時点で、Oracle AIAはすでに頭にあった。そこで扱ったのは、SAPが意味を標準化しようとしたのに対し、AIAは意味を統合しようとした、という範囲だった。
その後、Ritchie、Multics、Unixのポストを見た。
そこで、MulticsとOracle AIA / Project Fusionを並べる発想が出た。
AIの問題は、その後である。
AIAの位置づけを確認する過程で、あるAIはそれを「欧米CSでは有名な失敗例」であるかのように膨らませた。しかし、出典を当たりながら確認すると、少なくとも公開Web上で見える範囲では、その断定は怪しかった。
Multicsは、OS史、Unix史、コンピュータ史の中で語られている。
Oracle AIA / Project Fusionは、SOA、EAI、ERP統合、Oracle Applications実務史の中に埋もれている。
では、AIは完全に無意味だったのか。
そうではない。
AIの雑な整理をそのまま信じれば、ただのAIコピペ記事になる。だが、違和感を持ち、別のAIで出典を当たり、定義を確認し、何が言えて何が言えないかを切り分けると、粗い言い方は崩れる。
その後に、残るものがある。
今回残ったのは、MulticsとOracle AIA / Project Fusionを並べるというアイデアである。
これはAIが出したアイデアではない。
ぼくのアイデアである。
だが、そのアイデアを、AIとの対話と出典確認によって、より正確な形へ鍛えることはできる。
ここで必要なのは、AIを信じることではない。
AIを殴ることでもない。
自分のアイデアをリングに上げ、AIをスパーリング相手にし、ファクトで殴り、定義で締め、論証に耐える形へ鍛えることだ。
技術史もまた、勝者だけの歴史ではない。
壊された構想が、どのように分解され、再利用され、後続に技を残したかを見る必要がある。
Multicsは、そういう存在だった。
Oracle AIA / Project Fusionも、そう読むべきである。
Discussion