UAFの概要

大規模なシステムアーキテクチャや組織全体のアーキテクチャ(設備系のシステムに限らない)
を考える際に、思考の枠組みとして用いると非常に便利なUAFというフレームワークがある。
以下の図がそのUAFのマトリクスであり、これは顧客とのファシリテーションの際にも視座を揃えたいときに使える。

非常に学習コストは高いものの、大規模な分散アーキテクチャなどを考える際には、
個人的には必ず使った方が、運用コストや観点の抜け漏れを防いでくれて、非常にありがたいと感じている。

またこれを用いて、組織のどの部門に対して、どのような設備・ヒト系のリソース配置にするのか？
さらには、その部門へ求められる目標指標に達していないから、
・内製化するとしたらどういった教育がどのくらい必要なのか
・アウトソーシングするとしたら
・その部門に対する品質項目として何を定期的にテストしなくてはいけないのか？
などをシステム思考を用いて、仕組みづくりを行うのにも非常に役立つ。

前提条件

目的(ビジョン)が定義されていること

まずは最上位目的が定義されていること。
UAFではEnterpriseVisionのステレオタイプをつけて表現する。

これはビジョンモデリングや未来構造マップなどを用いて、予め定義する。
この目的が定義されたうえで、次の目的が達成されたのか？どうなのか？を定義する目標を定義するビューの定義へと進む。

この時のゴールなどは仮説ベースとなる。
参考文献として、以下の書籍がおすすめです。

どのスコープにおける目的なのか？が明確になっていること

UAFで表すのは、基本的に組織全体のアーキテクチャである。
これは1つの企業に限定されることはなく、
さらに広い範囲全体(複数の企業)で1つの目的を達成したいというときには、
その全体をスコープとして考えることになる。

視点の行き来

このUAFでは大きく分けて２つの迅速な視点の行き来が求められる。
・具体と抽象の行き来
抽象から具体のトップダウンだけでなく、具体から抽象へのボトムアップも求められる。
また、もしも抽象レイヤーであるStrategicビューで、
どのくらいの指標までしかこの能力は出せない　という制約が不明な場合には、
いったん未定義にしておいた上で、
より具体なレイヤーで制約を明らかにしたうえで、再度抽象レイヤーに戻ってきて再定義し直すというように進める。

・横のグリッドの行き来
構造の側面と動的な側面に矛盾があってはならないので、
左から順番にというわけでなく、何度も左右を行き来することになる。

設計原則

このUAFで管理する概念要素は、意味のある単位でまとめられていたり、変更のしやすいように関心を分離しておく必要がある。
そうすることで、外部環境の変化への迅速な対応や、再利用してコストの無駄を省くなどが可能となる。
その際に、ソフトウェア領域の設計原則である
・SOLID原則
・コンポーネントの6大原則
・GRASPパターン(特に情報エキスパート)
などが必要になってくる。

GQMワークショップ

後述のパラメタ列のメジャメント変数を考える際に、GQMワークが効果的である。

詳しくは上記のGQM記事をご覧ください。
ゴールからトップダウンで測定に必要なパラメタセットを考えていく。
もしもデータを現実的に集めるのが困難なら、そのメトリクスは変数として追わないで、別のものを考える。

データを集めるのにかかるコスト以上の価値を生み出さないデータは集めない。
過去にどんなに価値を生んでいても、時間経過で価値を生まなくなることもあることに注意。

各列の説明

左から右へ順番に考えないといけないという縛りはなく、
何度も行き来しながら要素の抜け漏れを防いだりする。
構造の側面、動的なプロセスや状態の側面などの複数の視点からの分析と、それらの整合性を取りながら、モデルを更新し続ける姿勢が重要である。
それぞれの列の内容とその関係性について以下に記載する。

Requirements

ステークホルダーの要求を定義する。
この要求がないと、その達成指標などが定義できないので、
目標がふんわりとしかイメージできない場合には、
いったん前提である、この要求に立ち戻ることをお勧めする。

