Get Executives to Act on Data: The Real-Time Decision Framework

The Problem No One in Enterprise Architecture Wants to Admit

A general asks a simple question: “Can we deploy? Do we have the capability to do this right now?”

His team’s answer: “Sir, we don’t know. Let us go check.”

Three weeks later, they return with a new diagram. By then, the deployment decision has already been made—with incomplete information.

This is the scenario Randy Dewoolfson, co-founder of InQuisient and applied mathematician with 20+ years solving large-scale data problems for the US Army and federal government, has spent his career trying to eliminate. The problem he describes isn’t unique to the military. It is the defining failure mode of enterprise data architecture across every sector—manufacturing, cloud migration, federal procurement, and commercial enterprise alike.

“That is like the business problem for every executive. You have this question and then the data is always out of date. It takes a team and a study to figure it out and you still have to move anyway.”

The stakes of failing to get executives to act on data aren’t theoretical. Decisions get made anyway—just without the information that was supposed to inform them.

Key Takeaways

When executives can’t get real-time answers to capability questions, they make consequential decisions on stale data. Randy Dewoolfson’s work at InQuisient reveals that 80–90% of enterprise architecture output never reaches decision-makers in actionable form. The solution requires rethinking data architecture from the top down—starting with the executive question and building backward to the data integration layer. Platforms that manipulate meta-layer data structures can go live in weeks, not years, and transform enterprise architects from back-office overhead into the requirements engineers driving agile development.

• 80–90% of enterprise architecture work is ignored — static diagrams on walls don’t answer real-time executive questions; this is a delivery failure, not a data failure
• The 3-week study cycle kills decision velocity — by the time analysis is complete, the decision window has closed; real-time dashboards eliminate this bottleneck entirely
• Meta-layer architecture is the force multiplier — manipulating data structures (not raw data) simultaneously generates data models, interfaces, and security rules without custom development for each use case
• Services revenue can fund product development — entering government markets as a subcontractor generates cash while you build, without surrendering product-company identity
• Bootstrapping creates better founders — constraint forces discipline; VC-funded comfort breeds waste and removes the skin-in-the-game mentality that drives precise decision-making
• Enterprise architects become requirements engineers — when their models feed directly into Jira backlogs and decision dashboards, their role transforms from ignored overhead to critical infrastructure
• AI’s highest enterprise value is context-aware gap-filling — platforms with built-in customer data context outperform generic AI by telling the engine exactly what data world it’s operating in

Deep Dive: How to Get Executives to Act on Data Before the Decision Window Closes

Why Enterprise Architecture Fails Executives at the Moment It Matters Most

Enterprise architecture fails executives because the format of its output—static, printed, meeting-dependent—is structurally incompatible with the speed at which strategic decisions must be made. The data exists. The analysis happens. But by the time the six-foot diagram is printed and the three-week meeting is scheduled, the executive has already acted on instinct. Dewoolfson spent 20 years watching this pattern repeat identically across the US Army, federal agencies, and commercial enterprises.

The failure isn’t technical. It’s architectural—in the human sense. The process that creates enterprise architecture diagrams was never designed to feed executive decision cycles. It was designed to document what exists, not to answer what’s possible right now.

“Literally teams and teams of people in cubicles plot these things out on 6-foot-wide papers and stick them on the wall—but then that’s where they stopped.”

The pattern Dewoolfson observed across sectors—military readiness, manufacturing capacity, cloud migration feasibility—is structurally identical. An executive asks a capability question. The question cascades down the org chart. At the bottom, someone has partial data in an incompatible format. They offer to produce a new diagram. The meeting is scheduled three weeks out. The decision gets made before the meeting happens.

This is the business problem for every executive operating in a complex organization: the data is always out of date, a team and a study are required to interpret it, and the decision cannot wait.

What Is Meta-Layer Data Architecture and Why Does It Solve Enterprise Integration?

