Modeling the Elephant: The Six-Phase Pipeline for Business-Aligned Architecture

6 minute read

During a recent engagement with a major healthcare organization, Impact Makers was brought in to help automate provider data management. The goal was clear. The path was not.

What we encountered was multiple worlds converging at once. Clinical teams, administrative teams, technology teams, and operational teams all working toward the same automation objective but speaking entirely different languages. The same concepts had different names across departments. The same terms meant different things across systems. Data that was supposed to flow between platforms arrived in forms the receiving system could not interpret. Project teams were churning through discrepancies that nobody could fully explain because nobody had a complete picture of how all the pieces connected.

The technical challenges were real, but the root cause was not technical. It was semantic. Nobody had ever formally described the full lifecycle of provider data across all the worlds that touched it. Without that shared model, every integration decision was being made in isolation, every team was optimizing for their own context, and the automation goal kept receding as new conflicts surfaced.

Impact Makers built an ontology describing the full provider data lifecycle, capturing the terms, definitions, and business concepts from each world and mapping the relationships between them. The effect was significant. Teams that were churning began to understand how the lines of business actually connected. Concepts that seemeded unique to each department turned out to be the same concept expressed differently. The nuances that did exist became visible and manageable rather than invisible sources of confusion. Progress toward the automation goal accelerated because the teams finally had a shared foundation from which to build.

This is the pattern we encounter consistently across industries: complex initiatives stall not because the technology is wrong, but because the business meaning underneath it was never formally modeled. This article describes the process our team uses to build that model in a disciplined, repeatable way.

The first three articles in this series established the why. The Context Crisis named the foundational problem. The Semantic Illusion addressed what it takes to fill the semantic layer. The MBE Mandate made the case for a stateful, executable model over static documentation.

This article addresses the how. Specifically, what does the process of building a business-first ontology actually look like, and how does an organization move from the first stakeholder conversation to a validated architecture that the business recognizes and trusts?

The answer is a structured, six-phase pipeline that our practitioners follow on every engagement. It is not a rigid sequence of steps so much as a disciplined progression that ensures nothing important is missed and nothing is built before the foundation is ready. Each phase has a clear purpose and a clear exit criterion. Nothing advances until that criterion is met.

The pipeline moves from broad business understanding to a validated, deliverable architecture in six phases:

1. Domain Ontology Establish the full scope of the business domain being modeled. What entities exist, how they relate, and what vocabulary the business uses to describe them. This is where the Elephant is first drawn in full.
2. Decomposition Slice the domain into deliverable scopes using business-driven lenses such as value streams and outcomes. The full Elephant does not need to be built before value is delivered. Decomposition identifies where to start and in what sequence to proceed.
3. Scoped Ontology Build the formal model for the selected scope, connecting business concepts to the data structures that will serve them. This is where the Ontology Accelerator does its most intensive work, using AI-augmented modeling to produce a substantive draft before stakeholder validation begins.
4. User Profiles Define the business questions the architecture must answer and the grain at which those answers need to be precise. These profiles become the guardrails for every subsequent decision. If a modeling choice does not serve the business questions, it does not belong in the scope.
5. Logical Use Case Translate the validated ontology into the logical data structures that will be built and delivered. This phase produces the artifacts that development teams work from, ensuring that the business intent captured in earlier phases is preserved through to implementation.
6. Handoff  Deliver the validated architecture with full lineage from business concept to data structure, along with the documentation and context needed for the receiving team to build, maintain, and extend it confidently.

The most critical input to any ontology is the knowledge that lives in the people who understand the business. Getting that knowledge out efficiently, without consuming weeks of executive and SME time, is where methodology matters most.

Impact Makers uses a “draft to correct” approach rather than a blank-page requirements gathering process. Our practitioners, supported by the Ontology Accelerator, produce a working draft of the business model before the first validation session. Subject matter experts are not asked to define concepts from scratch. They are shown a draft and asked to confirm what is right, correct what is wrong, and answer specific questions the draft surfaces.

This shift changes the dynamic entirely. People are far better at recognizing and correcting something than articulating it from nothing. The draft gives them something to which they can react. Their corrections and clarifications are the capture mechanism. Validation sessions that would otherwise run for hours and produce incomplete results become focused, productive, and bounded.

Across this series, we have referenced a rigorously developed methodology combined with purpose-built tooling. The Ontology Accelerator is that tooling.

It is an AI-augmented modeling environment built specifically to support the kind of complex, iterative ontology work this series describes. It maintains the full state of the model across sessions, meaning a practitioner working on a weeks-long engagement does not lose context between conversations or between work sessions. It accelerates the production of initial drafts, enabling our team to arrive at stakeholder sessions with substantive material rather than blank templates. And it produces the structured outputs, including JSON artifacts stored in a versioned repository, that feed directly into the downstream architecture.

The Ontology Accelerator is what allows a small, experienced team to deliver the depth of modeling work that organizations like Palantir, Netflix, and Uber built entire internal platforms to achieve. It does not replace the judgment and domain expertise of the practitioners using it. It eliminates the overhead that traditionally made that kind of work slow and resource-intensive.

The healthcare engagement described at the opening of this article is one example of what a structured modeling process makes possible. The automation goal that was stalling due to semantic conflicts became achievable once the shared model existed. The teams did not need to become data experts. They needed a common language and the ontology gave them one.

The same pattern plays out in financial services organizations managing risk across product lines that were built or acquired with different definitions of exposure; and in manufacturing organizations trying to connect design, production, and quality systems that each model the same products differently; and in government agencies trying to share information across divisions that were never designed to communicate with each other.

The details differ. The root cause is the same. And the process for addressing it is consistent enough that we can apply the same six-phase pipeline across all of them, adapting the domain knowledge and the scope while keeping the structure intact.

Tool-Augmented Modeling for the Modern Enterprise. The process is proven. The remaining question most executives ask is how long it takes and what it costs. The final post in this series answers both.

The Business-First Ontology Series draws on years of Impact Makers’ practitioner experience delivering data architecture and AI solutions across enterprise clients. The observations and findings in this series reflect patterns we encounter consistently in the field.

For more practical insights and proven methodology on building data architecture that serves your business and your AI, read the full series below.

• The Context Crisis: Why AI and Data Warehouses Fail Without a Business-First Ontology.
• The Semantic Illusion: Why You Can’t Buy a Semantic Layer — You Have to Model One.
• The MBE Mandate: Moving From Static Documentation to Executable Architecture.
• Modeling the Elephant: The Six Phase Pipeline for Business-Aligned Architecture.
• The Architecture of Speed: Tool-Augmented Modeling for the Modern Enterprise.