Three years ago, I was managing a capacity-constrained airport market - 4,600+ vehicles, airline schedules shifting in real time, reservation demand that could spike or collapse inside a four-hour window. The problem wasn't operational skill. The problem was that I couldn't see the data I needed to make decisions before problems happened instead of after.
The solution required pulling real-time airline feeds into a unified dashboard alongside reservation data, eliminating the manual Excel reconciliation that was absorbing over ten hours of analyst time each week, and building the integration architecture to make all of it update continuously. The result changed how we allocated vehicles and removed the blind spot that had been costing us capacity.
What I didn't know at the time was that this project had a formal name. In the language of enterprise architecture, what I'd built was an Information Systems Architecture - one of four core domains in something called TOGAF.
TOGAF is The Open Group Architecture Framework, a globally recognized standard for enterprise architecture practice. It's used by CIOs at Fortune 500 companies and large government agencies, and it has a reputation as an IT governance tool that has nothing to do with operations. That reputation is wrong, and understanding why is one of the more useful reframes an operations leader can make.
The misconception starts with the word "architecture." In enterprise architecture, architecture doesn't mean software design or system diagrams. It means the deliberate structure of how business capabilities, data, applications, and technology fit together to deliver outcomes.
That definition belongs to operations as much as it belongs to IT.
TOGAF is built around four domains: Business Architecture, Data Architecture, Application Architecture, and Technology Architecture. Operations leaders typically own the first two directly. We own how business processes work (Business Architecture) and how information flows through the organization (Data Architecture). The last two - applications and infrastructure - are where we hand off to IT. And those handoffs are where most cross-functional technology projects break down, because there's no shared language for them.
TOGAF provides that shared language. It doesn't transform operations into an IT discipline. It gives operations leaders the vocabulary to participate as equals in technology decisions that directly affect operational outcomes - instead of receiving technology handoffs and hoping they work.
This matters because the alternative is what most organizations already experience: IT builds systems optimized for IT concerns, operations accepts whatever gets delivered, and everyone wonders why the data doesn't support the decisions that need to be made.
The operational heart of TOGAF is the Architecture Development Method, or ADM - a cyclical, iterative process for making and documenting architectural decisions. It has multiple phases, but the core logic maps directly onto strategic planning processes that operations leaders already use.
When I scaled our fleet from 4,600 to 5,600+ units to unlock approximately $15.9M in incremental revenue capacity, the process looked like this: assess the current state (what do we have, what are the constraints?), define the target state (what do we need?), identify the gaps (what's missing - vehicles, routing logic, staffing, data integrations?), and sequence the transition (in what order do we close those gaps?). That is the ADM cycle in operational clothing.
The phases of the ADM - Architecture Vision, Business Architecture, Information Systems Architecture, Technology Architecture, Opportunities and Solutions, Migration Planning - translate into operational language as: define the problem, document how the business currently works, document how information and systems need to work, identify the technology infrastructure that supports it all, find the gaps, and plan the path to close them. Most operations leaders have done this work informally on every major project. The ADM formalizes it and makes it communicable to technical stakeholders who need that structure to build what you actually need.
The fleet integration project is one example. Here's another that's less visible but equally instructive.
At Lowe's, I managed a $97M store with 60+ staff during pandemic-era supply chain disruption. Reducing shrink from 2.3% to 1.6% - recovering approximately $680K annually - required aligning three things simultaneously: how staff workflows were structured (Business Architecture), how inventory data was tracked and made visible (Data Architecture), and what systems and tools were supporting those workflows (Application Architecture). Getting those three layers aligned was not an IT project. It was an operations project with significant technology implications that I was navigating without any architectural framework to structure the decisions.
Had I been thinking in TOGAF terms, I would have had a clearer methodology for documenting the current state, articulating the target state to the IT teams and vendors involved, and communicating the dependencies to leadership. Instead, we got there through operational intuition and a lot of rework that better architectural thinking might have shortened.
That's the practical value of TOGAF for operations leaders: not that it introduces new discipline, but that it structures and communicates discipline you're already applying. The framework makes your operational knowledge legible to the people who need to build the technical solutions that serve it.
You don't need to pursue TOGAF certification to benefit from enterprise architecture thinking - though I'm currently studying toward it and finding the formal framework more applicable to operational work than I expected. What you need is a working understanding of the four architecture domains and the discipline to think about technology decisions at all four levels before committing to them.
In practice, this looks like asking different questions earlier in the process. Before agreeing to implement a new system: where does this fit in our Business Architecture? What data flows will it depend on, and are those flows currently reliable? What applications will it need to integrate with, and what are the costs of those integrations? What happens to this system when our technology infrastructure changes? These are architectural questions, and asking them before implementation is dramatically cheaper than discovering the answers afterward.
For operations leaders managing nonprofit organizations, TOGAF thinking offers something even more concrete. Most nonprofits operate with fragmented systems - donor CRMs, program management tools, financial reporting platforms, and volunteer tracking databases that don't communicate with each other, built by different staff over time without any architectural oversight. The solution isn't necessarily buying better software. It's applying architectural thinking to prioritize which integrations matter most, which data should be standardized, and which technology decisions are creating long-term debt that future staff will inherit.
The pitch isn't "hire an enterprise architect." It's "have better conversations about technology investments before you make them." TOGAF gives you the structure to have those conversations at the right level of specificity.
What I keep finding as I go deeper into TOGAF is that the framework names things I was already doing without vocabulary for them. The airport data integration project was an Information Systems Architecture effort. The fleet scaling initiative followed the ADM cycle without being called that. The Lowe's shrink reduction was a multi-domain architectural alignment challenge that I solved operationally without the benefit of the framework's language.
The vocabulary matters because it creates alignment. When operations leaders can articulate architecture decisions in terms that IT teams, finance leaders, and technology vendors recognize, the translation failures that kill cross-functional projects become less likely. You're not learning a foreign discipline. You're acquiring a second language for work you've been doing in your native one all along.
If you're an operations or business leader, you're not outside enterprise architecture. You're the reason it exists.