Meta-layer data architecture is a hierarchical abstraction approach where Layer 1 addresses raw data complexity, Layer 2 addresses the structures that hold that data, and Layer 3 addresses how those structures relate and behave. By defining the right meta-layer, a platform can automatically generate data models, interfaces, and security rules without custom development for each new integration or use case.

Dewoolfson’s core intellectual contribution—developed over 20 years of building large-scale data systems—is the recognition that 80–90% of large data models across any industry share identical core structures. People. Organizations. Addresses. Money. The domain changes; the underlying architecture doesn’t.

“I kind of built a perspective that there was about 80 or 90% of commonality to every large data model. You always talk about people. You always talk about organizations. You always talk about addresses and money.”

This insight unlocks what Dewoolfson calls “meta-layer thinking”—the practice of manipulating the structural layer above raw data rather than the data itself. The payoff is substantial. Instead of rebuilding data models, interfaces, and security rules for every new enterprise customer, you define them once at the meta level and let the platform instantiate them for each specific context.

“You can make magic happen by manipulating the right meta layer. It simultaneously defines the data model you want and the interfaces that go with it and the security that underpins it.”

The practical implication for enterprise data integration is a deployment timeline that compresses from years to weeks. Dewoolfson’s platform targets going live in approximately two weeks versus the two-plus years typical of custom enterprise data development. That compression is only possible because the meta-layer framework eliminates the need to reinvent core architecture for each deployment.

For executives trying to get real-time answers to capability questions, this matters enormously. Cross-system data visibility—the ability to query across people, assets, systems, and processes simultaneously—requires exactly this kind of pre-integrated structural foundation.

How the General’s Question Framework Reverses the Architecture Problem

Most enterprise data architecture starts with the data and works toward a use case. The General’s Question Framework inverts this: start with the specific executive decision that must be made, map what data is required to answer it in real time, and build backward to the integration layer. The result is a queryable architecture platform that lets executives get answers themselves without initiating a study cycle.

The framework has five steps:

1. Identify the top-level executive question — “Can we deploy capability X?” or “Do we have the machine capacity for this production run?”
2. Map the data required to answer it — this always spans multiple teams, systems, and formats that have never been integrated
3. Solve for real-time data integration across those sources, using meta-layer structures to avoid custom development
4. Build a queryable dashboard that returns the answer without requiring a study request or meeting
5. Connect architecture insights to development tracking so progress toward strategic capability goals is visible to leadership continuously

The insight driving this framework is that the executive’s capability question is identical across sectors. Dewoolfson explicitly connects the Army general’s readiness question to manufacturing deployment questions (“Can we install this machine? All the drawings are out of date.”) and enterprise cloud migration questions. The data-driven executive decision making problem is universal—only the domain vocabulary changes.

“That is like the business problem for every executive. You have this question and then the data is always out of date. It takes a team and a study to figure it out and you still have to move anyway. And this is like a very common—I feel like I’ve seen a version of this also in manufacturing.”

How Enterprise Architects Become Requirements Engineers When Data Reaches Executives

When enterprise architecture models feed directly into development backlogs and executive dashboards, the enterprise architect’s role transforms from documentation overhead to the critical path of organizational capability. Instead of producing six-foot diagrams for walls, architects produce explicit models, process maps, and decision trees that automatically convert into Jira backlogs, agile sprint priorities, and real-time capability dashboards.

This role transformation is one of the most underappreciated business cases for real-time decision dashboards at the executive level. For decades, enterprise architects have operated in organizational back-rooms—technically necessary but practically invisible to the leadership making strategic decisions.

“So these architects that for decades have been in the back room with nobody caring—now they are really the requirements engineers of the future. You can take their very explicit models, processes, decision trees, all the things they create and convert those directly into, let’s say, Jira backlogs and agile development efforts.”

The connection to agile requirement engineering from architecture creates a direct feedback loop between strategic intent (what the executive needs to be capable of) and tactical execution (what the development team builds next). The enterprise architect becomes the translation layer—but now the translation is automated by the platform rather than requiring a three-week study cycle.

How AI Fills Data Gaps in Enterprise Systems Without Custom Model Building

