Business Language Driven

AI is bringing back the art of discovering business reality, business language, core business concepts and core business processes

Few things are really new, sometimes we just need to remember the valuable things we used to do in our previous Ways of Working.

DORO : Define Once, Reuse Often

As I prep my presentation for Data Day Texas in a few weeks and also work on content for both the Pink and Blue Books I find that I am browsing, referring and reusing patterns and patterns templates that I have found, refined or defined over the last decade or two.

My method of storing these are ad-hoc at best, I think this year I will try to put them all into a Obsidian repository and then hooking up something like Claude to see if it makes finding and reusing things a little easier.

The results of that experiment will be a post for a different day, for now I find browsing the slides I have used for the many presentation, training and mentoring sessions I have delivered over the decade the best place to find things I can potentially reuse.

And as I do that I realise there are a few foundational slides that I use repeatably.

Some of these are the “maps” I have documented briefly here:

Intro - Agile Data Way of Working Blueprints

Problem People Diagrams

Business Language Driven

Another piece of content I reuse a lot is this slide:

I use this slide in almost every presentation I do that relates to data work or data modeling.

From memory this slide was based on content from Lawrence Corr that we reused as part of the one day “BEAM” course we developed and delivered as part of OptimalBI in NZ, the data and analytics consulting company I founded a few decades ago, .

It shows a fundamental principle that we apply as part of the Agile Data Way of Working.

The principle is we work with data by first focussing on the Business Language and then focussing on the source systems data structure or reporting needs after that.

I have talked to this slide many many times, but never actually created a reusable description for the principle itself.

The principle of being Business Language Driven

So let’s have a go at creating an initial definition now.

Using the Pattern of the Agile Manifesto

Here is a definition of the principle using the pattern from the Agile Manifesto:

Business language grounded in business reality

The highest priority is to define and deliver information using the language of the business as it actually operates, so actions are based on shared understanding rather than system or technical abstractions.

Using the Pattern of the Agile Data Blueprint

A component of the Agile Data Blueprint I deliver for organisations is a list of Data Management principles. These are documented using a pattern I think I got from TOGAF.

Here is defintion of the principle using that pattern:

Name
Business Language Driven

Statement
Information, data and actions are expressed in the language of the business as it actually operates, not in the language of systems or technology.

Rationale
Using business language anchors data work in business reality, reducing misinterpretation, rework, and translation overhead between teams. When data work reflects real business concepts and behaviour, teams align faster, reduce translation errors, and achieve better outcomes.

Implications
Stakeholders must invest time to assist in clearly identifying, defining and agreeing core business concepts and core business processes, while Data Teams must design, model and name data using those definitions consistently. This may require additional upfront collaboration and discipline, but it lowers long-term costs by simplifying communication, improving trust, and increasing reuse across analytics, reporting, and automation.

*Both these definitions were created with the assistance of my ChatGPT friend for the initial version and then edited by me.

IMHO both these definitions still need a few more iterations to tighten them up.

Information Value Stream

If we think about the pattern of Business Language Driven from the lens of the Information Value Stream:

The source system data structures and the last mile reporting requirements all sit on the right of this diagram, ideally in the Design step, but often in the Build step.

We want Data Teams to start by focussing on the left hand side of the Value Stream.

I keep wanting to use the term “Data Product Team” instead of “Data Team” as I write this content but in reality it is just Data Teams applying product patterns and pattern templates. They are still a Data Team.

• We want them to understand the Problem that needs to be solved.

• We want them to Ideate with Stakeholders on the options to potentially solve it.

• We want them Discover which of those Ideas is the most Valuable, Usable, Viable, and Feasible.

• We then want to prioritise the value of solving this problem compared to the value of all the other problems we could solve first.

To do these things we need to use Business Language not the language of the source system structures or the last mile reporting requirements.

Stakeholders either don’t know, understand or care about the source system data structure.

They understand and care about the Business Reality. They speak in the language of the business, not the language of the data structures or the technology.

With help Stakeholders might be able to articulate the Core Business Concepts and Core Business Processes that are contained within that Business Reality. Data Teams should count themselves lucky if they do.

Different data practitioner personas, different language of requirements

In my experience each of the data practitioner personas typically have a language to capture requirements based on their preferred way to work.

• Personas that align with that of a Data Engineer will often start the process of understanding the requirements by wanting to review the structure of the Source Systems which the data that is needed is created within.

