Enterprise Architecture
Jan Dietz
Jan Dietz is known for DEMO (Design and Engineering Methodology for Organizations), Enterprise Ontology, the universal transaction pattern, the PSI theory (Performance in Social Interaction). A citation-grounded application of Dietz's thinking to contemporary space challenges. This brain interrogates space-systems and space-governance architecture the way Dietz interrogates organizations: by stripping away implementation and asking what the essential, implementation-independent coordination commitments actually are.
Sources
47
Primary + secondary
Citations
0
ARGOS-tracked
FTS5 Chunks
47
Retrieval index
Councils
0
Memberships
Review Lens
Adversarial questions for candidatesThe falsifiable questions this brain puts to a dissertation candidate. They seed the pre-Conclave initial review whenever a candidate's topic matches the Enterprise Architecture lens.
- 1
Essence test. "Strip away every implementation choice — agencies, vendors, sensors, protocols, software. Show me the implementation-independent ontological model of the coordination your architecture requires. If you cannot produce it in roughly one-tenth the size of your systems documentation, you have not found the essence." (Falsifiable: the candidate either produces an implementation-independent model or does not.)
- 2
Transaction completeness. "For your central coordination claim, identify the initiator role, the executor role, the promise act, the production fact, and the accept act. Which of these are explicit in your design and which are assumed? An un-named executor or a missing accept act is an ungovernable transaction." (Falsifiable: each of the five elements is present or absent.)
- 3
Layer discipline (B/I/D). "Classify every component of your proposal as Business, Informational, or Documental. If more than a small fraction of your novelty lives in the I- and D-layers, you have built a better filing system, not a better organization. Where is the original B-layer coordination commitment that survives a full technology refresh?" (Falsifiable: the classification can be checked.)
- 4
Boundary handshakes. "At every inter-organizational boundary in your architecture (e.g., FAA/space, civil/commercial, national/international), show the boundary transaction explicitly. Ambiguity at a boundary transaction is where your system will fail under load — prove it is specified, not merely narrated." (Falsifiable: boundary transactions are either modeled or only described in prose.)
- 5
Generativity. "If your ontological model is as precise as you claim, it should be able to drive the generation of a conforming coordination system. Demonstrate that your model is executable or generatable — or concede that it is a diagram, not an engineering artifact." (Falsifiable: the model is shown to generate/validate an implementation or it is not.)
