EA & Ontology: Why Tools Fail — Misapplication vs. Inherent Flaws

Introduction

A previous article on enterprise architecture and ontology received a reader comment with two core viewpoints worth analyzing.

1. If ontology has no essential difference from existing form templates and circulation processes, why build another ontology? Business cannot understand, technical staff cannot use, typical redundant construction. 2. The EA ADM method itself has defects, placing quality and improvement momentum entirely on expert group members, basically lacking implementability. Slightly traditional enterprises have weak expert forces; even leading enterprises struggle to assemble triple-talent who understand technology, business, and finance. Frankly, leading enterprise systems are piled with money and ground out through repeated friction; moving them to traditional enterprises results in total culture shock, lacking even standards to judge solution correctness.

The comment can be summarized into two core viewpoints:

If new ontology differs not from existing form templates and circulation flows, it is invalid redundant construction that business cannot understand and technical staff cannot use.

EA ADM method has inherent defects, over-depends on scarce cross-domain triple experts, lacks landability; leading enterprise solutions piled with money and friction are totally unsuited for traditional enterprises.

Both viewpoints capture the most universal pain points in Chinese manufacturing digitalization landing, with strong realistic feel, but both confuse "tool landing method" with "theory's own value" . They equate landing failure cases with theory invalidity, while narrowing the target positioning of ontology and TOGAF ADM.

Viewpoint 1: Ontology Equals Existing Forms and Process Templates

Valid Pain Points (Real, Widely Existing)

1. Many ontology projects indeed degenerate into redundant construction

Many implementers directly copy form fields and process forms "translated into ontology", merely storing Excel or ERP forms in another form, without extracting concepts or eliminating ambiguities. At this point ontology is just an extra redundant model; business cannot read, developers directly use database tables, completely idle — typical "trend-chasing ontology". Many ontology projects eventually become ornaments, an undisputed fact.

2. Ontology naturally has comprehension thresholds

Business personnel are used to forms, processes, policy texts; ontology uses formal language of classes, properties, relationships, axioms. Without a translation layer and lightweight transformation, "two skins" inevitably form.

Key Correction (Most Critical Divergence)

Forms/process templates = oriented to "operation instances"; Ontology = oriented to "conceptual semantic consensus" — completely different goal levels, no substitution relationship.

1. Form templates : answer "which fields a form fills, how process flows", serve single business scenario, full of same-meaning-different-names and same-name-different-meanings.

Example: "Supplier" in purchase order, "Collaborative Manufacturer" in outsourcing order, "Supplier" in finance ledger — three sets of fields at form level, hard to auto-connect.

2. Enterprise ontology : oriented to global semantic consensus , defines unified concepts, relationship constraints , identifies "Supplier = Collaborative Manufacturer = Supplier", establishes global semantic standard to eliminate cross-system, cross-division concept ambiguities.

Ontology then provides the semantic foundation for master data governance, cross-domain data fusion, knowledge graph construction.

Simple Scenario Distinction

Single system, single process optimization: only need form templates, process norms, completely no need for ontology .

Multi-system integration, master data governance, cross-division data connection, business rule automation, knowledge graph, data asset catalog: without ontology only point-to-point interface piling, long-term silos.

Thus conclusion is clear: single-process standardization, local system optimization completely do not need heavy ontology modeling. Only when enterprise faces multi-system silo breakthrough, global master data governance, data assetization construction does ontology value release. Biggest trap of ontology projects: forcing launch without scenario distinction, only modeling not landing, lacking business-oriented lightweight views and executable mapping rules.

When the Reader's Viewpoint Holds Completely

Project goal only to sort existing processes, standardize existing forms, yet forcibly introduce heavy ontology modeling; only model, no landing mapping rules, no master data connection, no business-understandable views.

But this does not mean ontology useless, only scenario mismatch + implementation method error .

Corrected Rational Expression

In scenarios only needing form and process standardization, no need to introduce heavy ontology modeling. If conducting cross-domain data fusion, master data governance, ontology has irreplaceable value. But ontology projects must accompany lightweight business views, establish ontology→form/master data mapping relationships. Pure replication of form fields into ontology modeling is invalid redundant construction.

Viewpoint 2: TOGAF ADM Relies on Experts, High Landing Difficulty, Culture Shock

Original: EA ADM method itself has defects, placing quality and improvement momentum on expert group members, basically lacking implementability. Slightly traditional enterprises have weak expert forces; even leading enterprises struggle to assemble triple-talent understanding technology, business, finance. Frankly, leading enterprise systems are piled with money and ground out through repeated friction; moving them to traditional enterprises results in total culture shock, lacking even standards to judge solution correctness.

Agreed Points (Manufacturing CIO Consensus)

1. Original TOGAF ADM ideal model highly dependent on composite architects

Standard ADM paradigm: Business Architecture → Information Architecture → Application Architecture → Technology Architecture, closed-loop iteration. Ideal state needs cross-business, IT, finance, governance composite expert teams. Small/medium manufacturing, traditional entities generally lack such talent.

2. Head enterprise success path not directly replicable

