# Analysis — mono2micro_IBM

Documentation: https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ (entry point); technical paper at https://ar5iv.labs.arxiv.org/html/2107.09698
Date: 2026-06-28

> IBM Mono2Micro is a closed-source, since-withdrawn IBM toolset (ESEC/FSE 2021 industry paper). Analysed via online documentation only — no local codebase. Prefer the source paper as ground truth; the modernization-playbook and community walkthroughs describe the shipped tooling and UI.

---

## Filled Analysis Template

### Goals
- Semi-automated decomposition of monolithic Java EE applications into candidate microservices, plus code generation to realise them. `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — paraphrase: AIPL generates microservice recommendations and Cardinal "generates a significant portion of the code needed to realize the recommended microservices in containers".`
- Align decompositions with business functionality. `https://ar5iv.labs.arxiv.org/html/2107.09698 — paraphrase: the tool considers business use cases as a "space dimension" alongside temporal call patterns, aligning classes and dependencies with business functionalities.`

### Phases
- Static instrumentation (Bluejay) → runtime trace collection (Flicker) → AI analysis/partitioning (AIPL/Oriole) → code generation (Cardinal) → visualization/editing (UI). `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "Bluejay - instruments the Java source code of monoliths"; "Flicker ... gathers runtime analysis data"; "AIPL - The AI engine of Mono2Micro"; "Cardinal ... Generates a significant portion of the code".`

### Granularity
- **Class** — decomposition produces partitions of application classes. `https://ar5iv.labs.arxiv.org/html/2107.09698 — "clustering on classes observed in the traces to recommend partitions of the application classes."`
- Methods are instrumented and observed but only as a means to build class-level relations, not as the decomposition unit. `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "The instrumentation captures entry and exit of every Java method in the application."`

## Representation Collection

### Collector

#### Source

##### Development
- **Source code** — Java EE monolith source is the primary input and is instrumented. `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "Java EE monolith application source code".`
- Build/config/deployment descriptors are consumed for static dependency tables (Maven/Gradle, server.xml, web.xml, persistence.xml). `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "Java EE deployment descriptors (web.xml, ejb-jar.xml, application.xml, persistence.xml)".`
- **Database schema** — not used. [evidence not found]
- **Version history** — not used. [evidence not found]