ステークホルダーにとっての嬉しい要求、つまり魅力的価値以外に、
「こんなことは避けたい」という負の感情の要求である、当たり前価値
などもここに定義される。

この要求をイシューとして、サブイシュー→サブサブイシューに詳細化していく。
上位レイヤーに関心のあるステークホルダーの要求を支えるような、
下位のレイヤーに関心を持ったステークホルダーの要求がない場合、
その上位要求はイシューとしては、妥当でないといえる。

この要求が具体的に共通認識が持てる程度になっていれば、
おのずとその指標を構成する変数なども決まってきて、
それによって下位で支える構成要素も自然と出てくる。

注意事項

ここの要求の定義で道を間違うと、その後工程の
「こんな機能とこんなデータが必要だよね」といった議論が意味をなさなくなります。
一回で真の要求にたどり着くというのは現実問題難しいとしても、
曖昧な状態でとりあえず手を動かすというのは避けるべきです。
それは結果的に、変なところでコンテキストを分けてしまったりといった様々な弊害をもたらします。

Taxonomy

ここにはまず静的な概念要素を定義する。
ここには、その概念の持つ動的な側面は定義しない。
注意点としては、抽象度がバラつくと他のグリッドのモデルへのマイナス影響を与えることがある。

よくあるアンチパターン

サービスレベルの要素とサービスの構成要素が同じ粒度として扱われてしまうことがある。
このアンチパターンは、他のProcessesなどの動的側面のモデルなどで違和感がないか、チェックした上で再度このTaxonomyに戻ってくることで抑制できる。

Structure

ここには上記で考えている概念同士の静的な関係図、結合度合いを定義する。
ここで概念同士に繋がりがないと思っていても、後述のシナリオ部分で概念同士が連携していることが判明したら、ここの図を更新する。
ただし、ここには静的に結合しているもの同士を線でつないだ図を定義する。
※静的に結合している部分は、たとえばトランザクションの集約の単位なども含まれる。そこはサービス境界を定義しない方がいい部分と見なせる。

Connectivity

ここには静的な結合ではない、もっと疎な動的に結合する概念同士の関係図を定義する。
もしも、動的に全く概念AとBが連携していないのに、
なぜかStructureでAとBが関連線で結ばれていたとしたら、
Structureの方の図を修正する　などの判断がつく。

Processes

ここには概念に割り当てられるプロセス群を定義する。
プロセスの抽象度は必ず意識する必要がある。
もしも不明な場合には、そのプロセスを１段階詳細化して理解を深めたうえで、また前提の抽象度に戻るというようにする。
※　一度で完全に粒度感を決め打ちにかからないことが大事。

よくあるアンチパターン

サービスレベルのロジックとサービスよりも詳細な粒度のロジックが同じ粒度で扱われてしまうことがある。
これは前述のTaxonomyでの粒度を適当に決め打ちにかかってしまった際に起こりやすい。
そのため、ここでの粒度感のチェックをしたうえで、
Taxonomyの方の概念同士の粒度感が不揃いでないか？をチェックするのがマストである。

States

ここには状態の種類と、状態遷移を定義する。
状態モデルがあることで業務理解が深まることもあるので、
ここのモデルは定義がマストではないものの、
定義して他のモデルとの整合を取っておいた方が無難である。

またTOCでいうところのDE(良い状態)、UDE(悪い状態)を定義できる所でもある。

下記のようにネストした状態などもここに定義する。

Interaction Scenario

ここには業務アクティビティの時間的流れを定義する。
MetaおよびStrategicビューでは、処理の順番は考えないビューのため、
未定義にする部分である。

ここでもしも処理を担う者がまだ不明な場合には、
いったん処理の流れを定義し、後で下図のように修正してもいい。

注意点

