@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.

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