##### Runtime
- **Runtime log traces** — runtime call traces gathered from instrumented execution of test cases. `https://ar5iv.labs.arxiv.org/html/2107.09698 — "Runtime traces are defined as T(ui)=⟨t₁,t₂,…⟩, where each trace t_i is generated by running a use case u_i."`
- **User interactions** — use cases are exercised by running functional test scenarios; the practitioner records named workflows, but these are test-driven flows rather than captured end-user sessions. `https://heidloff.net/article/step-by-step-instructions-mono2micro/ — "Users record typical application workflows using the Flicker tool, naming each flow (e.g., 'show-shop', 'add-to-cart')."` (Unclear whether this counts as the model's "User interactions" leaf vs. runtime traces — see Vocabulary Fit.)
  - Runtime log traces

##### Higher-Level Models
- **Business process model / Use case** — practitioner-defined business use cases drive the "space" dimension of decomposition. `https://ar5iv.labs.arxiv.org/html/2107.09698 — "business use cases provide functional alignment".` These are labels attached to test runs, not formal higher-level models. (See Vocabulary Fit.)
  - Use case is present, but is not analysed as a model; it is consumed as a label for runtime traces.

##### Documentation
- **Directly in the code** — inheritance/annotations are read into reference tables. `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "refTable.json capturing method signatures, class variables, and inheritance".`
  - This is just functional code, not really documentation
- **Paper / Digital format** — not used as input. [evidence not found]

#### Collection Technique
- **Static analysis** — Bluejay performs static code analysis to build dependency/symbol tables. `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "symTable.json documenting class dependencies and package relationships".`
- **Dynamic analysis** — runtime traces captured via method-level probes during test execution. `https://ar5iv.labs.arxiv.org/html/2107.09698 — "entries and exits to each function, including the constructors via added probes."`
- **Version analysis** — not used. [evidence not found]
- **Model analysis** — business use cases are consumed but as run-time labels, not as parsed higher-level models. Unclear. `https://ar5iv.labs.arxiv.org/html/2107.09698 — paraphrase: use cases provide the space dimension of decomposition.`

### External
- No external ontology/taxonomy is used. The only external human input is the business use-case definitions and target cluster count. `https://ar5iv.labs.arxiv.org/html/2107.09698 — "Practitioners must create use cases and define the target partition count".`

## Representation

### Analytical

#### Structure
- **Inner structure** — method signatures, class variables captured. `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "refTable.json capturing method signatures, class variables, and inheritance".`
- **Inheritance** — captured in refTable. `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "... and inheritance".`
- **Association** — class dependencies and package relationships captured. `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "symTable.json documenting class dependencies and package relationships".`

#### Behavior
- **Call graph** — class-level calling-context trees built from traces. `https://ar5iv.labs.arxiv.org/html/2107.09698 — "Calling-context trees (CCTs) at class level: nodes represent classes".`
- **Sequence of accesses** — temporal/co-occurrence relations among classes from runtime call traces. `https://ar5iv.labs.arxiv.org/html/2107.09698 — "temporal relations and co-occurrence relations among classes extracted from runtime call traces".`
- **Frequency** — direct/indirect call relations and patterns are aggregated over traces (call counts/patterns). `https://ar5iv.labs.arxiv.org/html/2107.09698 — "Direct call relations (DCR) ... Indirect call relations (ICR) ... Direct call patterns (DCP) ... Indirect call patterns (ICP)".` (Frequency-like, marked Unclear: counts of calls, not performance counters.)
  - This is frequency
- **CPU / Memory / Response time** — not captured. [evidence not found]

#### Evolution
- Not captured (no version history). [evidence not found]

### Type
- **Monolith** — the call/structure graph represents the monolith. `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "final_graph.json – Complete partition graph viewable in UI".`
- **Microservices** (mandatory) — output partitions/graph represent the target microservices, and code is generated per partition. `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "Partition-specific Java source folders (e.g., monolith-web, monolith-partition0)".`

### Visualization

#### Elements
- **Granularity view** (mandatory) — individual classes are visible and draggable in the graph. `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "dragging the SnoopServlet class from the Unobserved partition to the web partition".`
- **Cluster view** — partitions shown as groups with colour coding. `https://heidloff.net/article/step-by-step-instructions-mono2micro/ — "Color-coded class groupings: Purple for suggested catalog service, green for remaining monolith, red for unassigned classes".`

#### Relations
- **Structural relationship** — class dependencies shown across partitions. `https://heidloff.net/article/step-by-step-instructions-mono2micro/ — "Dependencies: Visual representation of class relationships across partitions".`
- **Control flow** — inter-partition method calls drawn as connecting lines. `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "Business Logic view ... shows inter-partition method calls as connecting lines".`
- **Data flow** — not explicitly shown. [evidence not found]

## Refactoring

### Domain Knowledge

#### Aggregation Criteria
- **Functional** — partitioning is functionally cohesive and aligned to business use cases. `https://ar5iv.labs.arxiv.org/html/2107.09698 — "functionally cohesive partitioning of application classes" / "business use cases provide functional alignment".`
- **Adjacency** — "Natural Seams" partitioning minimises class containment dependencies / structural entanglement. `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "Natural Seams Partitioning ... such that there are minimal class containment dependencies and entanglements".`
- **Lexical** — not used (no textual/semantic similarity over tokens). [evidence not found]
- **Task / Contributor** — not used (no version/co-change). [evidence not found]

#### Expert knowledge
- **Yes** — practitioner supplies business use cases and target partition count; user can manually edit the partitioning (rename/move classes) and re-run. `https://ar5iv.labs.arxiv.org/html/2107.09698 — "Practitioners must create use cases and define the target partition count".` `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "regenerate analysis via AIPL with regen_p option using UserModifiedGraph config parameter".`

### Services Refactoring

#### Algorithms
- **Hierarchical clustering** — iterative agglomerative merging on a similarity matrix until the target cluster count is reached. `https://ar5iv.labs.arxiv.org/html/2107.09698 — "Hierarchical clustering on the similarity matrix ... iteratively merges clusters with highest similarity until reaching n partitions."`
- Community detection / K-means / FCA / genetic / Hungarian — not used. [evidence not found]

#### Manual Editing
- **Transfer of elements between clusters** — drag-and-drop classes between partitions. `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "Move the IncrementAction class from partition2 to partition0 by dragging".`
- **Merge of clusters** — not an explicit operation (achieved indirectly via moving all classes / re-running with fewer partitions). Unclear. [evidence not found]
  - Does not count as a merge operation because the user cannot explicitly merge two clusters
- **Splitting of clusters** — not an explicit operation; cluster count is set before analysis. Unclear. [evidence not found]
  - Feature not present

### Functionality Refactoring
- **Code generation (not in model)** — Cardinal generates proxy/service/utility/dummy classes to realise the partitions; this is closest to a refactoring post-step but no Asynchronization/Granularity-refinement leaf matches it. `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "Generated classes by category: Proxy classes (for remote calls between partitions), Service classes (REST API interfaces)".` (See Model Gap Candidates.)
- **Asynchronization / Granularity refinement** — not provided. [evidence not found]

## Quality Assessment

### Metrics

#### Single Decomposition
- **Coupling** — ICP (Inter-Call Percentage). `https://ar5iv.labs.arxiv.org/html/2107.09698 — "ICP (Inter-Call Percentage): percentage of runtime calls occurring between two partitions".`
- **Cohesion / Modularity** — SM (Structural Modularity = internal cohesion minus inter-partition coupling). `https://ar5iv.labs.arxiv.org/html/2107.09698 — "SM (Structural Modularity): internal cohesion minus inter-partition coupling".`
- **Elements size** (mandatory) — NED (Non-Extreme Distribution) measures partition size evenness; IFN counts interfaces per microservice. `https://ar5iv.labs.arxiv.org/html/2107.09698 — "NED (Non-Extreme Distribution): measure of even partition sizing" / "IFN (Interface Number): count of interfaces per microservice".`
- **Complexity / Team size** — not computed. [evidence not found]
- Domain-specific **BCP (Business Context Purity)** — has no model counterpart. `https://ar5iv.labs.arxiv.org/html/2107.09698 — "BCP (Business Context Purity): average entropy of business use cases per partition".` (See Model Gap Candidates.)

#### Several Decompositions
- **MoJoFM** — not computed. [evidence not found]
- **Compare metrics** — paper benchmarks Mono2Micro against baselines via the above metrics (heatmaps of metric winners), but the shipped tool compares its own two recommendations (Business Logic vs Natural Seams) rather than reporting a comparative metric. Unclear. `https://ar5iv.labs.arxiv.org/html/2107.09698 — "Heatmaps showing metric winners across approaches".`
  - "The shipped tool's BL-vs-NS choice has no metrics at all — pure visual comparison"

### Graphical Comparison
- **Color** — partitions and unassigned classes are colour-coded in the UI. `https://heidloff.net/article/step-by-step-instructions-mono2micro/ — "Purple for suggested catalog service, green for remaining monolith, red for unassigned classes".`
- **Sizes / Distance** — not used as comparison encodings. [evidence not found]

## Open Issues
- The "Unobserved" partition flags classes never hit by test cases, surfacing incomplete coverage / dead code — a quality signal not captured by the model. `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "Classes analyzed but not detected in executed test cases; indicates incomplete test coverage or dead code".`

---

## Feature Coverage Table

| Feature | Dimension | Supported | Evidence |
|---------|-----------|-----------|----------|
| Method | Granularity | No | Methods instrumented but not the decomposition unit; `https://ar5iv.labs.arxiv.org/html/2107.09698 — "partitions of the application classes"` |
| Class | Granularity | Yes | `https://ar5iv.labs.arxiv.org/html/2107.09698 — "clustering on classes ... to recommend partitions of the application classes"` |
| Entity | Granularity | No | [evidence not found] |
| Functionality | Granularity | No | Use cases guide clustering but the unit is the class; [evidence not found] |
| Package | Granularity | No | Package relations captured but not the unit; [evidence not found] |
| API endpoint | Granularity | No | [evidence not found] |
| Source code | Repr. Collection > Source > Development | Yes | `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "Java EE monolith application source code"` |
| Database schema | Repr. Collection > Source > Development | No | [evidence not found] |
| Version history | Repr. Collection > Source > Development | No | [evidence not found] |
| Runtime log traces | Repr. Collection > Source > Runtime | Yes | `https://ar5iv.labs.arxiv.org/html/2107.09698 — "each trace t_i is generated by running a use case u_i"` |
| User interactions | Repr. Collection > Source > Runtime | Unclear | Test-driven recorded flows; `https://heidloff.net/article/step-by-step-instructions-mono2micro/ — "Users record typical application workflows using the Flicker tool"` |
| Business process model | Repr. Collection > Source > Higher-Level Models | Unclear | Business use-case labels, not a formal model; `https://ar5iv.labs.arxiv.org/html/2107.09698 — "business use cases provide functional alignment"` |
| Use case | Repr. Collection > Source > Higher-Level Models | Yes | `https://ar5iv.labs.arxiv.org/html/2107.09698 — "Practitioners must create use cases"` |
| Data flow diagram | Repr. Collection > Source > Higher-Level Models | No | [evidence not found] |
| Directly in the code | Repr. Collection > Source > Documentation | Unclear | inheritance/signatures read; `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "refTable.json capturing method signatures, class variables, and inheritance"` |
| Paper document | Repr. Collection > Source > Documentation | No | [evidence not found] |
| Digital format | Repr. Collection > Source > Documentation | No | [evidence not found] |
| Static analysis | Repr. Collection > Collection Technique | Yes | `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "symTable.json documenting class dependencies and package relationships"` |
| Dynamic analysis | Repr. Collection > Collection Technique | Yes | `https://ar5iv.labs.arxiv.org/html/2107.09698 — "entries and exits to each function ... via added probes"` |
| Version analysis | Repr. Collection > Collection Technique | No | [evidence not found] |
| Model analysis | Repr. Collection > Collection Technique | Unclear | use cases consumed as labels, not parsed models; [evidence not found] |
| External | Repr. Collection > External | No | only use cases / cluster count are human inputs; [evidence not found] |
| Inner structure | Representation > Analytical > Structure | Yes | `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "refTable.json capturing method signatures, class variables"` |
| Inheritance | Representation > Analytical > Structure | Yes | `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "... and inheritance"` |
| Association | Representation > Analytical > Structure | Yes | `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "class dependencies and package relationships"` |
| Call graph | Representation > Analytical > Behavior | Yes | `https://ar5iv.labs.arxiv.org/html/2107.09698 — "Calling-context trees (CCTs) at class level"` |
| Sequence of accesses | Representation > Analytical > Behavior | Yes | `https://ar5iv.labs.arxiv.org/html/2107.09698 — "temporal relations and co-occurrence relations among classes"` |
| Frequency | Representation > Analytical > Behavior | Unclear | call relations/patterns aggregated over traces; `https://ar5iv.labs.arxiv.org/html/2107.09698 — "Direct call relations ... Indirect call patterns (ICP)"` |
| CPU level | Representation > Analytical > Behavior | No | [evidence not found] |
| Memory level | Representation > Analytical > Behavior | No | [evidence not found] |
| Response time | Representation > Analytical > Behavior | No | [evidence not found] |
| By contributor | Representation > Analytical > Evolution | No | [evidence not found] |
| By task | Representation > Analytical > Evolution | No | [evidence not found] |
| Monolith | Representation > Type | Yes | `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "final_graph.json – Complete partition graph"` |
| Microservices | Representation > Type | Yes | `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "Partition-specific Java source folders (monolith-partition0)"` |
| Granularity view | Representation > Visualization > Elements | Yes | `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "dragging the SnoopServlet class from the Unobserved partition"` |
| Cluster view | Representation > Visualization > Elements | Yes | `https://heidloff.net/article/step-by-step-instructions-mono2micro/ — "Color-coded class groupings"` |
| Structural relationship | Representation > Visualization > Relations | Yes | `https://heidloff.net/article/step-by-step-instructions-mono2micro/ — "Visual representation of class relationships across partitions"` |
| Control flow | Representation > Visualization > Relations | Yes | `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "inter-partition method calls as connecting lines"` |
| Data flow | Representation > Visualization > Relations | No | [evidence not found] |
| Task | Refactoring > Aggregation Criteria | No | [evidence not found] |
| Contributor | Refactoring > Aggregation Criteria | No | [evidence not found] |
| Lexical | Refactoring > Aggregation Criteria | No | [evidence not found] |
| Functional | Refactoring > Aggregation Criteria | Yes | `https://ar5iv.labs.arxiv.org/html/2107.09698 — "functionally cohesive partitioning of application classes"` |
| Adjacency | Refactoring > Aggregation Criteria | Yes | `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "minimal class containment dependencies and entanglements"` |
| Expert knowledge | Refactoring > Domain Knowledge | Yes | `https://ar5iv.labs.arxiv.org/html/2107.09698 — "Practitioners must create use cases and define the target partition count"` |
| Hierarchical clustering | Refactoring > Algorithms | Yes | `https://ar5iv.labs.arxiv.org/html/2107.09698 — "iteratively merges clusters with highest similarity until reaching n partitions"` |
| Community detection | Refactoring > Algorithms | No | [evidence not found] |
| K-means++ | Refactoring > Algorithms | No | [evidence not found] |
| Formal concept analysis | Refactoring > Algorithms | No | [evidence not found] |
| Genetic algorithms | Refactoring > Algorithms | No | [evidence not found] |
| Hungarian algorithm | Refactoring > Algorithms | No | [evidence not found] |
| Merge of clusters | Refactoring > Manual Editing | Unclear | not an explicit op; [evidence not found] |
| Splitting of clusters | Refactoring > Manual Editing | Unclear | cluster count set pre-analysis; [evidence not found] |
| Transfer of elements between clusters | Refactoring > Manual Editing | Yes | `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "dragging IncrementAction class from partition2 to partition0"` |
| Asynchronization | Refactoring > Functionality Refactoring | No | [evidence not found] |
| Granularity refinement | Refactoring > Functionality Refactoring | No | [evidence not found] |
| Coupling | Quality > Single Decomposition | Yes | `https://ar5iv.labs.arxiv.org/html/2107.09698 — "ICP (Inter-Call Percentage): percentage of runtime calls occurring between two partitions"` |
| Cohesion | Quality > Single Decomposition | Yes | `https://ar5iv.labs.arxiv.org/html/2107.09698 — "SM (Structural Modularity): internal cohesion minus inter-partition coupling"` |
| Elements size | Quality > Single Decomposition | Yes | `https://ar5iv.labs.arxiv.org/html/2107.09698 — "NED (Non-Extreme Distribution): measure of even partition sizing"` |
| Complexity | Quality > Single Decomposition | No | [evidence not found] |
| Team size | Quality > Single Decomposition | No | [evidence not found] |
| MoJoFM | Quality > Several Decompositions | No | [evidence not found] |
| Compare metrics | Quality > Several Decompositions | Unclear | paper benchmarks vs baselines; tool compares its 2 recommendations; `https://ar5iv.labs.arxiv.org/html/2107.09698 — "Heatmaps showing metric winners across approaches"` |
| Color | Quality > Graphical Comparison | Yes | `https://heidloff.net/article/step-by-step-instructions-mono2micro/ — "Purple ... green ... red for unassigned classes"` |
| Sizes | Quality > Graphical Comparison | No | [evidence not found] |
| Distance between elements | Quality > Graphical Comparison | No | [evidence not found] |

---

## Observations

### Model Gap Candidates

- **Code / contract generation**
  - **Would be:** a leaf (or small group) under **Refactoring > Functionality Refactoring**, alongside Asynchronization and Granularity refinement.
  - **Evidence:** `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/ — "Cardinal ... Generates a significant portion of the code needed to realize the recommended microservices in containers"` and "Generated classes by category: Proxy classes (for remote calls between partitions), Service classes (REST API interfaces)".
  - **Rationale:** Producing runnable per-partition source (proxies, REST service interfaces, serialization) is a concrete post-decomposition transformation that several industrial tools perform and the model currently cannot represent.

- **Business Context Purity (use-case purity metric)**
  - **Would be:** a leaf under **Quality Assessment > Metrics > Single Decomposition**.
  - **Evidence:** `https://ar5iv.labs.arxiv.org/html/2107.09698 — "BCP (Business Context Purity): average entropy of business use cases per partition"`.
  - **Rationale:** A purity/entropy metric measuring how cleanly a partition maps to a single business use case is a recurring single-decomposition quality dimension not covered by Coupling/Cohesion/Size/Complexity/Team size.

- **Interface Number (service-interface count)**
  - **Would be:** a leaf under **Quality Assessment > Metrics > Single Decomposition** (or a sub-facet of "Elements size").
  - **Evidence:** `https://ar5iv.labs.arxiv.org/html/2107.09698 — "IFN (Interface Number): count of interfaces per microservice"`.
  - **Rationale:** The number of exposed interfaces per service is a distinct sizing/complexity signal from raw element count; worth distinguishing if the model wants finer service-size granularity.

### Other features outside the model

- **"Unobserved" partition** — classes never exercised by test cases are quarantined in a special partition, signalling test-coverage gaps / dead code. `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/`. Too tool-specific to be a model feature, but a notable practical artefact.
- **Dual recommendation modes (Business Logic vs Natural Seams)** — the tool offers two distinct partitioning strategies the user can choose between. This maps onto the model as two aggregation criteria (Functional vs Adjacency) rather than a new feature.
- **Per-partition containerisation / Docker packaging** — generated microservices ship as Docker containers with JAX-RS endpoints. Out of scope (deployment, not identification).

### Model Vocabulary Fit

- **Use case / Business process model vs "User interactions":** Mono2Micro's "use cases" are operator-defined labels attached to test runs, sitting between the model's *Higher-Level Models > Use case* (the label) and *Runtime > User interactions* (the recorded flow). The model treats these as separate leaves; the tool fuses them. Marked Use case = Yes, User interactions / Business process model = Unclear.
- **Frequency:** the model's Behavior > Frequency implies access/call frequency. Mono2Micro's DCR/ICR/DCP/ICP are call *relations and patterns* aggregated over traces — frequency-like but framed as similarity features, hence Unclear rather than Yes.
- **Merge/Split:** the model lists Merge and Split as manual-editing operations, but Mono2Micro fixes the cluster count up front and only supports drag-and-drop transfer, so Merge/Split have no direct UI counterpart.
- **Compare metrics:** the model's "Several Decompositions" assumes comparing multiple candidate decompositions. Mono2Micro's comparison happens in the *paper's* benchmark against baselines, while the *shipped tool* contrasts its own two recommendations — a partial fit.

### Cross-tree constraint violations

None found.
- Dynamic analysis is backed by Runtime log traces (constraint satisfied).
- Static analysis is backed by Source code (constraint satisfied).
- Hierarchical clustering is used together with Expert knowledge — allowed (the `NOT Expert knowledge` constraint only forbids Community detection and Formal concept analysis with expert knowledge, neither of which is used here).
- Functional/Adjacency aggregation backed by Call graph / Structure (constraint satisfied).

### Noteworthy design decisions

- **Spatio-temporal decomposition** is the central novelty: combining a *space* dimension (business use cases) with a *time* dimension (temporal/co-occurrence call relations) into a single similarity matrix, then hierarchically clustering. This is what lets it claim "explainable" decompositions, mapping each partition back to the use cases its classes serve.
- **Five-component pipeline** (Bluejay → Flicker → AIPL/Oriole → Cardinal → UI) cleanly separates static instrumentation, dynamic capture, ML partitioning, code generation, and human-in-the-loop editing — a strong example of a tool that spans the full identify-and-realise workflow rather than stopping at recommendations.
- **Human-in-the-loop by design:** target cluster count and business use cases are required inputs, and the UI supports editing the graph and re-running analysis (`UserModifiedGraph`/`regen_p`). The tool is explicitly *semi-automated*, not push-button.
- **Closed-source and withdrawn:** the product is no longer available from IBM, so the ESEC/FSE 2021 paper is the durable technical reference; operational details survive only in community walkthroughs and the IBM Cloud Architecture playbook.

---

## Reconciliation Log

Date: 2026-06-28
Versions compared: `9309f0a`, `6e7ce2a`, `29f7dfc`, `cc53285`, `d9b7b1c` (current on disk) + working tree

All three cited sources were re-fetched and the current on-disk table (`d9b7b1c`) was
confirmed correct on every disputed feature; **no table verdict was changed**, and the
`mono2micro_IBM.profile` was already a correct pure function of the table (all 67 leaf
colours and every group node verified — left unchanged). The non-determinism across
earlier reruns was adjudicated against the re-fetched evidence:

- Paper `https://ar5iv.labs.arxiv.org/html/2107.09698`
- Playbook `https://ibm-cloud-architecture.github.io/modernization-playbook/applications/m2m/`
- Walkthrough `https://heidloff.net/article/step-by-step-instructions-mono2micro/`

| Feature | Disputed values (versions) → Reconciled | Adjudicating evidence | Which version(s) were wrong |
|---------|------------------------------------------|-----------------------|-----------------------------|
| Use case | No (9309f0a/6e7ce2a/29f7dfc/cc53285) → **Yes** | paper: "A user can manually create such use cases by navigating through the application's UI and providing an appropriate label for each use case" | all four earlier versions (No) |
| Cohesion | No (9309f0a) → **Yes** | paper: SM (Structural Modularity) = internal cohesion; "scoh_i is computed as μᵢ/m²ᵢ" | 9309f0a (No) |
| Elements size | No (cc53285) → **Yes** | paper: "NED (Non-Extreme Distribution): measures how evenly the size of a microservice is" | cc53285 (No) |
| Microservices | No (9309f0a/6e7ce2a/29f7dfc) → **Yes** | playbook: per-partition source folders + Cardinal "generates a significant portion of the code"; "monolith-partition0" | 9309f0a/6e7ce2a/29f7dfc (No) |
| Color | Unclear (all earlier) → **Yes** | walkthrough: "purple … green … red for unassigned classes" (explicit colour-coded groupings) | 9309f0a/6e7ce2a/29f7dfc/cc53285 (Unclear) |
| Frequency | Yes (6e7ce2a/29f7dfc) / No (cc53285) → **Unclear** | paper: DCR/ICR/DCP are use-case intersection/union ratios (frequency-like, not performance counters) | 6e7ce2a/29f7dfc (Yes), cc53285 (No) |
| Method | Unclear (9309f0a/cc53285) → **No** | paper: "partitions of the application classes" — methods instrumented only to build class relations | 9309f0a/cc53285 (Unclear) |
| Expert knowledge | Unclear (6e7ce2a/29f7dfc) → **Yes** | playbook: UserModifiedGraph/regen_p + paper: practitioner creates use cases and sets target partition count | 6e7ce2a/29f7dfc (Unclear) |

Features still genuinely Unclear after adjudication: **User interactions** (recorded
test-driven Flicker flows vs. captured end-user sessions), **Business process model**
(use-case labels on traces, not a formal model), **Directly in the code** (inheritance/
signatures read into refTable), **Model analysis** (use cases consumed as labels, not
parsed models), **Frequency** (similarity ratios, not performance counters), **Merge of
clusters** / **Splitting of clusters** (no explicit UI op; cluster count fixed up front),
**Compare metrics** (baseline benchmark is the paper's, not the shipped tool's).

Cross-tree constraint check: none violated. Hierarchical clustering is used with Expert
knowledge — allowed, since the `NOT Expert knowledge` constraint only binds Community
detection and Formal concept analysis, neither of which is used. Static/Dynamic analysis
are each backed by their required sources (Source code / Runtime log traces).


### Profile fix (2026-06-28) — AND "fully satisfied" propagation rule

**Profile-only change; no analysis content was reviewed or altered in this pass.** A
cross-cutting correction to the group-propagation rule (made explicit in `codebase-map`,
`docs-map`, `verify-analysis`) was applied to `mono2micro_IBM.profile`: an AND node is only
`Dark_Green` ("Group: fully satisfied") when every **mandatory** child is fully
satisfied — a present **leaf** counts (`Light_Green` is a leaf's max; leaves are never
`Dark_Green`), but a mandatory child **group** that is only `Light_Green` (partially
satisfied) caps the AND parent at `Light_Green`. The previous derivation treated a merely
*present* mandatory child group as enough for `Dark_Green`, overstating coverage.

AND cells changed `Dark_Green` → `Light_Green` in `mono2micro_IBM.profile`: `Collector`, `Visualization`, `Representation`, `Domain Knowledge`, `Services Refactoring`, `Refactoring`, `Quality Assessment`, `Microservices Decomposition and Refactoring (root)`. (Nodes
already at a higher-priority colour — `Red`/`Orange`/`Magenta` — were unaffected; AND
nodes whose mandatory child is a present leaf, e.g. `Type`, correctly stay `Dark_Green`.)