必ず●部分に、この業務フローの事前条件を◎部分には事後条件を定義しておく。
そうでないと、この事後条件においてステークホルダーの目的が達成されたのかが不明になりやすい。
それだけでなく、システムユースケースの粒度を見誤りやすくなることにも繋がる。

条件分岐

条件分岐の判断ロジック部分には、その業務上の方針系ルールが存在している。
その中でボトルネックとなりやすいものを特定し、変更しやすくしておく工夫が大切である。

処理の粒度

この一連のフロー全体を大目的とすると、各処理ブロックは中目的の粒度感で統一されていることが望ましい。
その結果、図でいうと【利用者】という者が、
・カードを挿入する
・暗証番号を入力する
・引き出し金額を入力する
・現金、カードおよび伝票を取り出す(←処理名が曖昧なのは触れない)
という処理を持つ　といえる。

もしも処理ブロックの粒度感が揃っていないと、
Processesの方に、抽象度の揃っていないプロセス群を出してしまうことに繋がる。

各プロセスの事前条件・事後条件

このInteractionシナリオモデル図を描く理由の１つに
各プロセスの事前条件・事後条件を明らかにする　というものがある。
この事前事後条件が明確にわからないと、正確に抽象化したりすることができない。

逆に言うと、この事前事後条件を明らかにせず、適当に抽象化してしまうと、間違った抽象化をしてしまっていても気づかずに、
まとめられない概念を１つの抽象概念として扱ってしまいかねない。

Information

ここには各抽象度に応じたデータモデルを定義していく。

業務で使用するようなデータを具体なレイヤーでは、データのスキーマなどを意識したモデルとして定義し、抽象なレイヤーではマクロなデータのみを定義する。

たとえば、【注文】と【注文明細】というものがあった場合、
注文明細に関しては、詳細すぎるため注文という情報のみを出すことにする。

UAFでは、このInformationビューは一列にまとまっているが、
これは非常にミスリーディングである。

本来は各抽象度ごとに、構造モデル(ER図)、データの動的モデル(DFD)
を描くなど行う必要がある。

そのため、UAFの各グリッドごとに情報モデリングを行う必要がある。

ただし、ビジネスアーキテクチャでは情報よりも、
どちらかというとプロセスに関心の強さが寄っていることや、
ビジネスサイドとの議論は、機能的な観点からの方が認識合わせをしやすいため、
Informationビューは、後から議論する形が現実的であると感じる。

Parameters

ここには、大きく分けて以下の２つのパラメタを定義する。
・影響を受けるような外部環境の変数
・測定可能な内部環境変数

ここでの変数を定義するためには、前提としてRequirementsに要求が
具体的に定義されていることが必須である。
その要求をもとに「～～したいという要求を達成したかを判断するために、どんな変数をみればいいか？」という問いを立てて、
必要な変数をワークなどで考えてみればいい。

外部環境変数

自分たちではコントロールできない外部環境の情報をここで定義する。
Strategicレイヤー以下のレベルは、すべてこの外部環境の影響を受けることに注意。
ここの分析は、3C分析などと組み合わせて行うことになる。

たとえば、気候などの影響を受けるような場合、気象情報が外部環境変数を考えるにあたり、重要になってくる。
そこで【気温】や【風向き】【風量】【雨量】といったパラメタが外部環境変数として挙げられる。

ここでは暗算のようにパラメタを出しているが、実際にはGQMワークなどを開催し、気象情報を構成するデータを考えないといけない。

ちなみに、ビジネスケイパビリティに対して、ほぼ影響を与えないような変数はすべて無視する。

さらに下限値や上限値があれば、その内容も定義する。

何度も言うが、この外部環境は、自分たちのビジネスに影響を及ぼすものの、
自分たちでコントロールすることができないような変数である。

つまり、目的を達成するために、戦略の場合分けが発生する。

