Tag Archives: context

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.

Use cases in lean architecture

James Coplien and Gertrud Bjørnvig have written a wonderful book explaining how lean architecture can play a meaningful role in agile software development. Here they describe the benefits of use cases “as a way to capture what the system does when it is important to understand a sequence of work towards a goal in a context” (Lean architecture for agile software development, ch. 8.2).

The notion of a sequence of work towards a goal in a context resonates strongly with me: it’s a brief and–to  me–powerful way of tying what needs to be done to context and purpose.

I have been working on e-commerce sites for the last few years. Much of the work has been driven by conversations about user journeys or user interaction flows (or whatever you’d like to call this).

I suspect that interaction flow descriptions/visualizations and use cases might well complement each other, but I haven’t yet seen them being effectively used together. I’d be grateful for your thoughts, experiences and suggestions.

Notes:

When I say “use cases” I refer to the Alistair Cockburn tradition.

James & Gertrud more often used the phrase “a sequence of tasks…” than “a sequence of work…”. The latter seems preferable to me as it seems applicable in a much wider context.

If they can do it, why can’t we?

Sooner or later, but inevitably, this questions seems to come up  when developing digital services:  someone requests a feature,  the team responds that they can’t easily implement it, and the requester states: “Well, website xyz has this feature, why can’t we have it?” Things rapidly get worse when an implication of incompetence is perceived.

Whenever this question comes to mind, it might be useful to ask ourselves a few questions:

  • Are xyz working in a similar context?
  • Are xyz pursuing a similar purpose?

Context may include organisational policies, available technology and the ease of changing this context. Purpose may loosen or tighten constraints on available funding or the selection of (potentially controversial) means. (Dean Bubley tweeted about context and purpose in networking, I touched on it here.)

It might be beneficial to remember that we usually don’t have any idea how much it cost xyz to implement that feature, or how long it took them. It is also not clear that xyz’s feature, i.e. a solution to one of their problems, is necessarily a good solution to our problem.

So, if we really want that feature, we need to sit down with the team and take the time to truly understand what makes it difficult, slow or expensive to build. Often we might be able to clarify goals or accept constraints that will make implementing (a version of) the desired feature feasible. Or, together with the team, we might discover other, perhaps even better, options.

Let’s just not assume the team is full of half-wits.

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.

 

Updates:

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.