Issue #53 – Relevance of Business Models for Data
Why your business model is the starting point for every data decision you should make
Read time: 10 minutes
Sometimes I have a hard time fathoming how data professionals don’t understand what their company does or the business processes behind how it makes money/ operates.
But this is me forgetting that this is rarely explicitly articulated out.
Executives understand it.
Business functions get it.
Shareholders pretend to understand.
But data teams? Data teams are often focused on building data infrastructure or products, and don’t have time to learn about the business in great detail. Not to mention their background is often technically focused. And most companies also don’t bother to properly educate them in business fundamentals.
In the end, data teams work within their own siloed understanding of the business, leading them to optimize for technical proficiency without clear anchors for how the business actually operates.
…And people wonder why nobody uses their work. Or why data doesn’t deliver the value/ ROI it is supposed to.
Oh, and this problem is multiplied by 100 for AI, but we will get there in the next article.
So how do we solve this age-old data problem? First off, you read my previous article explaining what a business model is (and another article on business strategy if you want). Secondly, we dive into how business models are relevant for different data teams and domains. Let’s jump in!
How Business Models Should Influence Your Data Ecosystem
Before I start, in last week’s article, we established that every business model boils down to three core questions:
What does your business do?
How does it make money?
And what’s your differentiator?
Answering these three questions remains your first task, no matter how you approach it. Once you have that baseline understanding, you can embed it into how you design and operate your data ecosystem.
Where and how you embed it will depend on your role, but for the sake of holistic thinking (my favourite word), let’s examine all the different angles:
Data Strategy
Let’s start with the most obvious one—your data strategy. Next month we will do a deeper dive into Data Strategy and how to think about building and executing one.
But for now, the key thing to remember is that a data strategy is a data-focused articulation of the business strategy (aka the goals and direction of the organization).
Given the business strategy is built on the back of the business model, it flows fairly clearly into one another. The business model tells you what value you’re creating, for whom, and how. Therefore, when prioritizing your data goals, initiatives and roadmap, your data strategy should articulate how data actions and supports the business model.
This is also where it is important to articulate where data is 100% necessary to support the business. For example, Netflix’s business model is no longer viable without its recommender engine built on a strong data platform. Or, customer-centricity within the Amazon value proposition will not be a competitive differentiator unless predictive and prescriptive analytics are built into their logistics, product recommendations, and marketplace functionality. Given the close proximity of a data strategy to non-technical executives, it is most important to underscore the necessary link between the business model and data & AI.
Data Modelling & Engineering
I view data modelling as a nice technical bridge between business and data. But most organizations don’t think like this, and I have written about it before. Your data model should be built on the highest-priority business processes, which is derived from your business model. Have your architects and engineers consider how the organization creates and captures value. The conceptual data model they build should be a direct reflection of the business model processes.
Then, as you get further into the logical and physical data models, you know that the data foundations are being built on the same tenets of how the business operates. Ideally, this allows business leaders and stakeholders to understand how data supports the business model, as it is clearly mapped out. Engineering is the process of connecting those pieces from a data/technical perspective and actually operationalizing them, ensuring the data flows in a way that supports the business function.
Data Platform & Technology Decisions
Too often, technology and tooling decisions are made in an ad-hoc, piecemeal way. Obviously, it is hard to continuously build your data platform and tech suite in a fully strategic, planned way, but it should be informed by your business model about where and how you invest in technology. And in today’s world, core technologies are required to stand up different business models (e.g., CRM for any sales organization, ERP for manufacturing and logistics, etc.). This is a no brainer, and is the obvious link between business models and your initial technology decisions.
That next level of thinking gets into how technology enables your company’s competitive advantage. For example, do your business processes require real-time streaming platform, or can it make do with batch processing? Or how do you design your data platform/ tech stack to optimize for interoperability between those core technologies, adjacent technologies and the overall data platform? This article doesn’t have the answers, but I want to underscore that by starting with the business model, you can better identify the most important technical requirements and evaluate tools against those, rather than relying on a sleek vendor pitch or generalized analyst report.
Data Use Cases & Analytical Products
Like data strategy, how data use cases and products link back to the business model should be fairly clear. The simplest question is “does this product help us create, deliver, or capture value better?” For each business model there are the use cases and products that add so much productivity and functionality to the business teams that it is a no brainer to build or buy them. For reference, I alluded to several of these in last week’s article and in my data products article series.
Unfortunately, choosing the right use cases & data products is easier said than done. Most companies have way too many dashboards, and business teams get lost in the mess. Or the tools aren’t built to the right requirements that deliver value to these stakeholders.
Hence, use the business model as a compass to point you towards what is the most important thing to build, and keep sense-checking with business users with this in mind.
Data & AI Culture and Literacy
Most data culture and literacy programs focus on tool training or how to read a dashboard. This misses the bigger gap and opportunity.
A strong data & AI culture or a literate organization uses data effectively to enable the business model and processes. So any culture and literacy program should instead be based on the business model.
Of course, tools and skills are still part of data & AI culture and literacy, but they need to be framed as approaches to more effectively use data & AI to deliver value to the organization. Or make more money. Or drive its competitive advantage. Then articulating how data & AI fit into that business model and business processes so that individual employees can better live a data-driven culture that every company aspires to.
Data & AI Governance
I’ve written extensively about data & AI governance as a strategic enabler, which is why I’m probably one of the only people to say it in the same sentence as business model. As mentioned above, your business model should articulate how your company uses data & AI to advance its goals. Therefore, any governance framework should include this nuance.
For example, the business model will determine whether a company needs to manage its data with compliance top-of-mind or how far-reaching data standardization needs to be. It will also tell you what data matters most, who needs access, and what the risks are. Similar to data modelling and engineering, the business model and processes will help the governance team prioritize efforts on the data assets most critical to how the business operates. And given that most governance teams are understaffed and overworked, that direction is extremely helpful.
Making This Real
All of this sounds logical on paper. The harder part is operationalizing it and getting your data team to actually think and work this way on a day-to-day basis.
Here are six practical steps to make it happen:
Map Out the Business Model with Leadership — Answer the three core business model questions with your senior leadership team. What does the business do, how does it make money, and what’s the differentiator? Then translate that understanding down to the data leadership team and ensure it’s properly documented and well understood. If your data leaders can’t articulate the business model, they can’t build for it. This should be revisited as the business evolves (i.e., if AI changes the business model/ operations).
Align Data Domains with Business Model Components — In coordination with your data teams, make sure each person knows how they support the business model. Data leaders/ directors should be accountable for this, and managers should enforce it. The end goal is a tangible reference point that connects every data activity to the business.
Anchor Data Initiatives to Business Processes — Roadmap the highest-priority business processes from the business model perspective and let those guide the data team’s initiatives. Every active data project should be able to answer the question: which business process does this support, and how? If the answer isn’t clear, question whether it should be a priority. Again, data domain leaders should be accountable for this!
Embed Business Context into Data Team Rituals — Sprint planning, quarterly reviews, and backlog prioritization should allude to business priorities. It may not be the main focus, but there should be some references back to the business model and processes. This is also where it may be beneficial to invite business stakeholders to data team planning sessions. This is about creating the processes to ensure the data team’s work stays connected to what actually matters.
Develop Business Acumen throughout the Data Team — With AI handling more of the coding and technical work (hello, Claude Code…), data professionals should spend more of their time understanding business processes and translating them into technical requirements and architecture. Invest in this through secondments, cross-functional delivery with business teams, shadowing commercial functions, and attending leadership sessions. The best data professionals I’ve worked with understand the business as well as they understand the tech stack.
Create a Shared Language and Strategic Alignment — The language gap between business and data teams is a major barrier to progress. The business model can help bridge that gap. Ensure the data team understands the vocabulary, documentation, and strategic context they need (e.g., KPIs, business terms, strategy documents, customer journey maps) to do their job effectively. When a data engineer understands the strategic reasons for modelling the data or building a pipeline in a certain way, their work becomes inherently better.
The Benefits of Business Model–Led Data Thinking
I’ve been alluding to the benefits of a clear understanding of the business model for data stakeholders throughout this article, but the impact really does compound.
First, you get better prioritization. Data projects often translate to whatever sounds most interesting or which stakeholder shouts the loudest. So by evaluating which initiative most directly supports how the business creates and captures value, you can better prioritize your limited data resources and ideally achieve a better ROI.
Second, there is a clear path to stakeholder buy-in. When data teams speak the language of the business, executives and business functions are more likely to engage and work to make it succeed. From the business model frame of reference, the data team has the vocabulary to make that translation and get the buy-in.
Third, better built data products and outputs. This is a catch-all of sorts. But to be fair, when you have a clear direction to the business model, prioritized initiatives and stakeholder buy-in, it becomes way easier to build analytical products that drive tangible value. These products answer questions that the business is actually asking and needs for its operations. The business model alignment acts as a filter, preventing your team from building things no one will use.
Fourth and finally, cross-functional collaboration. The business model is the one thing every department shares. It ladders up to what matters most and using it as a common reference point breaks down the silos between data, commercial, operations, and finance teams. In the end, you get a shared “so what” that ideally transcends departmental interests, creating a culture of cross-functional delivery. Also, this multi-stakeholder collaborative approach feeds back into better prioritization, demonstrating the flywheel effect that thinking from this perspective creates.
We Still Aren’t Done
Six months ago, I would have stopped there, at the data implications.
But the world has changed drastically since then and there is a bigger question looming. With the advance of AI, what happens to your business model, and how might that change?
Right now, most companies are bolting AI onto existing structures and adding tools without rethinking how the business operates. In the next and final article in this series, we’ll explore why that’s a mistake and introduce a different way of thinking about it: AI Systems Design. Business models, org structures, and operational systems were never designed for AI; they need to be refactored to align with where leaders want them to go and where the world is heading.
Moreover, if you want to think about these topics more thoroughly, reach out, as I’m conducting workshops with companies on exactly this! Don’t run into this AI world blind; approach it strategically and purposefully!
See you all next week, and have a great Sunday!
Thanks for the read! Comment below and share the newsletter if you think it’s relevant! Feel free to also follow me on Substack, LinkedIn, and Medium. See you amazing folks next week!
Great start of the new blog journey. I miss the different architect roles positioned though: EAs, BAs, Domain Architects and eventually Solution Architects. Of course all benefit from a solid understanding of how (and why and when…) a business makes money. The analytical and the operational roles are converging. So perhaps the architects’ toolbox should be brought to attention to bridge the contextual/cohesive gaps.