例)
①　気温が20℃以上30℃以下かつ1hあたりの雨量10mm以下の場合：　戦略X＝ケイパビリティaとbのセット
②　気温が20℃未満の場合かつ風速10m/s以下：　戦略Y＝ケイパビリティcとdのセット

外部環境の変数の制約や　自分たちのバッファコスト制約を課すことによって、
ケイパビリティの指標をどの程度まで発揮したらいいのか？の下限や上限値が
おおよそ決まってくる。
この範囲を一切決めていないと、後の工程で要件が決まっていないがゆえに、
次の設計フェーズでどの案を採用したらいいのか？などにあいまいさを残すだけでなく、
戦略を満たすワークフローの設計も決まらない。

ちなみに、ある戦略で風向きが影響を与える重要な外部環境変数であったとしても、
戦略の種類を変えたら風向きは特に戦略に対して影響を与えない　ということも起こるので、どの外部変数が自分たちの戦略に影響を与えるのか？
を仮説と　データ分析による客観的検証を持って考察しないといけない。

内部環境変数

自分たちでコントロールできる変数、
各プロセス群などの目標指標を構成するパラメタセットをメジャメントとして定義する。
たとえば、システムの稼働している環境の条件などがまさにこれである。
たとえば、【～～を予約する】というシステムユースケースがあった場合、
そのユースケースの動く本番環境の条件群が、この内部環境変数に相当する。

注意点として、測定可能な変数であることがあげられる。
もしも現実的に測定が不可能なのであれば、それはその時点では変数として考えない。

この内部環境変数をあぶり出すためには、
GQMストラクチャを考えて、必要でかつ現実的に集められそうなデータを考え、
ログとしてとって測定する。
といったように、集めるべきログデータのWhyにも繋がってくる。

Constraints

ここは各抽象度において存在する制約条件を定義する。
ちょうどここで、TOCの考え方が必要になってくる。

法律などの外的な制約の内容などもここに定義し、
自組織で課している内的な制約においてもここで定義するが、
必ず外的制約と内的制約とは、要素を分離しておく必要がある。

そうしておくことで、法改正などの外部環境変化にも柔軟に対応できるようになる。
(※　設計思想の基本である、関心の分離が土台にある。)

※　特にProjectビュー × Constraintsのところが、
プロジェクトにおける制約条件を考える箇所であり、
ここでCCPMを使って、制約をうまく使いこなすことになる。

全体のマクロな範囲における制約条件を明らかにし、
その上で原因を作り出している、さらに詳細な範囲の制約箇所を絞り込んだりする際に使用する。

注意点

運用し出してからのボトルネックの特定は、
MetaやStrategicビューなどの抽象(マクロ)レイヤーでの制約からざっくりの制約の場所を特定し、
そこから徐々に詳細化していって、真因の深いボトルネックを「このリソースが原因で全体としての」特定するという流れである。

あるボトルネックを解消した際に、別のより大きなボトルネックが発生しては意味がない。
事前に「このリソースのボトルネックを解消したら、上位概念に対してどのような影響を与えうるのか」をミクロからマクロにボトムアップに検証しておくことが重要。

RoadMap

ここでもTOCの移行ツリーの考え方をそのまま使用できる。
このロードマップが、Strategicレベルなら組織の成長戦略になるし、
Personnelレベルなら人材育成戦略になり、
Resourceレベルなら技術戦略になり、
Projectレベルならプロジェクト期間中のチームの歩む軌跡となり、
それが開発者体験、従業員価値といったものに繋がる。

プロジェクトビューのロードマップは、ODSCの一連の繋がりとして表現されているもの。
抽象レイヤーのロードマップ～具体なレイヤーのロードマップまで、一気通貫で表現されていると、

・ある具体なレイヤーでのロードマップの経路変更が、上位の抽象な経路のどこにマイナスの影響を及ぼすのか？

・抽象なレイヤーのロードマップが下位のロードマップへどう影響するのか？

がメンテしやすい。

Traceability

