Architecture is non-functional
Architecture is non-functional.
I’ll bet that statement raised the blood-pressure a few notches for some folks, yes? Defensive? Irritated? Sarcastic? “Waddayamean, non-functional, hey?”
Good point, because ‘non-functional’ is not the same as ‘has no function’ – although it’s often misread that way…
The problem all stems from an arbitrary and amazingly unhelpful categorisation of project-requirements as either ‘functional’ or ‘non-functional’. In this case, ‘functional’ means ‘what the project/object/thing/whatever does‘, whilst ‘non-functional’ is a generalised grab-bag for any requirements about anything else at all. But because ‘functional’ implies ‘useful’, or ‘working’, whilst ‘non-functional’ kind of implies ‘not-useful’ or ‘not-working’, this categorisation means that so-called ‘non-functional’ requirements are often assigned a much lower priority, or even ignored altogether. Which is not wise, because ‘functional’ requirements only cover the ‘what’ and ‘how’ of a project – and usually only a subset of ‘what’ and ‘how’ at that. Everything else is probably classed as ‘non-functional’: when, where, who, how much, how well, how often, and so on – and ignoring those needs is not wise at all. (The one question that’s often missing from any list of requirements – ‘functional’ or ‘non-functional’ – is why: sometimes it seems that people automatically forget how to ask pertinent questions once ‘The Requirements’ have been defined…) Which is a worry – to say the least.
But there is another way to view the notion of ‘non-functional’ – an alternative term that much better describes the real meaning or purpose of those requirements, and the architecture role with it. I was reminded of this as I skimmed through the presentations at the the current Open Group Enterprise Architecture Practitioners conference in Seattle, and came across the following table in a presentation on ‘Business-Driven IT Strategy‘ by Sam Ishak of First Canadian Title:
The ‘role’ row caught my eye because the same ‘driver/navigator’ metaphor had been used by several people in yesterday’s discussion on strategy. But then I noticed the ‘responsibility’ row – and a light-bulb lit up in my head: “Govern the quality of the solution”. The project-manager deals with the ‘functional requirements’ for the project itself; the architect deals with all the other ‘non-functional requirements’, ensuring that the end-result is not merely efficient in a functional sense, but effective overall. The PM ensures that the end-result works, within the available time and budget; but the architect ensures that it is useful – which is not a trivial matter at all.
So a more general term for ‘non-functional’ is qualitative – ensuring that whatever-it-is not only works, but also does what we want, how, where, when, with whom and, especially, why we want it to do so. There’s not much point in any focus on function alone without also including those qualitative concerns.
Architecture is about quality. Architecture is ‘non-functional’ – and that is what is should be, because its purpose is to “govern the quality of the solution”.
So yes, architecture is indeed ‘non-functional’. But perhaps we ought to be more openly proud of that fact? 🙂