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? 🙂
I love the title, and the post!
Regarding the pertinent questions that are omitted: I worry along, and wrote a ranty post on that (http://www.martijnlinssen.com/2009/12/architecture-as-pressure-cooker.html)
I also worry about the different goals in an enterprise: project versus lifecycle, with the balance shifting from time and money spent on intitial project delivery, towards maintenance phase. Jotted down my thoughts on that as well (http://www.martijnlinssen.com/2009/09/perfect-business-application_17.html)
Arhcitecture is no goal. There’s only one goal out there: satisfied customers. Everything else is a means
Agree completely – see my blogpost on So-Called Non-Functional Requirements http://tinyurl.com/ykkqc4u
ere ere but you may remember an fbm…
Forming an information model, analyzing and engineering business processes/rules are very important tasks of an architect. These are clearly focusing on what/how and “functional”. So how can we say architecture is “non-functional”?
@Martijn – many thanks for the links – very strongly agree with the points you make, and the checklists in the ‘Perfect business application’ posts are very useful indeed.
@Richard – ditto for your blogpost on ‘So-Called Non-Functional Requirements’ – strongly agree with your points there, especially the suggestion that, architecturally speaking, the ‘non-functional requirements’ are often more important than the so-called ‘functional’ ones.
@Peter – yup, I do indeed remember a certain FBM. 🙂
@Iyigun – my apologies, possibly a slight miscommunication here on my part. The point I’m making is that in terms of change-management, almost all of architecture work falls into the ‘non-functional’ category – its focus is on quality (in the broadest sense of that term) rather than on the function of change-management itself (which, as per Sam Ishak’s table, is more the province of the Project Manager or the like). So yes, we do indeed explore function and the like, as you say; but the details of that function ultimately derive from the ‘non-functional’ requirements, as Richard explains well in his post. (As we move down towards implementation, we shift from architecture to design: and yes, design is arguably more focussed on function – but the post was about the role of architecture, and whilst architecture and design are best understood as flip-sides of each other, they are _not_ the same.)
As a quick ball-park of the relative importance to architects of ‘functional’ versus ‘non-functional’, note that in the architecture-framework I use (see http://tetradianbooks.com/2008/12/silos-frame-ref/ ), ‘function’ is just one of six main categories of ‘primitives’. (IT-functions in turn represent a variable-sized subset of just one of four categories of function, which means that in a true enterprise-scale architecture, IT itself should typically occupy no more than perhaps 2-5% of the total attention – which might help to explain why I and others are so insistent that IT-centric approaches to enterprise-architecture are not a good idea. 🙂 )
Hope this helps – and thanks again, folks, ’tis much appreciated.
Pandora’s Box is a-opening: According to PMBOK, PM is responsible for quality and its compromises being driven to completion. Prince2 is a little different as it requires SMEs to bring out issues with Quality. Therefore I am finding Architecture is the framework over which understanding of business context can be shared and therefore quality negotiated. I’ve heard Execs and SMEs say their ‘PM’s dont understand’ and PM’s say the same thing because of detail and the fact that PM’s are there to drive. Use Architecture to clarify quality impacts so that benefits (prine2) remain secure. Closing the box.