Monthly Archives: March 2014

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.

Update:

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.

Advertisements