Understudy Architect

In-house ITとLine of Businessの両方に役立つEA (Ente…

Understudy Architect

In-house ITとLine of Businessの両方に役立つEA (Enterprise Architecture) のおはなし

最近の記事

「物質世界」をモデル化する

今回も前回に引き続き、Archiのパレット上に居るのに今まで紹介されなかった面々にスポットを当てます。 「フィジカル」レイヤー初期のArchiMateの開発には金融、保険、税務分野の人々が多く関わっていたのでその反動、というワケでもないでしょうが、製造業を意識した要素がバージョン3から追加されています。 「設備 (Equipment)」「施設 (Facility)」「物流網 (Distribution Network)」「マテリアル (Material)」 「設備」と「

    • 「境界」や「経路」をモデル化する

      今回は、Archiのパレット上に居るのに今まで紹介されなかった面々にスポットを当てます。思いのほか量が増えたので前後編の2回にわけてご紹介します。今回はその前編です。 ビジネス・オブジェクトのなかま「レプレゼンテーション」と「コントラクト」 これらとビジネス・オブジェクトとの関係を絵にするとこのようになります。 ビジネス・オブジェクトとコントラクトとの関連は、3本とも逆向きにも引けます。念のためですが、これはArchiMateを説明するための、いわゆるメタモデルであって

      • 「動き」をモデル化する (「その他」オマケつき)

        ArchiMateリレーションシップ、今回は「動的 (Dynamic)」と、バンドルで「その他 (Other)」リレーションもご紹介します。動的リレーションが「トリガ (Trigger)」と「フロー (Flow)」、その他リレーションが「特化 (Specialization)」と「関連 (Association)」の、それぞれ2種類です。 「動的」リレーションは、時間・空間的な概念を含むところが「構造」や「依存」のリレーションとの違いになります。時間・空間的な概念とは、「順

        • 「依存関係」をモデル化する

          ArchiMateのリレーション、今回は「依存 (Dependency)」です。前回の構造リレーションと違い、依存リレーションはターゲット要素に何らかの「作用」を及ぼします。 なぜそれを「依存」と呼ぶのかというと、ArchiMateの「お里」が元々「オブジェクト指向だから」、ということになります。そのお国コトバでは、オブジェクトaがオブジェクトbを呼び出して使うとき、aはbに依存している、といいますが、その名残、というワケですね。 依存リレーションは「インフルーエンス (

        「物質世界」をモデル化する

          「構造」をモデル化する

          単語を並べて文章にする「継続事業」という概念に「カタチ」はないが概念的な「構造」はあって、それは「概念要素」の「関連」で表現できます。これまで様々な種類の概念要素をご紹介してきましたが、概念要素を並べただけでは構造にはなりません。バラバラな〇ゴブロックと同じですね。 これらを組み上げれば、ブロックは概念ではなく物理的存在なので「カタチ」が出来て、そこに「建物」とか「乗り物」とかいった意味なり価値なりが表現されることになります。ArchiMateで概念要素間に関連を引くことは

          「構造」をモデル化する

          ArchiMateをスケールさせる

          これまでArchiMateの各要素をご紹介してきましたが、今回は趣向を変えて、少しテクニカルな話題を取り上げてみたいと思います。 解るヒトが多ければ多いほど良いエンタープライズ・アーキテクチャは継続事業全体を包含するので、そのモデルも当然大きくなります。ここで気を付けなければならないのは因果関係ですね。こういう取り組みでは先に大きなモデルを作ることをゴールにしがちですが、そうすると大体やっているうちに疲弊してしまって、最後にはこれも「発散」してしまいます。 組織内の誰もが

          ArchiMateをスケールさせる

          プロジェクトをモデル化する

          今回は「導入と移行 ("Implementation and Migration") 」要素のご紹介です。一般的にアーキテクチャの変化をあらわすとき、「使用前」「使用後」のような図を書きますが、その差分も含めてデータにするのに使えます。 プラトープラトーは「アーキテクチャにさしたる変化がない期間」です。ただし、これには2つの異なる意味があって、それらの区別を理解する必要があります。 一つは名前通りに「アーキテクチャ目線」で、アーキテクチャのある部分の今の状態、将来の状態と

          プロジェクトをモデル化する

          「理念」と「実存」とのあいだ

          今回はArchiMateのストラテジー・レイヤーにある4つの要素をご紹介します。モチベーション要素は「可変の未来」、構造や振る舞い要素は「不変の過去」の表現ですが、ストラテジー・レイヤーの要素は、「不変の過去の抽象化」「可変の未来の具体化」で、「理念と実存」「未来と過去」を繋ぐ構造を描くのに使います。 ストラテジー・レイヤーは「ビジネスモデル」ストラテジー・レイヤーの主な要素である「バリュー・ストリーム」、「ケイパビリティ」そして「リソース」の3つで、組織のビジネスモデルを

          「理念」と「実存」とのあいだ

          「理念とか意志とか」をモデル化する

          過去2回は継続事業の「実存」についての表現でした。そこには現実のキャピタルやオペレーションがあり、現実のバリューを生み出しています。でもそれは自然の摂理ではなく「人間の意志と理念」から生じるものですよね。 理念とか意志というと創業のとき書いたりするものと思いがちですが、そんなことはありません。それなしで事業継続も成り立たないでしょう。 VUCA的には「アニマル・スピリット」という表現もありますが、「継続事業の論理構造」に「アニマル・スピリット」を付け足すことは出来るのでし

          「理念とか意志とか」をモデル化する

          「主語」と「目的語」をモデル化する

          前回はArchiMateの振る舞い要素についてご紹介しました。今回は構造要素をご紹介します。下の図の左側「リソース」の仲間たちです。 「振舞い」の目的語 前回ご紹介した「振る舞い」要素には、振る舞う対象があります。レイヤー毎に下のような図形であらわされます。 上から「ビジネス・オブジェクト」「データ・オブジェクト」「アーティファクト」です。ArchiMateではこれらを「受動構造 ("Passive Structure") 要素」と呼んでいます。アプリケーション・レイヤー

          「主語」と「目的語」をモデル化する

          「振る舞い」をモデル化する

          角が丸いか四角いか前回の記事で、手始めにこんなモデルを描いてみました。 この二つの四角をよく見ると、Resourceのほうは角が四角くて、Capabilityのほうは角がまるくなっています。 ArchiMateでは、四角い角を「構造要素 ("Structure Element")」、丸い角を「振舞い要素 ("Behavior Element")」と呼んでいます。構造要素は、静的・スタティックな、「在る」「モノやヒト」を、そして振る舞い要素は、動的・ダイナミックな、「やる」

          「振る舞い」をモデル化する

          タダで始めるEAモデリング

          EAモデルの「最初の点」を打つのはとても簡単で、おカネも全く掛かりません。文献やツールは英語ですが、気にすることはありません。早速やってみましょう。 ArchiMate®を使おう!ArchiMate (アーキメイト)とは、EAモデリングのための標準記法、即ちEAを表現するときに使うべき「基本的な語彙」と、表現に適用される「文法」とを定めたものです。また、モデルをグラフィカルに表現するときに適用されるシンボルも規定しています。 "ArchiMate3.1 specifica

          タダで始めるEAモデリング

          EAリテラシーはデータリテラシー

          (前回の記事「ITオンチな組織」と思われないために) ゴーイング・コンサーンをデータ化する継続事業の全体を、どうすればモデル化出来るでしょうか。モデルというとまずは平面上に描かれた図形が思い浮かびますが、継続事業の全体となると、二次元平面上の視覚表現では、巨大になり過ぎたり、抽象的過ぎたりしそうで中々難しそうです。 そもそも「継続事業」というのは「概念」ですね。「概念」には「形状」は有りませんが「構造」はあります。ですから継続事業をモデルにしたいときは、その概念構造を作れ

          EAリテラシーはデータリテラシー

          「ITオンチな組織」と思われないために

          日本がIT後進国という評判は既に定着してしまった感があります。もちろんテックベンチャーもどんどん増えていますが、既存の組織、とりわけIT関連ではない業種ではいわゆる「ITオンチ」問題が深刻化しているようです。 このような「ITオンチ」組織に対しては、すでに様々な立場から様々な助言が提供されていますが、ここではそれらとは少し異なる切り口で、実際的な解決の可能性を探ります。 「ITオンチ」が組織にもたらすもの「ITオンチ」自体がどういった状態を指すのかはいろいろあるでしょうが

          「ITオンチな組織」と思われないために