ここには、上位概念を下位概念で実現しているかの一連の関係を定義する。
最終的に、Meta～Resourceまでの一気通貫での実現関係になっていればいい。

各ビューのトレーサビリティ図だけでなく、
要求のトレーサビリティ図も定義しておくことが望ましい。
Resourceビューに関心のあるステークホルダーのこの要求が叶えば、
Servicesビューに関心のあるステークホルダーのこの要求が叶う。
そうすると、Strategicに関心のあるステークホルダーのこの要求が叶う。
というように、要求ツリーを定義しておく。

Security

Securityは、マトリクス上では横軸になっているが、
すべてのビューに対して横断的に考えなくてはいけない。

このビューで行うことは、主に脅威モデリングを通しての各抽象度におけるリスクの洗い出しと、それに対する対策を考えること。
それはプロセス面においてもだし、情報データに対する脅威モデリングも両方を指す。

そのリスク分析の結果、どのような品質特性を満たさなくてはいけないのか？
を継続的に考えて、それをアーキテクチャに反映するのである。

脅威モデリングとの組み合わせ

ここのビューでは、脅威モデリングなどの分析とセットで行わないといけない。
脅威モデリングに関しては、以下を参照ください。

脅威モデリングで洗い出した脅威の中で、ハイリスクなものに関しては、
このビューで脆弱性対策の実現方法を考えていく。

プロセス観点でのセキュリティ

プロセス観点での脅威モデリングは、
Security × InteractionScenarioでその対策を考える。

ただし、その際に出したセキュリティ上の機能は、システムの非機能なものであるため、通常の機能とは分けて管理しておくことが望ましい。

データ観点でのセキュリティ

Informationと交差するグリッドでデータに求められるセキュリティレベルを考える。
しかしそのためには、データフローを考えなくてはならない場面がある。
データフローを定義できるグリッドはないものの、
脅威モデリングの成果物と照らし合わせて、信頼境界などを定義した上、
このグリッドにその信頼境界を定義する。

データの側面でのコンテキスト境界である【データドメイン】
とこの信頼境界の位置が一致していたら簡単なのだが、一致していないケースもある。
なので、このInformation×Securityのグリッドでは、
信頼境界の位置を定義するというようにする。

作成手順の大まかな流れ

よくある流れとして、まずは静的な要素をTaxonomyに定義し、
Structureで要素同士の静的な構造関係をいったん考え、
次にProcessesまたは、Interaction Scenarioで動的側面の考察を行う。
その上で、Statesで処理がどの要素に対して、どの状態からどの状態に変化させるのか？を考察し、Connectivityに動的な結合状態を定義。
それを持ってして再度Structureのモデルを更新する。

ただし、もしもInteraction ScenarioでどのAgentに処理を割り当てるのか不明な場合には、いったんフローの流れのみを定義し、
Requirementsから読み解いた運用特性をもとに、
情報の所有権および、プロセスの割り当てを行い、境界位置を定義する。

この時に分散アーキテクチャのデータの所有権の考え方がベースとして必要になってくる。

ただし、いきなり物理的に分散で考えるのではなく、
まずは論理的な境界位置を考えて、論理分割だけ行っておいた上で、
境界位置が安定してきたら、状況を見て物理的にサブシステムとして分割する方が、リスクを小さく抑えられる。

Meta Dataビュー

このビューは最上位の目標を定義するビューとして使うことにする。
本当は、名前からして組織のベストプラクティス的な戦略のメタデータ系をまとめるのだろうけども、いったんはMetaDataとしてではなく、戦略よりもさらに上の目的として使うという前提で解説する。

まずはその目標名を定義し、Taxonomyへ。
未来構造マップを定義したら、そのDE(良い状態)をMetaのStates列へと定義する。
この際に、「こんな状態になっていたらよろしくない」というUDEも定義しておくことで、後述の脅威分析が効率的に進む。

