Living Master System Index (MSI)

Automated Inventory, Confidence Scoring & Stewardship Loops #

---

1 Purpose #

Every enterprise claims to have a “single source of truth.”
In practice, they have several — all arguing.
The Master System Index (MSI) is EA 2.0’s way of ending the argument.

It is a continuously updated, self-healing catalog of every business capability, application, data store, integration, and owner — the beating heart of the architecture graph.

---

2 Why Traditional Inventories Fail #

Pain Point	Description
Manual syncs	Periodic spreadsheet uploads create drift within weeks.
Siloed ownership	Different domains (IT, security, data) maintain separate lists.
No feedback loop	Once entered, information dies — no update path.
Lack of trust score	Users can’t tell which entries are reliable.

The MSI fixes this by combining graph linkage + confidence analytics + stewardship automation.

---

3 Conceptual Model #

[Source Systems]  →  [Integration & ETL]  →  [Graph Nodes]  
                                  ↓  
                         [MSI Table / View]  
                                  ↓  
                     [Confidence + Stewardship]

The MSI is not a separate database; it’s a semantic view over all nodes in the graph, enriched with metadata from their sources.

---

4 Core Attributes of Each MSI Record #

Field	Description	Example
system_id	Canonical identifier	APP-0235
name	Human-friendly name	Payroll Suite
domain	Capability / Business Area	Finance
owner	Person or team responsible	anita.m@org
source_systems	Feeds that report this record	CMDB, Jira
confidence_score	0–100 % data completeness	87 %
last_seen_at	Last update timestamp	2025-10-28
status	Active / Pending Validation / Retired	Active
sensitivity	Public / Confidential / Restricted	Confidential

---

5 Building the MSI Automatically #

EA 2.0 populates the MSI through pipelines:

CREATE VIEW master_system_index AS
SELECT
  coalesce(cmdb.app_id, jira.project_key, cloud.app_tag) AS system_id,
  max(name) AS name,
  array_agg(DISTINCT source) AS source_systems,
  count(source) * 20 AS confidence_score,
  max(last_seen_at) AS last_seen_at
FROM ingested_nodes
GROUP BY system_id;

This automatically merges duplicate records and assigns a confidence score based on source redundancy.

---

6 Confidence Scoring Logic #

Signal	Weight	Meaning
Found in CMDB	+40	Official asset record
Found in Cloud Inventory	+20	Deployed and running
Found in ServiceNow Incidents	+10	Operationally active
Linked to Owner in HR Feed	+15	Accountable person exists
Updated in last 30 days	+15	Recently validated

Score = sum of weights for active signals
Confidence bands: 0-49 Low • 50-79 Medium • 80-100 High

---

7 Visualizing Confidence #

The MSI Dashboard highlights:

• Confidence heat map by domain
• “Single-source” vs. “multi-source” records
• Trend of coverage over time
• Orphaned systems with no owner

Example Power BI card:

“78 % of Applications have ≥ 3 independent sources.”

---

8 Self-Healing Loops #

Every low-confidence record generates a feedback event:

Trigger	Automated Action
Missing Owner	Create ServiceNow task “Assign Application Owner.”
Last seen > 60 days	Ping source systems to re-validate.
Duplicate Detected	Merge nodes & preserve lineage.
Low score < 50	Flag to steward for manual review.

Results feed back into the graph — closing the loop.

---

9 Stewardship Workflow #

1. Trigger – Rule engine detects anomaly.
2. Ticket – ServiceNow GRC task assigned to owner.
3. Response – Steward confirms or edits record.
4. Re-ingest – API updates graph node.
5. Audit Trail – Every change logged with user & timestamp.

No manual Excel needed; stewardship is a living process.

---

10 Handling Multiple Sources of Truth #

EA 2.0 uses Source Confidence Hierarchy — a set of priority rules:

Rank	Source	When Trusted
1	CMDB / ERP	Asset IDs and official names
2	Cloud Inventory	Runtime status and region
3	Jira / ADO	Project linkages and teams
4	Manual Upload	Fallback for missing records
5	Discovery Scan	Temporary evidence only

Highest-confidence source wins; lower ones serve as evidence.

---

11 AI-Assisted Inference #

Machine learning models in the Reasoning Layer suggest:

• probable owners based on past patterns, emails in commits, or ticket assignees;
• system duplications via fuzzy matching (Levenshtein distance > 0.8);
• life-cycle state predictions (active, sunset, retire candidate).

This reduces human review load by > 60 %.

---

12 Auditing and Traceability #

Each MSI record keeps lineage:

MSI Node  
  ├── Sources[]  
  ├── Confidence score history  
  ├── Steward actions (logs)  
  └── AI recommendations

Dashboards show who last validated what and why.

---

13 KPIs for Inventory Health #

KPI	Definition	Target
Confidence ≥ 80 % coverage	% of systems with score ≥ 80	≥ 90 %
Stale records (> 90 days)	Count of outdated entries	≤ 5 %
Duplicate ratio	Duplicates / total records	≤ 1 %
Steward SLA closure time	Avg time to validate low-confidence record	< 7 days
Automated validation rate	% of records self-healed	≥ 60 %

---

14 Governance Model #

• Data Stewards own accuracy and validation.
• EA Ops own pipeline and automation.
• Governance Board reviews monthly KPIs.
• AI Auditor reports bias or systematic gaps.

Clear roles prevent MSI from becoming a “no one’s job” asset.

---

15 Security and Compliance #

• MSI runs inside tenant; no public exposure.
• Every record inherits sensitivity label from its most restricted source.
• All API access authenticated via Entra ID service principals.
• Audit logs immutable (Write-Once Storage policy).

---

16 Value to the Enterprise #

• Trust: Executives see a score for every system’s data quality.
• Speed: Architects query a live index instead of chasing owners.
• Savings: De-duplicates licenses and retired assets.
• Compliance: Supports SOX / NIST control objectives.

---

💡 Takeaway #

The Living MSI is the memory of the enterprise.
It remembers every system, judges its truth, and asks for help only when human judgment is needed.
That is how EA 2.0 stays alive — accurate by design, not by audit.