My work has driven me to considering activities before static structures – when talking about organisations and software-intensive systems.
An organisation’s purpose is fulfilled and value is created by carrying out activities. Static structure does not usually create value by itself but supports these activities.
Some people seem to be less invested in activities than in systems or organisational units, which sometimes makes conversations about activities easier, more frank and less ‘loaded’ than conversations about systems or organisational units – especially so early in an engagement.
In effect, I initially treat static structure and the assignment of responsibilities to it as an implementation detail. This helps with creating a shared understanding of these activities and makes discussing the (re-) assignment of responsibilities easier.
For me, this works in analysis and design.
This still feels odd to me even though I’ve already written about it in Functional flow and structural composition in 2014.
Perhaps this is due to heritage: I came of age professionally when Kruchten’s 4+1 view and RUP were a thing (much value there, no dis). For some time, my environment encouraged – probably unconsciously – given short shrift to the the use-case view and digging right into the logical view and structural decomposition. I was working in C++ and Java at the time.
Interestingly, my professional upbringing was different: as far as I can recall, writing Delta COBOL on a mainframe was all about procedures and data, which led to a different problem.
Of course, there are German words to help with this: when discussing Organisation we distinguish Aufbauorganisation (structural setup) and Ablauforganisation (process).
Mostly in government agencies, we distinguish an Allgemeine Aufbauorganisation (general organisational setup, eg your regular line organisation) from a Spezielle Aufbauorganisation (special organisational setup, eg a project).