COLLEGIUMInstitutional Wisdom for the Space Age

Hall of Shoulders

Enterprise Architecture

Steven Spewak

Steven Spewak is known for Enterprise Architecture Planning (EAP); the data-driven, business-driven layered architecture (business model -> data -> applications -> technology); the EAP "Wedding Cake" methodology and the data-before-applications sequencing principle. Adversarial reviewer-brain for space-policy, space-systems-architecture, and data-governance dissertations

Built

Sources

59

Primary + secondary

Citations

0

ARGOS-tracked

FTS5 Chunks

59

Retrieval index

Councils

0

Memberships

Core Concepts & Space Translation

The four-layer, business-driven architecture (the EAP stack)

An enterprise is described by four architectures defined in a strict dependency order: (1) the *business model* (functions and the information they need), then the three blueprints - (2) *data architecture*, (3) *applications architecture*, and (4) *technology architecture*. Each layer is justified only by the layer above it; technology exists to run applications, applications exist to manage data, and data exists to serve the business. This layered, business-first decomposition is the spine of EAP and is reproduced in the EAP-method literature applied to real organizations (the University EAP/Zachman application, Setiawan & Setiyadi 2019, 10.5430/ijhe.v8n3p13; the HICSS EAP requirements analysis, Beese et al. 2017, 10.24251/hicss.2017.589).

Space translation

See Space Applications below for how this framework translates to contemporary space governance, drawn directly from the dossier's applied-literature review.

Data before applications (the EAP sequencing rule)

Spewak's most distinctive and falsifiable claim is that the *data architecture must be defined before the applications architecture*, which must be defined before technology. Data is the most stable enterprise asset; processes and technologies churn around it. Designing applications first - the common practice - produces stovepipes that each re-define the same data, the root cause of non-interoperability. The "stable data, volatile process" premise underlies all data-stewardship frameworks that followed; its modern restatement is the FAIR principle that data should be Findable, Accessible, Interoperable, and Reusable *independent of any application* (Wilkinson et al. 2016, 10.1038/sdata.2016.18).

Space translation

See Space Applications below for how this framework translates to contemporary space governance, drawn directly from the dossier's applied-literature review.

The current architecture / target architecture / migration plan triad

EAP is explicitly a *planning* method: it requires documenting the *baseline* (current systems and data), defining the *target* (the four blueprints), and producing a *migration plan* that sequences the transition with priorities, dependencies, and a cost/benefit case. Architecture without a migration plan is, for Spewak, a wish list. This baseline->target->transition structure is the operational core later generalized into federal EA frameworks and the practice literature (Beese et al. 2017, 10.24251/hicss.2017.589; the EA-value analysis of Tamm et al. 2011, 10.17705/1cais.02810).

Space translation

See Space Applications below for how this framework translates to contemporary space governance, drawn directly from the dossier's applied-literature review.

Architecture defines what the enterprise should be, not what it is

Spewak insists the architecture is normative and outcome-oriented: it is a blueprint for a desired future state derived from business need, not a documentation exercise of the present. The discipline's payoff is realized only when the blueprint drives investment decisions - what to build, buy, retire, and integrate. The empirical EA-value literature tests exactly this claim, finding that EA delivers benefits only when it actually shapes decisions and is governed, not merely drawn (Tamm et al. 2011, 10.17705/1cais.02810; Lange/Mendling exploration of EA research, 2013, 10.17705/1cais.03201).

Space translation

See Space Applications below for how this framework translates to contemporary space governance, drawn directly from the dossier's applied-literature review.

The shared data resource (enterprise-wide data definition)

Because data is defined once for the whole enterprise and shared across applications, EAP requires an enterprise data model that is *custodian-neutral*: the definition of an entity does not belong to the application that happens to create it. This is the architectural precondition for interoperability and the conceptual ancestor of common data models and federated data governance (Wilkinson et al. 2016, 10.1038/sdata.2016.18; the JSpOC Mission System Common Data Model work, Holzinger et al. AMOS 2012, AMOS brain).

Space translation

See Space Applications below for how this framework translates to contemporary space governance, drawn directly from the dossier's applied-literature review.

EAP as a managed, governed program (planning is continuous, not a one-shot)

