Or conceptual architectures? This question – and my answer – was prompted by Peter Bakker‘s post Factual Architecture! Basically, my understanding of Peter’s criticism is that he thinks that concepts are too abstract – don’t connect with audiences, and don’t connect with reality. He contrasts this with “factual architectures” – whatever they are. I’ll respond directly to Peter’s post on his site, but here I’d like to defend the notion of conceptual architectures and conceptual analysis in more detail than I have done in my two other posts.
Why do I disagree with Peter? Why do I think that conceptual architectures are valuable? The simple answer is given in the classic Gang of Four song “Why Theory?” – as the song says: “Each day seems like a natural fact/but what we think changes how we act”. That is to say that concepts change what we view as facts, and they change how we act – in this case they change how we view the world, describe the world and architect our solutions.
Part of this critique of un-analysed “facts” is the belief that when we discuss things we are always doing so in the context of an implicit theory, an implicit conceptual framework. The point of conceptual analysis of the sort that I am engaging in is to make that theory and that framework explicit, so it can be critiqued, so that its assumptions can be exposed.
A conceptual architecture gives us a framework for looking at a problem, and describing a solution that is neutral between implementations. Unless we have this, how can we compare different possible implementations of the solution? In particular it allows us to see whether a particular implementation is a complete solution. I have seen many enterprise IT solutions that do not include all of the necessary elements to address the problem because of a lack of basic analysis and description.
A conceptual architecture sits on one end of a continuum from a conceptual architecture through an executable architecture through to an implemented solution. It is not the full answer – not even close. It is just the start of telling the story – but in my mind it is an essential part. The reason that I write posts on conceptual architectures is that I see many examples of technology or deployment architectures. I come across many descriptions of how to connect or deploy vendor products to deliver a certain solution, but rarely do I come across a full description showing why the solution exists, and why it takes the form it does, what functions the solution is performing. These are the items that a conceptual architecture addresses.
.