• Personas that align with that of a Data Scientist will often want to follow a pattern based on Exploratory Data Analysis (EDA) starting by exploring the data values themselves.

• Personas that align with that of a BI Developer will often want to start by wire-framing the final Information Product delivery type, for example a Dashboard.

• Personas that align with that of a Business Analyst will often want to start with documenting and understanding the business processes.

Stakeholders will often align with the persona that best matches their career path or will default to wanting to start by describing the final Information Product output, such as the Report or Dashboard they want to use.

Data Teams have trained Stakeholders wrong

One of the mistakes we have made as data practitioners over the last few decades is teaching Stakeholders to talk to us in the language of Reports and Dashboards.

When Data Teams ask a Stakeholder what their “requirements” are, Stakeholders will often describe the Dashboards they think they need delivered. They are giving the Data Team a solution as a requirement not the problem to be solved.

That is not the Stakeholders fault.

Data Teams have trained them to think in the language of Dashboards, as that has been the hammer they have delivered to hit every little nail, aka every problem the Stakeholders have.

Data Teams have trained Stakeholders to be fluent in the language of the data platforms most common last mile delivery type, rather than the Data Team learning a new language.

This focus on legacy dashboards to define requirements and deliver solutions will bite Data Teams in 2026 as data platforms move away from legacy BI tools that build multi use Dashboards that are reused to solve multiple business problems and towards GenAI generated “One shot” BI Apps that solve a single problem well, and is not reused for anything else.

Missing T skills

Another common problem that drives Data Teams to focus on source system structures or reporting requirements, rather than Business Language and Business Reality is the loss of “Business Analysis” skills from the core Data Teams.

I wrote about Skills vs Roles a while ago:

Team - Skills vs Roles

And as part of that I talked about the shape of skills in a data team.

*I think its probably about time to review this list of skills and see if it needs to be iterated.

If you look at Data Team members who have traditionally have a role of Data Engineer or BI Developer, you will see skills similar to the diagram below.

Compare it to the typical skills for somebody that typically had a role of Business Analyst below.

People with a Business Analysis background and these set of skills typically engage with Stakeholders a lot more than people with an engineering background and as a result seem to use business language more often.

When I am working with a data team for the first time, I can often guess the language that team will use based on the primary skills or roles in the team.

Or I can review the things they produce and the language used within those things and guess at the primary roles and skills within that team.

Metadata Driven Information Factories

When I talk to data practitioners about being Business Language driven, they will often jump straight to the pattern of metadata-driven development.

As I was writing this article I did a LinkedIN poll on this.

https://www.linkedin.com/posts/shagility_as-a-data-practitioner-are-you-code-driven-activity-7414943978749480960-EgPO

In the post I wrote:

As a data practitioner are you code driven or metadata driven in your way of working?

Do you write code that creates the data structures you need.

- And then use those structures or that code to create the “map” of the data model those structures represent.

Or do you define the data structures as “metadata” and have code that reads that metadata and then automatically creates the structures.

- And then use that metadata to create the “map” of the data model those structures represent.

(I tried to abstract a whole bunch of different context languages into 2 simple patterns above, did a so so job)

I have been in the data domain for enough decades to have watched metadata driven data tools emerge and die with each new technology wave.

Our AgileData.cloud product is a form of a metadata driven capability, with a sprinkling of business language.

As the pattern for Context Planes start to emerge to support GenAI patterns, I think we will see these tools remerge.

But they will contain Context in the form of Business Language rather than metadata in a language of technology.

I look forward to the day we can capture this Context using the language of the business reality, and that powers the creation of the other languages for us automagically.

In Summary

One of the reasons I write is to help me think.

Sometimes I can sit down and write quickly and with clarity, as its something I have thought about for a long while and something I have taught other people.

Sometimes it is a new set of patterns or pattern templates and I yet to have clarity, so i write to think and iterate towards that clarity.

When its the latter I use a constraints model, I time box the content, to stop me going down endless rabbit holes.

This article was deffo the latter.

But the intersting thing is its based on a slide, a piece of content, a pattern, I have used for years.

So the fact that I still don’t have clarity on that pattern, is a surprise to me.

And means it probably never resonated with anybody else when I used it due to that lack of clarity.

In the famous words of the Terminator “ill be back” on this one.