Our industry seems to go through cycles of re-discovery of lost knowledge with every new generation of developers, which probably is not so odd considering the exponential growth of practitioners. Allegedly half of the programmers today are juniors, which means many of them have yet to encounter the challenges faced decades ago. For example, many run the risk of falling into the trap of modelling services around domain entities, risking ending up with a distributed monolith with its devastating coupling, fragility, and cognitive nightmare. Lucky for us, we have shoulders to stand on to get us out of the quagmire, or even better, prevent us from getting on that slippery slope in the first place. Being conscious of fallacies like those of distributed computing and anti-patterns like functional decomposition and entity services are all well and good, and necessary heuristics to good service design, but we often crave more concrete guidance. There are many great techniques to consider, like context mapping, user story mapping, event storming, and value chain analysis, but in this talk I will focus on the lost art of business capability modelling. My thesis is that a technique that was relevant in the pre-computing era might be just as useful and relevant when we split our monoliths into a mesh of autonomous (micro)services. Maybe they even could help us identify subdomains, contexts, and organisational structure; in effect the construction of sociotechnical systems?