Large groups have budget, ample talent, long trial-error cycles, rely on continuous investment to grind out systems; traditional enterprises tight budget, small trial space, large org change resistance, directly copying head EA solutions extremely easy to fail.

3. Native ADM lacks "solution evaluation quantitative standards"

TOGAF emphasizes process framework, lacks supporting KPIs, landing acceptance rulers. Many enterprises do EA finally producing pile of architecture documents, cannot measure architecture quality, fall into "document engineering".

Three Key Logical Flaws

1. Confusion: ADM framework itself flawed VS original ADM unsuitable for SMEs

TOGAF ADM is a general process framework , not a fixed solution. It never mandated must assemble top-tier triple experts. The viewpoint confuses a key fact: ADM is a tailorable process framework , not a fixed implementation template. Industry mature practice: SMEs need not execute full ADM cycle, can trim, lightweight landing .

Head enterprises: full ADM lifecycle, full four-layer architecture modeling.

Traditional manufacturing enterprises: only trim [Business Architecture + Application Architecture], weaken heavy technical architecture, prioritize solving system integration, master data pain points, no need for full-team top experts.

2. Fallacy: "Lack composite experts → EA method not implementable"

EA does not necessarily rely on few omnipotent experts. Mature landing mode is domain-expert collaboration : business experts, finance experts, IT experts divide labor, architect responsible for aligning consensus, no need one person master all domains. The viewpoint presets "must single person triple-capable", a narrowing and partial understanding of EA implementation org model.

3. Causality inversion: Head enterprises pile money = EA no value

Head enterprises massive funds, manpower grinding systems, precisely many are unconsciously doing architecture governance, just not wrapped in EA terminology . "Piling money without architecture thinking" final result is massive silos, duplicate investment, interface proliferation.

Traditional enterprise culture shock mostly two reasons: ① directly copying head full heavy EA solution, no trimming adaptation to own scale; ② equating EA with one-time architecture document output, not incorporating architecture into continuous governance process.

Correct Way for Traditional Enterprises

Lightweight trim ADM cycle: prioritize focus on business architecture and application architecture, weaken heavy technical architecture design, target urgent pain points like system integration, master data combing.

Root cause of many EA project failures not framework defect, but mechanical copying head enterprise full solution, equating architecture work with document output, no continuous architecture governance mechanism, lack quantitative evaluation ruler for architecture decisions.

Head enterprises continuously investing in systems essentially unconsciously conducting architecture governance; blind investment without architecture thinking only breeds new information silos.

Most Rational Corrected Expression

Standard TOGAF ADM full version demands high enterprise talent maturity, direct copying extremely easy culture shock; traditional enterprises hard to assemble omnipotent architecture experts. Therefore cannot mechanically apply full ADM, must trim architecture implementation path based on enterprise scale, establish layered expert collaboration mechanism, and accompany architecture decision evaluation standards. Head enterprise informationization results relying on funds and long-term grinding cannot be directly copied. Architecture framework value lies in reducing blind trial-error, not directly applying finished solutions.

Final Summary

1. Value of Two Viewpoints: Effective Warning Against "Theory Tool Abuse"

Current digitalization field prevalent theory-first, scenario-detached phenomenon: blindly launch ontology modeling, copy TOGAF full EA process, only produce documents, not solve business pain points. Thus these two viewpoints very suitable for preventing formalistic digitalization .

2. Core Boundary Consensus (Team Unified Cognition)

Ontology: not all projects need . Single process standardization don't force; cross-domain data governance, master data, knowledge asset scenarios worth investment, and must eliminate pure form-replication invalid modeling, accompany business-visualized mapping.

TOGAF ADM: don't dogmatic full-process landing . It's a framework toolbox, not standard answer. Traditional manufacturing enterprises prioritize lightweight trimming, abandon pursuit of "omnipotent experts", switch to domain-expert collaboration mode; simultaneously must accompany architecture decision standards, avoid architecture becoming paper documents.

3. Beware Other Extreme: Don't Deny Theory Because of Landing Chaos

Many see massive failed ontology, EA projects, directly conclude "ontology useless, TOGAF useless". Real conclusion should be: Theory itself no right/wrong, wrong is no trimming, detached from business scenarios, only heavy modeling not heavy landing implementation ways .

Action Guidelines

First, reject "trend-following use" of theory tools. Don't introduce ontology, EA for concept trendiness; all models, frameworks must match business demands. Problems solvable by forms, process norms, absolutely not introduce heavy modeling tools.

Second, distinguish "tool itself" and "wrong implementation way". Massive failure cases, problem lies in implementation path, scenario mismatch, not theory itself failure. Whether ontology or EA framework, core value is reducing trial-error cost, not grab-and-use standard answers.

Also, digital transformation most need vigilance against two extremes: blindly worship frontier theories, pile model documents, fall into formalism; or witness landing chaos, completely deny all architecture methodologies, rely on experience barbaric construction. Find tool applicability boundaries, tailor methods to local conditions, is the long-term viable path for entity enterprise architecture construction.

Two Core Insights: Don't blindly follow new theories, nor deny methodologies because of implementation chaos. Tools have no good/bad, key is scenario fit, landing path matches enterprise own reality.