Business Data Diagrams – the LISP of requirements models?

Share This Post

It’s been argued in programming communities that all programming languages can ultimately be abstracted back to LISP.  As a software developer, you may not care that we can ultimately abstract Java into LISP, but the fact that you can tells us some fundamental truths relating to the nature of programming. It makes me wonder, in the business analysis world, do we have a single model that all others could be translated to as well??

BDD_exampleThis week, I started asking colleagues “What is the model that you would use to model our models?” The one model that we kept coming back to over and over again was the Business Data Diagram. If I wanted to describe to someone what an org chart was, I’d probably need to do so in terms of a BDD. If I wanted to describe a state diagram, I’d be thinking about the relationship between states and connections, and I could do so with a BDD.  I could describe process flows and data flow diagrams as BDDs.  Ecosystem map? Describe it with a BDD.

So we can describe most of our models using a BDD – but what does that actually tell us?

I think several conclusions could be drawn, but the important thing is that it highlights a fundamental truth about models: our models all represent relationships between different objects. I think this eloquently defines the difference between a visual representation of a system using models versus a long text listing of requirements.

More To Explore

It’s a Matter of Trust

The combination of pandemic and moving to a rural community has increased the amount of shopping I do online, but even before those events I found myself depending more and

Thoughts from SAMA

I was recently able to attend the San Antonio Manufacturers Association Trade Show & Conference (SAMA). Like all live events I have had the pleasure to attend this year, the