AI’s highest-value application in complex enterprise data integration platforms isn’t generating new models from scratch—it’s filling gaps in existing data using the built-in organizational context the platform already holds. Platforms with meta-layer understanding of a customer’s data structures can give AI engines precise context about what data world they’re operating in, dramatically improving gap-fill accuracy over generic AI approaches.

Dewoolfson’s framing here is precise and practically important. Generic AI models attempting to fill enterprise data gaps lack the organizational context to do so reliably. But a platform that already understands a customer’s data structures—their people, organizations, addresses, assets, and the relationships between them—can give an AI engine a head start that generic approaches can’t match.

“We understand these meta layers of our customers’ information model. So we have built-in context for the AI engines that is, I think, superior to what you might get otherwise. So we’re able to tell the AI, ‘Here’s the data world that we’re living in and here’s all the connections that we know about—and maybe you can help me fill in some of these gaps.’”

For executives trying to get real-time answers, missing data is the single most common reason dashboards fail in practice. A capability query that should return a clear yes/no instead returns “insufficient data.” AI-powered data gap filling—calibrated by the platform’s meta-layer context—addresses this without requiring a custom AI implementation for each enterprise deployment.

The Services-First Path to Government Product Sales

Selling a software product to the US government when the government prefers buying services requires a specific bridging strategy: enter as a subcontractor on an existing prime contractor’s vehicle, deliver billable consulting hours, use that revenue to fund parallel product development, and maintain strict discipline against becoming a services company. The product is always the endgame; the services relationship is the financing mechanism.

Dewoolfson is direct about the structural challenge. Government financing favors services procurement. The contracting vehicles, budget categories, and procurement processes are built for services delivery—not for SaaS licensing. Founders who want to sell product into government without understanding this dynamic will lose to the structural incentives every time.

“It’s actually a bit more difficult to sell product to the government. They’d rather buy service than product. The way the financing is set up, it’s harder—but I’ve been pretty rigid about: let’s maintain ourselves as a product company, not a services company.”

The six-step Services-First Path framework InQuisient used:

1. Identify government prime contractors with existing contract vehicles (GSA schedules, IDIQ contracts)
2. Negotiate placement as a subcontractor—the prime handles government billing and compliance
3. Deliver services (billable consulting hours) while building product simultaneously
4. Use contract revenue to fund product development without outside equity
5. Transition customers from services to product usage within the same relationship
6. Maintain the boundary: services is the bridge, not the destination

The founder-led government software sales model Dewoolfson describes depends entirely on personal network activation—what he calls “pulling the friend string.”

“I got it all, unfortunately or fortunately, through personal contacts. You kind of pull the friend string and say, ‘Well, let’s see if we can go talk.’”

This is not a scalable marketing channel. It is, however, the realistic starting point for complex enterprise and government SaaS sales where trust, domain credibility, and relationship access determine whether you get a meeting.

Why Bootstrapping Beats VC Funding for Complex Enterprise SaaS

Bootstrapping enterprise SaaS creates better decision-makers because financial constraint eliminates the option of making recoverable mistakes. When a founder is personally exposed—mortgaging a house, watching every dollar—the quality of decisions at the $10,000 level changes fundamentally. VC-funded founders who haven’t experienced this constraint haven’t been tested under conditions that reveal true judgment.

Dewoolfson’s perspective on bootstrapped vs. VC-funded SaaS is grounded in 20 years of observing how resource abundance changes founder behavior—not as a moral claim, but as a practical observation about decision quality under different incentive structures.

“You get too much money in the beginning. You don’t have to be lean. You can make a lot of mistakes and then you can fail easily. You don’t have your skin in it. So you do it where you know you’re mortgaging your house and you’re struggling—it changes the way you play the next $10,000.”

For founders building complex data modeling for enterprises or government SaaS, where sales cycles are long, compliance requirements are high, and product-market fit is expensive to validate, the financial discipline bootstrapping forces may be a structural advantage rather than a handicap.