定義した目標地点から逆算する形で、大目標を中目標-小目標へと分解していく。
完成した小目標→中目標→大目標という流れに違和感がないかをチェックしながらこれを最も抽象度の高い移行ツリーとして、Roadmap列へ定義する。
この時点で、複数の道筋を考えておくことが重要。
この時点での制約条件は、絶対に変えようがない条件以外はあまり考慮しなくていい。

最上位目標の定義

たとえば「隠れた敵を味方を極力損耗せずに素早く最小限のリソースで撃退したい」という要求がある場合、目的の指標として、
・索敵ミッション開始～撃退完了までの時間が、〇〇s以内
・かかるエネルギーコストが、〇〇以内
・撃退完了までの味方損耗人数が、〇人以内
などが列挙できる。
さらに、どのようなログが必要なのかまで明確に定義できる。

これらが定量的に定義されていないと、下位のStrategicビューで、
間違ったケイパビリティセットを選んでしまいかねない。

問題の可視化

先にToBeの目標値を定義したら、それに対するAsIsがどのくらいかを考える。
それによって、ギャップである問題を正確に把握する。

そのギャップをどのような道筋で埋めていくのか？
それがCCPMでいうところのODSCの繋がりみたいなものとして、
Metaのロードマップに定義される。

TOCとの関連性

このビューのConstraintsには、このUAFで管理するスコープ全体の制約条件を定義する。(たとえば、コスト制約などが代表例である。)

もしも最初に制約条件が不明な場合には、
より具体なレイヤーでの制約条件を明らかにしたうえで、再度Metaに戻ってきて定義しなおす。

Strategicビュー

ここは経営戦略、事業戦略に必要な組織の能力の要素を定義するビュー。
Metaで考えたギャップ(問題)を埋めるのに必要なケイパビリティを考える。

Metaで目標が定義されていないで、要求の段階程度までしか出ていないと、どんなケイパビリティセットが必要なのか？が定まらない。

情報システムなどの設備であろうが、ひと系のリソースであろうが、
下位のResourceビューやPersonnelビューで考えた要素が、その能力値を発揮できさえすれば問題ない。

このビューでは、Taxonomyにて【〇〇能力】といった具合に定義し、
その能力がどの程度必要なのか？　コストはどのくらいかかるのか？
などを定義する。

たとえば上記同様、「隠れた敵を味方を極力損耗せずに素早く最小限のリソースで撃退したい」という目的がある場合、最低限
①隠れた敵を正確に素早く索敵する能力
②素早く最小限労力で撃退できる能力
③なるべく損耗しないための回避能力
というケイパビリティセットからなる戦略がマストとなる。

また、索敵した上で撃退に移行するという前提条件によって、
ケイパビリティ②はケイパビリティ①に依存するといえる。

ケイパビリティ目標の定義

Servicesビューとの関連

ここで定義したケイパビリティを下位のService要素で実現するという関係性である。
しかし注意しなくてはならないのは、
ケイパビリティ1つに対して、サービスは1つと限らないこと。
またサービス1つに対して、保有しているケイパビリティは複数という、
多対多の関係性が成立する。

TOCとの関連

各ケイパビリティ要素がどのくらいの制約を受けているのか？
法律などの外的要因によって「そのケイパビリティが100までしか発揮してはならない。」といった制約が存在すれば、
その指標がStrategicビューでの制約要素として定義される。

それ以外に、自組織の保有するリソースの性能によって、
あるラインまでしか現状能力値を叩き出せていないのであれば、
具体なリソースの制約条件の集合として、ボトムアップ式に

ケイパビリティ同士の関係性を可視化

平面上にケイパビリティ要素を配置して、ケイパビリティ同士の力学関係を可視化しておくことが望ましい。
下図のように、上から見た図で各ケイパビリティを図形的に配置する。

そうすることで、ケイパビリティ同士の対立関係などを把握できるので、後述の成長戦略における副作用を未然に防げる。

