‘Seems’ is a very large part of what causes complicated systems to fall into true-complexity. ‘Seems’ is what causes ‘rampant feature-itis’ and the like – “just one more feature, ple-ee-ease? – it won’t make any difference, will it?”, and so on. The difference between ‘seems’ and ‘is’ is what we’re really trying to tackle here…

And as you say, scale is one very good example of how a ‘non-functional’ requirement can easily end up dominating the ‘functional’ needs.

Great points – many thanks.

“They’re very short-termist. They want to create a quick impact …[and] are very naive about IT systems and the cost of IT staff, so they’re taken for a ride by very bright people who earn very large salaries in the private sector running these companies.

“Ministers come they go and they add onto these things like a Christmas tree. You need one simple – piloted – [system] … you stick to it. Rough-justice politicians just keep changing their minds – constantly new ideas – and of course they are just playthings for the private sector.

http://www.computerweekly.com/blogs/tony_collins/2010/03/bright-people-at-it-suppliers.html#more

Sometimes it seems easy enough to plug in new functionality – until everything else falls over. Like when Van Halen plugs in another bass guitar and the electricity substation catches fire. Easy for someone, but a nightmare for someone else.

There are two contrasting scenarios here. One is that the architects have done an unusually brilliant job at the so-called non-functional requirements, allowing new functionality to be plugged in easily. This was the ideal vision I was describing in my book Component-Based Business – Plug and Play.

At the other extreme, new functionality is plugged in with insufficient thought for the non-functional implications, creating enormous problems for the architects and unexpected expense for the organization.

There are some interesting implications of this for organizational design. An organization structure that is designed to be loosely coupled can gradually become tightly coupled as the quantity of work increases. Here’s an example I prepared earlier.

Sometimes coupling is itself a consequence of scale. At low volumes, a system may be able to operate effectively in asynchronous mode. At high volumes, the same system may have to switch to a more synchronous mode. If an airport gets two incoming flights per hour, then the utilization of the runway is extremely low and planes hardly ever need to wait. But if the airport gets two incoming flights per minute, then the runway becomes a scarce resource demanding tight scheduling, and planes are regularly forced to wait for a take-off or landing slot. Systems can become more complex simply as a consequence of a change in scale.

http://rvsoapbox.blogspot.com/2006/04/loose-coupling.htm

In any case, many thanks for the question!

Quick answer, even if it’s in the wrong place: yes, the whole aim of a business-anarchist’s work is to help create new rules – but the process of _creating_ those new rules must, by definition, operate at least in part outside of the old ones. And when operating outside of the rules – the usual notions of ‘order’ – the ‘anarchist’ needs to rely on guidelines, principles and values: that’s really all that I’m suggesting here.

That’s about _implementation_, which occurs _within_ the organisation by a _development_ team; what I’m talking about here is _source_ for foundational non-functional requirements, which derive from _outside_ the organisation, as mapped by an _architectural_ team. Although they do ultimately intersect, these two concerns really are very different.

I’ll agree that that ‘unit of work’ stack is a good way to describe what the services/capabilities relate to, though. Will be worth coming back to that when we do look at implementation – though in my field that’s usually outside-of-scope for architecture.

and what about the anarchist that breaks the wall down and stretches the playing field? Aren’t they helping to develop new rules?

As you made non-functional characteristics very important, I tried to use this importance to clarify dependencies between capabilities, services and processes (a popular topic in Linkedin discussions). It seems that capability is a description of a unit of work. The latter can be implemented as a service (black-box) or as a process (white-box). If we use service option then some non-functional characteristics have to be validated during testing or at run-time. If we use process option then some non-functional characteristics can be guaranteed at design-time. Also process option provides definitions for lower capabilities.

Thanks again,
AS

I fear I’m still not managing to understand what you’re saying. I think you’re describing a different type of model, a ‘capability/service’ model?

All that the ‘steps’ or ‘layers’ mean here are in terms of boundaries of commitment – typically via an explicit or implied contract, such as (at step 3 / layer 3) the implied ‘social contract’ that every business has with its societal context. Every business-process occurs ‘within’ the organisation itself (i.e. inside of ‘step 0′ – hence implementation of process at a kind of ‘step -1′).

Business-processes touch different places within the respective layers beyond the organisation-boundary, but in terms of legal responsibility and the like, they mostly take place ‘within’ the organisation. (A variation of that occurs in outsourcing, where part of the process is effectively in what I’d labelled ‘step 1′, but the legal responsibilities – i.e. in terms of the definition of ‘organisation’ – primarily reside with the organisation, ‘step 0′.)

I think we’ll risk getting a bit lost here if we introduce any notion of process or implementation – this is solely about values and the like, as the ‘external’ sources for business-requirements.

I think, that in this context my ”step 4” is not “step -1” inside “step 0”.

Thanks,
AS

My apologies, but I suspect there’s a slight misunderstanding here. [I've now put an update into the text above to resolve this.]

I’m not talking about development-sequence – i.e. how we use functional or non-functional requirements – but about the relationship between ‘organisation’ and its layers of enclosing ‘enterprise’ – i.e. the sources for those requirements.

The ‘steps’ are actually steps outward from the boundaries of the organisation-in-scope. An implementation takes place within the organisation-in-scope.

Although we probably wouldn’t describe it as such, your ‘Step 4′ implementation would thus be more like ‘Step -1′, inside of ‘Step 0′.

Note also that if we were talking about requirements-to-implementation, Richard Veryard’s point – and I agree with him – is that we would need to turn the sequence the other way round: overall ‘non-functional’ requirements first, then ‘customer functional requirements’ (aka ‘use-cases’), then ‘supplier/partner functional requirements’ (aka ‘interfaces’).