When I started my law firm, I thought everything I knew about a client matter needed to be in "the file". I wasted a lot of time moving things that were perfectly fine where they were. I realized that "the file" was a naive metaphor I took from law firms pre-cloud. That changed my outlook about data models. I don't want my digital model of things to mimic the real world artifacts involved, and spend a lot of time trying to explain to my colleagues that just because a person files a motion by delivering a real or digital pile of pages with real or digital ink on them doesn't mean that the document and the motion are the same thing. A motion doesn't have a page orientation, and a document isn't potentially vexatious. But when I argue that we should be modeling the domain, not only the artifacts, my colleagues — who are all also former lawyers — don't seem to disagree so much as act as though I'm speaking heavenly script. Does anyone have any tips for persuading people who haven't been converted to the wisdom of domain modeling that maybe our systems should deal with the things we care about, and not only the things we can download or touch?

I would talk about how crime detectives resort to knowledge graphs to identify patterns. Graphs are where it's at. Every other artifact is lossy and should be derived rather than be the source of truth.

I have the same problem with explaining domain modeling to my colleagues in computational science. What I try, with mixed success, is to say that I want people to interact with computers using the same concepts that they use to communicate with each other. The mixed success is probably due to a change of habits in what I see as the wrong direction: people start to talk to each other in terms of files and programs. It is normal nowadays to see journal articles state "we analyzed the data using the FOOBAR program suite" rather than "we computed a time correlation function".

@Nilesh Trivedi oh wait, what, evidence boards are real and not just an invention by hollywood? TIL!

I wonder if an evidence board is sort of not at all what I want them to be thinking about, because an evidence board is a graph of physical artifacts. I want a graph of abstract entities. You can't pick up and pin someone's lawsuit to a cork board. 😂 I did make a little progress today with drawing pictures. But so far what I have achieved is bemused tolerance, and what I'm looking for is enthusiasm. 😉

If you learn how to get abstraction-averse folks to address boundary objects as signified and not as signifier, let me know. I yearn for this technology too. But I agree that drawing pictures together is our best stop-gap in the meantime.

@Nilesh Trivedi I'm a police detective; knowledge graphing is mostly done on "i2 charts". The market leaders are things like Chorus and Analyst's Notebook. I am personally a big proponent of doing it in pen on whiteboard, if there is more than one person working on the investigation. I think this has big benefits à la Bret Victor's "Seeing Spaces". @Jason Morris for sure you need to demonstrate real value that they don't already have. You must have some complex interlinked cases/clients that are impossible to "cut" nicely...? If you can't do this then I'd query whether the current model is actually deficient in a real business sense. I made a thread a while ago asking for examples for an Information Management version of 7 GUIs where people made some good suggestions about really gnarly edge cases. I think about this sort of thing a lot. I think it will probably end up being my life's work once I'm bored of dealing with people 🙃. I remember a long time ago the presentation that announced Metasploit was titled Hacking Like In The Movies; I have a long-running background brain process working on equivalent (Crime Detection Like In The Movies). I often watch things like Sherlock and think "There's no magic here; you could actually make deductions like this if the right databases existed". I think the perfect system lets you be simultaneously loose and detailed about the taxonomy of your domain as required, and seamlessly go back and enrich entities without breaking anything.

@Chris Knott The version of this problem I most commonly encounter right now is "with the right prompt engineering, we can get the LLM to do X". Which is true, but "the right prompt engineering" means reducing the problem to parts the LLM is competent to handle. And those parts could be reused at different steps in the process. But the value of having and reusing that structure hides behind the idea of "prompt engineering", and they can't see that under the hood it is actually domain modeling. So it's not that they don't see the need to build a tool, they just don't see the need to build it this way.

Do you need to sell the domain model then? It's just an implementation detail that lets you Avoid Risks with using a "raw" LLM. I'd just say;

we can't risk using an LLM at the moment because how it thinks is a black box. When it learns it develops "concepts" of some sort, but we can't know if these internally categories are, for example, illegally racist. We need to develop a shared intermediary language that both the LLM and technical users can read and understand. This will let us check and control the LLM's thinking