Stop Drawing Architecture, Start Committing It: The New PRISM EA Framework
by Vikram Palakurthi
PRISM Treats Enterprise Architecture Like Code, Not Like a Deliverable
When a stakeholder asks for a diagram or a diagram needs to be created as part of compliance, the architect draws it in Visio or a SaaS whiteboard tool. It lives behind a login or on a shared drive, which means someone has to provision access, and what usually gets circulated instead is a PDF or an image export. A few months pass. Half of what it describes has changed, but the diagram hasn’t. Someone eventually asks for “the current architecture,” and what they get back is a stale file, or a series of meetings scheduled just to update the current state.
If you are reading this, you have already lived some version of that story. In reality, it is not really a tooling problem but a philosophical one. For a long time, we have treated architecture as documentation when we should have treated it as source, and it is time we rethink how we operate.
This article introduces PRISM, a new opinionated enterprise architecture framework built from ground up in the year 2026 around that one idea. Architecture artifacts should live as plain text, get validated against a schema, and travel through version control the same way application code does. Nobody should need a specialized tool, a certified practitioner, or a scheduled review meeting just to find out what changed and why. Make no mistake: this isn’t an argument against enterprise architecture. It’s an argument that an enterprise architect no longer needs to be a certified practitioner of one specific tool.
Why PRISM Exists
Zachman (1987) gave the field a comprehensive ontology. TOGAF (The Open Group, 2022) gave it a process and a repository model mature enough for large enterprises to run on. Credit where it’s due, and that’s the credit: two frameworks, decades of real foundational work.
What both leave open is adoption. Ross, Weill, and Robertson’s (2006) research on EA maturity found real performance gains in organizations that got architecture right, but enterprise architecture adoption outside large enterprises has stayed stubbornly low, mainly due to cost of entry, tool dependency and process overhead measured in weeks before anyone produces something useful. And a practice that is hard to start and does not connect to daily decisions will not get adopted, no matter how complete its theory is and Kotusev’s broader comparison of Zachman, FEAF, DoDAF, and TOGAF (2021) documents a consistent pattern of high adoption cost and abandonment across all four frameworks (Kotusev, 2021). This provides further context for why a lower-cost-of-entry alternative has practical motivation, independent of PRISM’s own argument for it.
PRISM is built to close that gap, not to replace either framework. However, it’s worth noting that some of the pain points discussed above have already been addressed by existing EA tools, although most of those solutions are open source. Open-source EA tools do exist, such as Archi, which I personally use but Archi and PRISM are not directly comparable, since Archi is a modeling tool for producing ArchiMate diagrams, while PRISM is a source-of-truth authoring standard i.e., they solve different problems rather than competing on the same one. But to be honest, PRISM’s existence would not have been possible without the existence of Zachman, TOGAF, and Archi.
What PRISM Actually Is
PRISM stands for its five layers. People & Place, Reality, Intent, Signal, and Movement. The name is not decorative. A prism takes one beam of light and splits it into its parts, and what comes out the other side is easier to study than the beam ever was. PRISM does the same thing to an organization. Instead of one tangled picture of “the enterprise,” you get five distinct views, each one answering a question the others cannot.
Callout — The Five Layers, Plain
People & Place — who’s involved, and where do they operate from
Reality — what the enterprise has, and how it actually runs
Intent — why it runs that way, and when decisions actually matter
Signal — how the parts talk to each other and exchange value
Movement — are people adopting this, and where is the organization headed
Five layers sounds like a simplification of Zachman’s much larger matrix, and it is one, but it’s a deliberate one. Zachman’s matrix covers who, where, what, how, why, and when. PRISM keeps all six and adds three more: risk, exchange, and the human and historical trajectory of the organization, which are the concerns that traditional EA frameworks touch on unevenly, if at all. PRISM groups the ones that are tightly coupled in practice, so People & Place covers who and where together, Reality covers what and how together, and so on. Nothing gets left out. What changes is how many separate documents you need to track it all.
Eight Rules That Actually Constrain the Design
PRISM is not just “architecture, but in YAML.” Eight design principles drive almost every decision in the spec, and they are worth naming directly because they are what separates PRISM from a stylistic preference.
Source-first. Every artifact is a plain-text file i.e., YAML for structured data, Markdown for narrative, following architecture-as-code principle. The file is the truth. There’s no proprietary model sitting behind a rendering tool that only one person in the building knows how to operate.
Git-native. Version control is not a backup here, it’s the governance engine itself. Branches represent architectural exploration. Commits represent decisions that got made. Pull requests are the review checkpoint, and git history is the audit trail. Teams that already live in git do not need to learn a new change-management process. They already know this one.
Schema-based. Every artifact validates against a published JSON Schema. That gets you structural consistency across teams and lets a CI pipeline catch a malformed artifact before it merges, the same way a broken build gets caught before it ships.
Authorable. A business analyst, a product owner, and a CIO should all be able to write a PRISM artifact, not just a certified enterprise architect. YAML reads close enough to structured prose that this actually holds up in practice.
Domain-agnostic. Nothing in PRISM assumes an IT context specifically. A “system” can be a software application, a hospital ward, or a production line. A “signal” can be a REST API, an HL7 message, or a truck leaving a loading dock. That generality is intentional, and it’s what lets PRISM work as a shared language across parts of the business that have never spoken the same architectural vocabulary.
Opinionated. Five layers, not six or twelve. Plain text, not UML. Git, not a dedicated repository nobody outside the EA team can log into. These are narrow choices on purpose. A team of three should be able to start using PRISM in an afternoon, and a CIO should be able to put it in front of a board without a translation layer in between.
Impact-aware. Every artifact records what it connects to, not just what it is. Mark a system for decommission and PRISM traces every dependent signal, process, and stakeholder tied to it, so nobody removes something without knowing what breaks downstream.
AI-inferable and authorable. A PRISM artifact is structured enough for an AI system to read, reason over, and draft, not just for a human to write. Ask a model what breaks if a system is decommissioned, or have it propose a first-pass Signal artifact from an API spec, and the schema gives it enough structure to answer without guessing at freeform prose. This is what lets PRISM tap into modern AI capability instead of sitting outside it.
Where the Real Novelty Sits
Apart from the core rules and constraints stated above, most of PRISM’s layers map fairly directly onto ground Zachman or TOGAF already covered, and this article should say so plainly rather than oversell the framework as something built from nothing. The genuinely new part sits in three places: Intent, Signal, and Movement. Each one carries a named construct that neither Zachman nor TOGAF has an equivalent for.
Intent carries If-Then. It captures risks, goals, and constraints as conditional statements tied to a decision, not as a narrative buried somewhere in a design document. If a condition holds, a specific consequence follows, and that link is written down where anyone can check it later.
Signal carries Exchange. It treats APIs, events, and contracts as the actual unit of architecture, not as an implementation detail left to whoever builds the integration. A REST API, an HL7 message, and a truck leaving a loading dock are all the same kind of thing under Exchange. Each one is something crossing a boundary, carrying value from one part of the enterprise to another.
Movement carries two constructs. Pulse covers ethics, adoption, and sentiment. Legacy covers history, trajectory, and the decisions that got the organization to where it is now. Between the two, Movement is where PRISM tracks not just what changed, but why it changed and how people responded to it.
Pulse tracks four things most EA frameworks leave out entirely. First, how deeply people are actually using a system they were handed. This runs on a six-level scale from “none” to “embedded,” because deployment and adoption are not the same thing, and a system that’s live but unused is quietly costing the business money it hasn’t noticed yet. Second, the dominant emotional signal coming from a stakeholder group, whether that’s enthusiasm, skepticism, or plain fatigue. Third, change readiness, drawing on Armenakis, Harris, and Mossholder’s (1993) research on organizational capacity to absorb change. PRISM treats this as something you measure over time, not something you assume. Fourth, ethics markers. These don’t resolve a concern about bias, privacy, or accessibility, but they make sure it’s named and owned by someone instead of floating around undocumented.
Risk still sits inside If-Then, in Intent. Exchange still sits in Signal. Nothing gets dropped, it just moves to the construct built to hold it.
This matters because architecture that ignores whether people adopt it is, quietly, an incomplete architecture. It describes the technical landscape in detail and says nothing about the human one sitting right next to it.
A Comparison, Stated Plainly
Table 1
Where PRISM stands when compared to Zachman and TOGAF, Side by Side
| What You’re Comparing | Zachman | TOGAF 10 | PRISM 1.0 |
| What it mainly gives you | A reference ontology | A process model | A landscape you can author |
| Where artifacts live | Not tool-defined, any format works | Tool-dependent, usually a dedicated repo | Plain YAML and Markdown files |
| Version control | Not part of the framework | Not part of the framework | Git, as a core principle |
| Tooling you need to start | None mandated | An EA repository product | A text editor |
| Domain reach | Domain-agnostic in theory | IT-centric | Works outside IT by design |
| Human adoption | Out of scope | Out of scope | First-class, in the Movement layer |
| How time is modeled | Rows imply levels, not time | ADM phases | Baseline, transition, target |
| Governance | Sits outside the framework | ADM phase gates | Git pull requests |
| Modularity | Single flat taxonomy | Modular, core + extension modules + series guides | Modular by design, schema-driven components, disciplines |
| Augmented EA (machine-readable schema) | Cells filled in any format | Formal metamodel exists | Machine-readable by design |
| Getting started | Slow | Slow | Fast |
| Coverage | Comprehensive | Comprehensive | Narrower, on purpose |
Note. This table describes different design emphases, not deficiencies. Each framework serves its intended context. Zachman (1987). TOGAF (The Open Group, 2022).
The tradeoff PRISM makes is right there in the last two rows. It gives up some completeness in exchange for a much lower cost of entry and a much more honest treatment of the human side of change. That’s not a claim that PRISM beats Zachman or TOGAF everywhere. An organization with a working TOGAF practice, certified staff, and existing tool investment has good reasons to keep doing what it’s doing, and nothing here argues otherwise. PRISM isn’t scoped to smaller organizations either. Any organization, large or small, that hasn’t already sunk years into a TOGAF practice is exactly who PRISM is aimed at.
Time as Part of Every Artifact, not a Separate Concept
Every PRISM artifact carries a temporal state. Baseline, meaning the architecture as it exists right now. Transition, meaning an intermediate step during a planned change. Target, meaning where the organization is trying to get to. This is not a sixth layer bolted on. It’s a property every artifact already has.
Git makes this concrete instead of conceptual. Published baselines get tagged prism/baseline/2026-q3, targets get tagged prism/target/2026-q3, and transition work lives on a branch like prism/transition/customer-platform-migration. Checking out a tag gets you the exact architecture at that point in time. Diffing two tags shows you what changed, using the same tooling a developer already reaches for to review a code change. TOGAF’s Architecture Change Request and Compliance Review artifacts effectively disappear into a pull request review, because that’s already where the decision and its rationale live.
Outside IT, Where It Also Has to Work
A framework that only works for software teams is not really domain-agnostic, so it’s worth walking through what PRISM looks like somewhere else entirely.
Take a hospital network. The People & Place layer models clinical staff roles, patient populations, and regulatory zones tied to HIPAA, along with distinct operating environments like the ICU, general wards, and outpatient clinics. Reality captures clinical workflows, the drug formulary, and the patient record systems doing the actual work. Signal documents the HL7 FHIR interfaces connecting the EHR to the pharmacy system, along with consent protocols and referral processes between departments. Movement tracks how quickly clinicians are actually adopting a new EHR module, whether nursing staff are running on fumes after a recent restructuring, and how far along the hospital is on its move from paper charts to digital records.
Or take a manufacturer running several plants. People & Place covers line workers, plant supervisors, and supplier relationships across regions. Reality treats each production line as a system, tracks bills of materials as data assets, and documents lean production workflows as processes. Signal captures EDI 856 shipping notices exchanged with suppliers and the integration events flowing through the manufacturing execution system. Movement tracks whether the workforce is actually ready for a lean manufacturing rollout, and how far the current factory layout is from the target state leadership signed off on.
Neither example needed a different notation or a specialized tool. The YAML templates stay identical. Only the content changes, which is exactly the point.
What PRISM Doesn’t Do Yet
A framework that only lists its strengths is not being straight with its readers, so here’s where PRISM is genuinely thin right now.
It hasn’t been tested through a longitudinal case study yet. Everything above is grounded in practitioner experience and in the research, it cites, but nobody has run PRISM inside a real organization for a year and measured what changed. That is the most important gap, and closing it is the actual priority ahead of anything else on this list.
Tooling is early, but not completely absent. prism-framework.org hosts a landscape renderer, a YAML editor, and visual forms for authoring artifacts without hand-writing YAML. Mark a system for decommission there and it surfaces every system that depends on it. What’s still missing is a broader query interface, the kind that answers open-ended cross-layer questions beyond decommission impact.
There’s no maturity model yet either and it’s intentional for the time being. Organizations adopting a new framework usually want to know what ‘getting better at this’ looks like over time, and PRISM doesn’t answer that question in version 1.0. TOGAF’s maturity model itself is based on U.S. Department of Commerce’s Architecture Capability Maturity Model (ACMM) which was published in version 1.2 in December 2007 (U.S. Department of Commerce, 2007). And an initial absence of a maturity model does not make PRISM any less of a framework.
Pulse, the adoption-tracking part of the Movement layer, currently captures the vocabulary and structure for measuring sentiment and change readiness, but not a validated method for actually taking that measurement. That’s a real gap between what the schema can hold and what anyone can currently fill it with reliably.
And large enterprises that run several genuinely separate business domains will find that PRISM 1.0 doesn’t yet define how multiple landscapes relate to each other. That’s a known limitation, not an oversight, and it’s on the roadmap.
Why This Is Worth an Afternoon of Your Time
Enterprise architecture has had a tool-and-entry-cost problem for a long time, and it has kept the practice mostly confined to organizations big enough to fund a dedicated team. PRISM takes the operating model modern software teams already trust, version-controlled text, schema validation, pull-request review, and applies it directly to architecture instead of asking teams to adopt something unfamiliar.
The five layers, taken together, cover the same ground as Zachman’s matrix or TOGAF’s full ADM, without demanding the same upfront investment before anyone sees value. The Movement layer treats adoption and readiness as measurable architectural facts, not soft inputs handed off to a change-management team. That’s the part worth remembering most.
PRISM doesn’t replace Zachman or TOGAF, and it is not trying to. Instead, PRISM is compatible with both. It’s aimed at any organization that needs architectural discipline, large or small, and it’s trying to make the human cost of change something an architecture can actually name instead of quietly ignore.
Extended Disciplines
While PRISM Core is solid, in practice it has been a challenge to scale past the same core pattern to the different disciplines such as Application, Data, Cybersecurity, etc. and this is where PRISM tries to build on the core by carrying forward the same authoring style to the extended discipline areas. This was a design choice to eliminate the complexity by simply representing the extended disciplines in the form of landscapes. To this, PRISM scales past the core five layers into six specialized disciplines, where each has its own dimension set but follows the same authoring conventions:
- Infrastructure (Who, Where, Runtime, State, Control, Operations),
- Cybersecurity (Identity, Surface, Controls, Threats, Posture),
- AI Architecture (Models, Systems, Lifecycle, Trust, Observability),
- Application Architecture (Domains, Components, Integrations, Quality, Evolution),
- Data (Domains, Flows, Platforms, Contracts, Governance), and
- Product Validation (Market, Value, Bets, Hypotheses, Signals).
In comparison, TOGAF handles this kind of scope growth through Series Guides i.e., over 30 companion publications covering technical domains, methodology, and industry-specific guidance, and these sit alongside the ADM/BDAT core without sharing its schema or governance model (The Open Group, 2022). PRISM takes a tighter approach, where each discipline is a first-class citizen of the same authoring system as the core five layers, using the same layer-definition format, the same JSON Schema structure, and the same governance model, just scoped to a narrower domain. The standardization is not in the dimension set as it varies by discipline but it is in the pattern. A team already fluent in PRISM EA can pick up PRISM/CY or PRISM/D without learning a new grammar. To reiterate PRISM takes an opinionated version and similar to TOGAF, new disciplines will be introduced as need arises.
Each discipline discussed above deserves its own treatment, and that is coming separately, this article scope is limited to name them and shows how they attach. The full specification (layer definitions, schema, governance model) is published separately at the prism-framework.org (Palakurthi, 2026) and versioned in the project repository, the intent of this article is to cover the core ideas, not the complete technical reference.
The specification, the JSON Schemas, and the authoring templates are all open-source. Feedback, disagreement, and real-world test cases are what this framework needs most right now, and this article is partly an invitation for exactly that.
To conclude, a lot of people I worked with often used analogies, as they are so simple yet very powerful in conveying the idea, explain the context and in that spirit, I would like to draw one from Vemana padhyam that fits exactly “గంగిగోవు పాలు గంటెడైనను చాలు, కడివెడైన నేమి ఖరము పాలు” to put it simply in context of PRISM, it’s grounding in prior work is deliberately narrow rather than absent. In the spirit of the old Telugu saying that a spoonful of good milk outweighs a potful of poor milk, which the intent here is relevance over volume.
References
Armenakis, A. A., Harris, S. G., & Mossholder, K. W. (1993). Creating readiness for organizational change. *Human Relations*, 46(6), 681–703. https://doi.org/10.1177/001872679304600601
Kotusev, S. (2021). A comparison of the top four enterprise architecture frameworks. BCS, The Chartered Institute for IT. https://www.bcs.org/articles-opinion-and-research/a-comparison-of-the-top-four-enterprise-architecture-frameworks/
Palakurthi, V. (2026). PRISM: A source-first enterprise architecture standard and framework family for the modern organization. SSRN. http://dx.doi.org/10.2139/ssrn.7037719
Ross, J. W., Weill, P., & Robertson, D. C. (2006). *Enterprise architecture as strategy: Creating a foundation for business execution*. Harvard Business School Press.
The Open Group. (2018). *The TOGAF® standard, version 9.2*. The Open Group.
The Open Group. (2022). *The TOGAF® standard, version 10*. The Open Group.
U.S. Department of Commerce. (2007). IT architecture capability maturity model (Version 1.2). Office of the Chief Information Officer.
Zachman, J. A. (1987). A framework for information systems architecture. *IBM Systems Journal*, 26(3), 276–292. https://doi.org/10.1147/sj.263.0276