ただし外部・内部環境変化に伴って、
その配置関係が変わりうるので、データをもとに仮説を持って配置関係を定期的に見直す必要がある。

上記の隠れた敵を素早く撃退したい　という例の場合だと、
索敵能力と　撃退能力　は対立関係にあるとは考えにくい。
天候などが変わったとしてもその関係は変わらないと言えるので、
これら２つのケイパビリティは、共存できる配置関係にあると主張できる。

成長戦略

このビューのロードマップに定義されるのが、組織全体の成長戦略になる。
能力が徐々に拡張していくとか、今ある能力をさらに向上させるとか。
その際に気を付けるのが、今あるケイパビリティに新しいケイパビリティを追加した際のマイナスの影響を与えてしまわないか？を事前に考えること。

Operationalビュー

このビューでは、Capabilityを実現させるような業務フローを考える。
このビューでは、どんなシステムを使うかとか、どんな人系リソースを用いるか？
などは考慮しない。　つまり、リソースに依存した内容は定義してはならない。

ポイントは、

① リソースを考慮せず、行う業務を可視化する
② 5W2Hを用いて業務プロセスを詳細に整理する
③ 業務フローの開始点と終了点を明確にし、プロセスの連携を視覚化する

最初はInteraction Scenarioから考えてしまって、
その中で、どこで責務を切り分けるのが自然かがおおよそ分かるので、
Operational Performerを見つけTaxonomyに定義する。

たとえば、隠れた敵を素早く撃退したい　という目的がある場合、
最低限、索敵能力 + 撃退能力
というケイパビリティセットからなる戦略がマストである。

索敵能力というケイパビリティのみに着目すると、
索敵活動というOperational Activityのみで索敵能力を実現しようとするのでは、粒度があまりに大きすぎる。
できれば、1段階小さい粒度感が望ましいからである。

Resourceからのボトムアップ

実際の案件では、ファシリテーションする際に、
Resourceビューでの議論でないと実質まともに議論ができない。
具体なレイヤーでのフローなどの方がより確実に共通認識を図れるからである。

その際に、意識したいこととして
Operational PerfomerとResourceの関係性は、
インターフェイスとそれを実現する具体の関係性であるということ。

この時にいくつかのケースがあってそれを以下に示す。

1つのResourceで複数のOperational Performerを実現するとき

これは下図のようになり、
丁度、SOLID設計原則でいうところのインターフェイス分離の原則が適用されていることになる。

実際には、interface分離と同様に、
いきなりこのようにOperational Perfomerを分離することが難しい。
その場合には、Operational Performerの持つ活動の集合に対して、
たった1つのPerformer名前を付けられるのか？
や　外からその活動を使う側として使わない活動が混在していないか？
を基準に考える。

Servicesビュー

ここでは、サブ組織の責任範囲やデータの所有権割り当てなどを
トランザクションの単位を気にしながら、コンテキスト境界の位置を検討するビューである。

１つのサービス量子が、１つのサブ組織の責任範囲となるように
対応付けてあげると、チーム同士の責任範囲や責務が明確であり、
メンテもしやすくなる。

ここでの設計思想として、
・マイクロサービスアーキテクチャ
・チームトポロジー
といった知見がマストになってくる。

もしも物理的にサブ組織を分けないとかであれば、
論理的にだけサブ組織としてモジュール分割を行い、
同じインフラ基盤にシステムも組織も配置する　という手法を取る。

UAFに残されている課題点

業務データのWhyになるInformationがあったりするものの、
その情報に求められる品質の側面を表現ができない。

また、情報フロー(あえてデータフローとは呼ばずにこう命名する)を表すビューも存在していない。
よって、必要に応じてデータの品質を定義できるようなものとセットで組み合わせて使うことが望ましいと思っている。

Projectビューで実験的に行ってうまくいった活動をOperationalに引き上げ。