Business Data Diagrams – the LISP of requirements models?

ArgonDigital - enterprise automation experts

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

b2b auto pay

B2B Auto Pay: Automation Use Cases

Migrating a B2B “Auto Pay” Program Companies migrating to SAP often have daunting challenges to overcome in Accounts Receivable as part of the transition. You might have different divisions running

ArgonDigital | Making Technology a Strategic Advantage