Spewak frames EAP as a program with phases, deliverables, stewardship roles, and a feedback loop; the architecture is maintained, not finished. The maturity of the method depends on organizational governance - sponsorship, data stewardship, and a unit that owns the blueprint and the migration plan. The modern process literature restates EAP precisely as a *continuous transformation process* rather than a document (the Industry-4.0 EAP-process work, Gampfer et al. 2019, 10.5220/0007680005720579; Beese et al. 2017, 10.24251/hicss.2017.589).

Space translation

See Space Applications below for how this framework translates to contemporary space governance, drawn directly from the dossier's applied-literature review.

Space Applications

Challenge 1: SSA/SDA data sharing as applications built before a data architecture: Space situational awareness is, in Spewak's terms, a textbook case of the EAP sequence run backwards (F2). The field has built application after application - sensor networks, screening services, catalogs - each defining "a tracked object and its provenance" in its own terms, which is exactly the stovepipe pathology EAP predicts when applications precede the data layer. The Joint Space Operations Center Mission System (JMS) Common Data Model is the clearest counter-move: it is an explicit attempt to define the shared data resource (F5) so that situational-awareness data is interoperable across systems rather than re-defined per application (Holzinger et al., "JSpOC Mission System (JMS) Common Data Model Foundation for Interoperable Data Sharing for Space Situational Awareness," AMOS 2012; AMOS brain). The recurring "SSA architecture vision" papers (Space Situational Awareness Architecture Vision, AMOS 2013; A Simulation and Modeling Framework for SSA, AMOS 2008; AMOS brain) are, read through EAP, repeated attempts to define a *target* architecture without ever stabilizing the *data* architecture beneath it - which is why each vision is reinvented. ACTA's orbit-information-sharing work (Orbit information of predetermined accuracy and its sharing in the SSA context, 2019, 10.1016/j.actaastro.2019.01.027) is precisely an attempt to make the data primitive - an orbit and its accuracy - shareable independent of the application that produced it, i.e., the FAIR/EAP move toward a custodian-neutral data definition (Wilkinson et al. 2016, 10.1038/sdata.2016.18). A Spewak reviewer would not ask "which SSA system is best"; he would ask whether the shared data resource was defined before any of them, and would treat the catalog's missing enterprise data model as the cause of every downstream integration cost.
Challenge 2: Space traffic management as a target architecture with no baseline and no migration plan: STM discourse is rich in target visions and thin in EAP's other two legs: a documented baseline and a migration plan (F3). The space-governance literature describes the desired coordination end-state - Oltrogge and Christensen survey the fragmented institutional landscape and the need for coordinated governance in the new-space era (2020, 10.1016/j.jsse.2020.06.003) - but the field rarely produces the baseline inventory of *who currently holds which data and authority* or a sequenced transition with priorities and dependencies. ACTA's space-capacity-management analysis is one of the few works that connects current capacity to the STM target, i.e., that begins to supply a migration-relevant baseline (Space capacity management and its interaction with space traffic management, 2025, 10.1016/j.actaastro.2025.01.069). The cislunar STM literature extends the gap into a volume with neither a data baseline nor a shared reference model (Moon to Mars: challenges and strategic frameworks for STM in cislunar and cismartian environments, 2025, 10.1016/j.actaastro.2024.12.056). A Spewak reviewer would credit STM proposals for articulating the target (F4) but would refuse to evaluate a target architecture presented without the baseline it transitions from or the migration plan that gets there - for Spewak, that is a wish list, not a plan.
Challenge 3: Mega-constellations and orbital debris as a missing enterprise data model for a shared commons: The constellation-debris problem is what EAP predicts when a shared data resource (F5) is never defined for a commonly used asset. Venkatesan et al. frame orbit as an "ancestral global commons" (2020, 10.1038/s41550-020-01238-3) - in EAP terms, a shared enterprise asset that, by F5, demands a single, custodian-neutral definition of the "object in orbit" and its footprint, held once for the whole enterprise. Instead each operator architects its own constellation as a stovepipe application, and the aggregate effect is unmanaged: exploratory analyses link large constellations directly to strategic mismanagement of the space commons (Bernhard et al., Large satellite constellations and space debris: exploratory analysis of strategic management of the space commons, 2022, 10.1016/j.ejor.2022.04.030), and the economic literature shows that uncoordinated competition between constellations actively reduces welfare from orbit use (Guyot et al., Oligopoly competition between satellite constellations will reduce economic welfare from orbit use, 2023, 10.1073/pnas.2221343120). Wilson and Vasile name the macro-symptom a "space sustainability paradox" (2023, 10.1016/j.jclepro.2023.138869), and the regulation-gap literature shows intent outrunning implementation (Martin-Lawson et al., The cost of (un)regulation, 2023, 10.1016/j.jenvman.2023.119382; OECD/Undseth, Space sustainability, 2020, 10.1787/a339de43-en). Spewak's diagnosis is sharper than "we need regulation": the commons has no enterprise data architecture, so there is no shared definition of the thing being depleted, and therefore no migration plan can even be written. The architectural prerequisite for governing the commons is the one EAP supplies - define the data resource for the whole enterprise first.
Challenge 4: Space sustainability ratings and in-space-servicing supervision as decision-driven architecture done right: Two recent efforts are, in EAP terms, the field's most method-literate moves because they tie architecture to *decisions* (F4) and begin from a shared data definition (F5). The Space Sustainability Rating is explicitly designed as a composite indicator whose purpose is to drive operator behavior - architecture that exists to shape investment and operational decisions, exactly Spewak's test that a blueprint earns its keep only by driving decisions (Rathnasabapathy et al., Space sustainability rating, 2025, 10.1016/j.actaastro.2025.03.034; Fostering multi-stakeholder collaboration for space sustainability, 2025, 10.1016/j.actaastro.2025.06.029). The in-space-servicing decision-support work is even more directly EAP-shaped: it *architects a decision support system* for continuing supervision, i.e., it defines the applications and data architecture required to make a recurring regulatory decision, rather than treating supervision as an ad hoc process (Architecting a decision support system for continuing supervision of commercial in-space servicing, 2025, 10.1016/j.actaastro.2025.05.036). A Spewak reviewer would credit both for putting decisions and data first, but would interrogate F2: does the rating keep its data definitions stable and shared, or does each rated operator supply data in its own application-specific schema, re-introducing the stovepipe at the input layer? The empirical EA-value literature warns that an architecture undelivers exactly when it is drawn but not governed into decisions (Tamm et al. 2011, 10.17705/1cais.02810).
Challenge 5: Launch cadence and capacity as a migration problem nobody has sequenced: Rising launch cadence is, in EAP terms, a migration-plan problem (F3): the current state (pads, ranges, slots, licensing systems) is sprawling and siloed, the desired target (deconflicted, high-cadence operations) is articulated, but no one has produced the sequenced, prioritized, dependency-aware transition that EAP demands between them. ACTA's capacity-management/STM-interaction analysis supplies the kind of baseline data a migration plan would consume (2025, 10.1016/j.actaastro.2025.01.069), and the LEO-impact literature quantifies the operational pressure the transition must absorb (Evaluating the impact of space activities in low Earth orbit, 2021, 10.1016/j.actaastro.2021.03.030). Spewak's contribution here is procedural precision: the launch-cadence "crisis" is not a shortage of infrastructure, it is the absence of an enterprise migration plan in which licensing, range, airspace, and orbital-slot architectures are sequenced together from a shared data baseline - and absent that plan, each authority optimizes its own application and the aggregate transition never converges.
Synthesis: Across all five challenges the same EAP inversion recurs: the space enterprise builds *applications* (catalogs, constellations, screening services, licenses) before it defines a *shared data architecture*, and it produces *target visions* (STM regimes, sustainability goals, cislunar concepts) without the *baseline* and *migration plan* that turn a vision into a program. The governance literature reaches the conclusions empirically - Oltrogge & Christensen (2020) on fragmented authority, Venkatesan et al. (2020) on the un-defined commons, Guyot et al. (2023) on uncoordinated competition, Wilson & Vasile (2023) on the paradox - but lacks the method-vocabulary to say *what to do first*. Spewak supplies it: architect the data before the applications, define the shared resource once for the whole enterprise, and never present a target without the baseline and the migration plan that reach it. Where Zachman would audit which descriptive cells are empty, Spewak audits *the order of operations* - and finds the space enterprise building the cake from the top down. The contribution of an EAP lens to space policy is therefore not another rating, treaty, or vision but a sequence: data first, shared definitions, baseline, target, migration plan, governed into decisions. ---

Council Memberships

No active memberships.

Brain Record

Brain ID: hos-spewak
FTS5 path: brains/spewak/spewak.db
Corpus: Full corpus + dossier
Last indexed: 2026-06-14

Query this brain

search_brain.py --brain spewak "<query>"

Open BrainTrust entry