Tag Archives: structure

Activities before static structure

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).

Functional flow and structural composition

Architectural descriptions of software-intensive systems often begin with a description of the system’s structural composition. This technical inside-out perspective has made me feel uneasy for quite a while.

In contrast, I like to take an outside-in perspective and begin describing a system by discussing its purpose and the context in which the system will be used in pursuit of this purpose. More concretely, I like to talk about a system’s functions and how work flows through the system when exercising these functions. Working mostly on e-commerce sites, this often means describing user journeys and interaction flows.

And eventually I describe which structural elements collaborate in order to realize these functions. At times, the required mapping of functions and interactions to interacting components and collaborating objects feels tedious and strained.

As I’m learning more about functional programming, I wonder whether describing the architecture of a system built using a functional programming approach will feel more natural? Will the rift between the functional and the structural perspectives diminish as I gain experience with composing functional solutions to non-trivial problems? Or should that read functionally decomposing non-trivial problems?

Related posts


Also see Function & information: a useful duality? on my previous blog, On Service Design.

What the system is, does and knows?

In Lean Architecture for Agile Software Development, Getrud and Cope describe a system’s architecture in terms of what the system does (function) and what the system is (form).

(As a side note, their work includes the only substantial discussion of form (as distinguished from structure) of software systems I have come across so far.)

But what about the information managed by the system? Wouldn’t we also want to discuss what the system knows (in a casual sense of the word)?

Architecture descriptions (at least most of the ones I’ve seen) tend to discuss relevant data or information models in the context of a system’s structure (i.e. its major building blocks), but that never felt quite right to me. Or is discussing what the systems knows unnecessary because we could include data capture, storage and retrieval in the context of a system’s function?

I’d love to hear your views on this topic.


2014-04-06: Function & information: a useful duality? might be relevant in this context.

2014-03-16: Clarified that I used “what the system knows” in a casual sense. This may not have been a good idea — see the comments below.

2014-03-15: Correction: Form describes what the system is in this book, not structure. Also added “major building blocks” to somewhat clarify what I meant with “a system’s structure” in the last paragraph.

Yet another architecture definition

A system’s architecture is the shared understanding of this system’s purpose, context, function, form, structure and characteristics.

A system’s architecture results from planning, designing, building and sustaining this system.

In hindsight, mental model probably would have been a better term than definition.

The above was inspired by the thinking behind http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf and http://en.wikipedia.org/wiki/Architecture.


2014-04-26: Gene Hughson wrote about Architecture vs. Design at Iasa Global and Like it or not, you have an architecture (in fact, you may have several) at Form Follows Function.
2013-11-30: Added form, made function singular.
2013-11-09: Added characteristics to the definition. Stated mental model may be a better term than definition.