The Spreadsheet
Field Notes on Enterprise Architecture in Healthcare (The Messy Middle)
There is a moment in every architecture effort where the whiteboards stop being inspiring. The sticky notes start falling off the wall the diagrams that made me feel so smart two weeks ago starts to look like they were drawn by someone who has never actually worked in a health system. Then someone, usually the most practical person in the room, says the thing everyone has been thinking for at least a week. Can we just put this in a spreadsheet.
So I did, and I want to talk about what happened, because this part of the work does not get written about much and I think it should.
The First Version Lied to Us
You start with what feels obvious: Infrastructure, Applications, Data, Security. It looks clean. It looks like something you could put in front of an executive without embarrassing yourself……..and then you try to actually place things in it.
Where does patient room technology live? Is telehealth a product, a platform, or a capability? Is device integration infrastructure, middleware, or clinical operations? Where does command center logic sit? What about the ambient monitoring pilot that technically belongs to three different teams depending on who you ask on which day?
Twenty minutes in, the domain model is lying to you. Not on purpose. Just simplistically. Because the domains you chose were shaped by the org chart, not by how care actually moves. So then you pivot and stop focusing on cataloging tools and start trying to ask better questions:
Are these real enterprise domains or just how we have always done it? Are we organizing by technology type, by capability, or by ownership, and do we actually know the difference between those three things? Are we treating care environments as real architectural entities or are we still pretending everything is an application because that is easier to put in a column? If I handed this to someone new tomorrow, would it help them understand how care is delivered here or would it just confuse them in a more organized way, and would they need a translator to understand it?
The spreadsheet does not let you stay comfortable the way a whiteboard does. Whiteboards let you gesture at things. Spreadsheets (or databases, but lets be real we are definitely not at that level of permanence yet.) make you be specific about things. That is why this phase is harder than it looks.
Every New Domain Is a Political Act
Here is the part that does not make it into the architecture presentation. When you start noticing what does not fit, you start adding things. A Care Environment domain. A Presence and Communication domain. A Device and Edge domain. A Workflow Orchestration layer that does not cleanly belong anywhere. A Governance and Ownership column that is going to be deeply uncomfortable to fill in because some of those cells are going to be empty in ways that will raise questions, or there will be multiple names and the leaders will ask why?
Every one of those additions is a political act.
You are redrawing boundaries. You are implying ownership where ownership has never been formally established. You are surfacing overlap that someone somewhere has been comfortable not examining directly.
This is why the phase feels messy. Not because the technical questions are hard, although some of them genuinely are. Because the organizational questions sitting underneath the technical ones are hard. And the spreadsheet, if you are honest about it, will not let you avoid them.
I have now been in rooms where adding a single domain column derailed a two hour meeting. Not because the addition was wrong, because it was right and nobody was ready for what that meant.
The Question I Keep Coming Back To
When I am building or refining this thing I keep asking one question: if we tried to scale tomorrow would this structure hold. Not does it document what exists. Does it hold under pressure.
If we add another hospital does the model extend or does it collapse into a new version of the same confusion we started with. If we add AI-driven decision support at the edge where does it land and does that placement actually make sense to the people who will own it. If nursing leadership asks for enterprise visibility across units next week can this spreadsheet support that view or does someone have to start over from scratch.
Architecture is not about documenting what exists. It is about testing whether what exists can scale without falling apart. The spreadsheet is how you run that test before the pressure is real.
From Inventory to Model, and Why That Transition Is Harder Than It Sounds
There is a trap here and I want to name it because I have almost fallen into it and I have watched other people fall into it completely. You can spend months perfecting the taxonomy while nothing changes operationally. The spreadsheet becomes a catalog. Comprehensive, well-organized, and completely disconnected from actual decisions.
So we phased the work deliberately (note we are still in the middle of this so I will report back on if it is an absolute disaster)
Phase one is just visibility. Get everything into one place even if the categories are not perfect. Imperfect and complete is more useful than elegant and partial and I will defend that position.
Phase two is pressure-testing the domains, adding the ones that are missing. Split the ones doing too much work. Merge the ones that are artificially separate. Make the structure honest even when honesty surfaces things nobody was planning to look at this quarter.
Phase three is where it gets real. For every row: who owns it, what capability does it support, is it redundant, is it strategic or tactical or just legacy that nobody has gotten around to addressing, what is the plan if it needs to go away. This is where the spreadsheet stops being documentation and starts being strategy. Those are genuinely not the same thing.
The Emotional Reality
Current state documentation is draining work and I think we should say that more plainly than we usually do.
It surfaces things nobody wants to look at. Multiple tools solving the same problem purchased by teams who did not know about each other. Critical workflows with no clear owner. Devices installed without lifecycle plans that have been quietly humming along since the original implementation team left three years ago. Capabilities that exist in one building and not another with no documented reason why.
The pull toward future state is real and I understand it. Future state feels generative. Current state feels like an audit of decisions you did not make but now have to account for……But if you skip it, or rush through it, your future-state architecture becomes fiction (welcome Informatics Brain, thank you for finding current/future state workflows in literally everything). A beautiful diagram with no honest relationship to the thing it is supposed to be built on. I have seen this happen. It is an expensive way to learn the lesson.
The messy middle is necessary. I have not found a shortcut that actually works and at this point I have stopped looking for one, and am in the middle of the chaos.
The Spreadsheet Is Not the Architecture
At some point if you stay with it long enough something shifts. It stops feeling like a task and starts feeling like a lens.
You start seeing patterns. Where investment is fragmented across teams who genuinely do not know about each other. Where capabilities are overbuilt in some areas and missing entirely in others. Where the infrastructure is actually pretty mature but the service modeling on top of it is years behind. Where governance is implied but never written down anywhere a new person could find it.
The spreadsheet is not the architecture. I want to be careful about that because it is easy to confuse the two. The spreadsheet is the mirror. It shows you what you actually have so you can make honest decisions about what to build next.
The Part I Think About a Lot
There is a leadership question embedded in this work that I do not hear talked about much.
Do you build this quietly and present it fully formed, or do you let people see the mess while it is still a mess.
Both approaches carry real risk. Transparency invites critique before the work is mature enough to defend. Silence invites the kind of misalignment that you discover too late to fix cheaply.
I do not have a clean answer. What I have noticed is that the health systems that mature architecturally tend to be the ones willing to sit in visible ambiguity long enough to build something that holds. They let the spreadsheet be messy in public for a while. They ask for input before they have answers. They do not wait until everything is polished before starting the conversation.
That requires a specific kind of organizational trust that takes time to build. Worth naming that honestly rather than pretending it is just a methodology choice.
Where This Goes
The current-state spreadsheet is not the endpoint. It is the substrate for everything else. Capability rationalization. Portfolio prioritization. Governance modeling. Investment planning. Without it those conversations are opinion dressed up as analysis.
With it, even imperfectly structured, even still evolving, you start moving from reacting to building. And that shift is the whole reason any of us are doing this work.
It is going to be messy. It is going to change. There will be a point around revision four where you question every domain decision you made in week one. That is not a sign something is wrong. That is a sign you are actually doing the work and learning from it.
Next up I want to get into what happens when you start trying to map capabilities onto this structure, because that is where the conversations get genuinely interesting and the politics get considerably more complicated.