About Randy Dewoolfson

Randy Dewoolfson is co-founder of InQuisient and an applied mathematician who spent 20+ years solving large-scale data problems for the US Army and federal government before translating that expertise into a SaaS platform. His perspective on enterprise data integration is built from direct, high-stakes experience—not theoretical frameworks—making his frameworks for real-time executive decision-making unusually grounded in operational reality.

Dewoolfson’s 20-year career working on government data systems gave him a pattern-recognition advantage rare in commercial SaaS: the ability to see structural commonalities across data models in radically different domains. That insight—that 80–90% of any large data model is built from the same core structures—became the foundation for InQuisient’s meta-layer architecture approach. He built and launched InQuisient from the Washington DC area, leveraging proximity to the federal workforce and a personal network cultivated over two decades of defense and government work.

Ready to Turn Your Architecture Work Into Real-Time Executive Decisions?

The pattern Dewoolfson describes—executives asking capability questions while their teams schedule three-week study meetings—is not a data shortage problem. It’s a delivery and architecture problem. The organizations that solve it don’t just answer executive questions faster; they make fundamentally better strategic decisions because the gap between asking and knowing collapses from weeks to seconds. If your B2B SaaS product sits at the intersection of data integration, enterprise visibility, or decision-support tooling, the frameworks in this episode offer a precise map of where the real value lives—and how to position against it.

Talk to a Growth Strategist →

Frequently Asked Questions

How do you get executives to act on data when their teams take weeks to produce answers?

The bottleneck isn’t willpower—it’s architecture. Executives ask capability questions that require real-time, cross-system data integration. Current enterprise architecture processes take 3 weeks to produce a static diagram that’s already outdated. The fix is building queryable dashboards that let executives answer their own questions without initiating a study cycle. Randy Dewoolfson’s approach maps the executive’s specific decision need first, then reverse-engineers what data integration is required to answer it in real time, eliminating the study-cycle delay entirely.

What percentage of enterprise architecture work actually gets used by decision-makers?

According to Randy Dewoolfson, co-founder of InQuisient, 80–90% of enterprise architecture work is never used by decision-makers. Teams produce six-foot-wide printed diagrams that get pinned to walls and never converted into actionable dashboards or decision support tools. The core failure is a delivery problem, not a data problem—the insights exist but never reach executives in a format they can act on within their decision timeline. Solving this requires starting with the executive’s specific question and building backward to the data integration layer.

How do you sell a software product to the US government when they prefer buying services?

The government’s financing structures favor services procurement over product licensing, making direct product sales harder for early-stage SaaS founders. Dewoolfson’s approach: enter as a subcontractor on an existing prime contractor’s government vehicle (GSA schedule or IDIQ contract). This handles compliance and billing while you deliver billable consulting hours. Use that revenue to fund product development simultaneously. Maintain strict discipline—never let the services revenue turn you into a services company. The product is always the endgame; the subcontractor relationship is the financing bridge.

What is meta-layer data architecture and why does it solve enterprise integration problems?

Meta-layer data architecture works by abstracting above raw data to the structural level—defining how data containers relate and behave rather than processing raw data directly. Manipulating this meta-layer simultaneously generates data models, interfaces, and security rules without custom development for each deployment. Dewoolfson identified that 80–90% of large data models in any industry share the same core structures (people, organizations, addresses, money), which means a platform built at the meta-layer can deploy for new enterprise customers in approximately 2 weeks instead of the 2-plus years typical of custom development.

How can AI fill data gaps in enterprise systems without building custom models from scratch?

Platforms that already understand an organization’s meta-layer data structures—how its people, organizations, assets, and relationships are connected—can give AI engines precise organizational context that generic AI approaches lack. Instead of asking AI to fill gaps blind, the platform tells the AI engine exactly what data world it’s operating in and what connections already exist, enabling more accurate and contextually appropriate gap-filling. This approach, as Dewoolfson describes it, is superior to generic AI because the built-in customer context is already encoded in the platform’s meta-layer architecture.