ArgonDigital - enterprise automation experts

Share This Post

Business Data Diagrams – the LISP of requirements models?

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.

Business Data Diagrams – the LISP of requirements models?

More To Explore

AI to Write Requirements

How We Use AI to Write Requirements

At ArgonDigital, we’ve been writing requirements for 22 years. I’ve watched our teams waste hours translating notes into requirements. Now, we’ve cut the nonsense with AI. Our teams can spend

ArgonDigital | Making Technology a Strategic Advantage