TOGAF9について

Open Groupのエンタプライズアーキテクチャ実践者カンファレンス(Enterprise Architecture Practitioners Conference)というが現在San Diegoで開催されていて、そこでTOGAFの第9版が発表されたとのことです。

  1. The Open Group Announces General Availability of TOGAF(TM) Version 9

以前SOAのブログで紹介したDana Gartnerさんもその紹介を書いています。

  1. TOGAF 9: Take control of your IT architecture

TOGAF文書はOpen Groupのメンバでなくても90日の評価ライセンスでPDFファイルをダウンロードできます。しかし、(同じものかどうか分りませんが)オンライン閲覧も可能になっており、オンライン版は次のURLが入り口になっています。

  1. Welcome to TOGAF™ Version 9 — The Open Group Architecture Framework

「Using TOGAF to Define & Govern SOAs」という章でSOAをこの枠組みの中に取り込もう(少なくとも位置づけを説明しよう)としています。Cloudについても触れているとのことですが、まだどの章のどこのことか場所が特定できていません。

改善され完成度が上がったのだろうと思いますが、同時により大きな枠組みになっているはずです(何ページになったのでしょうか?)。全体像を把握するのは大変そうです。日本ではどんな反応が出るのでしょうか。楽しみです。

補足: 本件は欧米(特に米国)のメディアでかなり取り上げられ、注目を集めています。ひょっとすると(他に大きなニュースが無く)本日一番のITニュースだったのかもしれません。いろいろな見方がありますが、初お目見えのメタモデルにも関心が向けられています。

TOGAF9について

徒然草について

このブログの名前に「徒然」とつけていますが、その理由は二つあります。一つは、徒然草でよく舞台として登場する仁和寺や双が丘が地元で馴染み深かったこと。もう一つは、有名な序段の「つれづれなるまゝに、日暮らし、硯にむかひて、心にうつりゆくよしなし事を、そこはかとなく書きつくれば、あやしうこそものぐるほしけれ」がなんとなく最近の気分にぴったりきたことです。

徒然草をネット検索してみると随分沢山の現代語訳があります。そういえば原文は長い間見たことがありませんでした。ぱらぱら眺めていると、その中に「何事も、古き世のみぞ慕はしき。今様は、無下にいやしくこそなりゆくめれ。かの木の道の匠の造れる、うつくしき器物も、古代の姿こそをかしと見ゆれ。」という第二十二段があり、「昔は良かった」というのは大昔からの真理のようです。

アーキテクチャやモデリングでも「古き世のみぞ慕はしき」(抽象レベルを上げてお絵かきをするするよりテキスト指向の美しいコードが良い?)と言われそうです。規模の問題があるので、そう単純な話ではないでしょうが。

ところで、技術の進歩に関して時々「以前同じ議論をした気がする」ということがないでしょうか?私でも何度か体験しています。どうも技術はスパイラル状に進化(なら良いのですが単なる変化かもしれません)していて、数年すると別の用語を使って何年か前と概念的に同じ議論をしていることがあります。米国人の知り合いと雑談していた際、彼は今やっている議論は6度目だと言っていました。スパイラルでも上昇すれば良いのですが、時には少し下に落ちて回ってくることがあります。何しろ急に新しい3文字熟語が現れて、過去を捨ててその世界で全部を再整理しようとするためでしょう。やはり過去の技術や議論など十分に勉強しておく必要があるということでしょう。そういう意味では、兼好法師の時代から人間は(日本人だけでしょうか?)何も変わっていないのかもしれません。

徒然草について

アプリケーションフレームワークとモデリングとMDDについて

つい先日もソフトウェアアーキテクチャのモデル記述についてを書きましたが、世の中にはシステムの全体像を幾つかの観点(ビューポイント)から記述するエンタプライズアーキテクチャないしアプリケーションフレームワーク(FEA, DoDAF/MODAF, TOGAF, RM-ODP他)というものがあります。これらについてはアーキテクチャ表現方法(記法)が決められていないことも多く「ハイレベルでの記述」が多いような気がします。次にUMLのようなモデリング技術があります。これには汎用のUMLと、ドメイン用のモデリング言語があります。そしてモデルに基づいてシステム開発を行うというモデル駆動開発(MDD)があります。

これらは最終的にはシームレスに結びつくべきなのですが、今のところそうなっていないようです。どうしてでしょう?エンタプライズアーキテクチャないしアプリケーションフレームワークはAS-ISとTO-BEのシステム全体を大きく捉えるのに有効、むしろ全体を押さえるためのものです。これと比べ、モデリングはある程度の抽象レベルで詳細化や厳密さが求められるため、対応出来る人が違ってきます。この2段階だけでも結構調整が難しそうです。更にMDDになると、今度はプラットフォームにマッピングするため抽象度の高いものをどんどん具体的なものに置き換えたり追加したりしてゆきますので、ある意味通常のプログラミング・プログラマーにどんどん接近してきます。

これらがシームレスに結びつくには、どこか特急ルート的な道筋を設けるのが良さそうです。それは近道なのかRoRのような方式なのか分りませんが、何か工夫が要りそうです。

今度は逆にMDDからスタートしてみてみます。MDDがうまく働くということは、対象プラットフォームやフレームワークがはっきりしており、そこに自動的にマッピングできるようなモデルが与えられていることが前提になります。そのモデルは、IT化されるわけですから、システム分析の結果システム化対象となっているはずです。その部分を含む対極的なビジネスプロセス定義などを含むようなものがモデリングの始まりに来ているはずです。そしてそのモデルは、エンタプライズアーキテクチャないしアプリケーションフレームワークのシステム規定に近い部分になっているはずです。

カバレッジが広く大変ですが、このあたりをつなげないと一貫したそして持続するシステム開発になかなか近づけないと思います。

アプリケーションフレームワークとモデリングとMDDについて