Non-functional elements in enterprise-architecture
This one starts with a note from Belgian enterprise-architect Kris Meukens:
I couldn’t agree more with your post last month on “Architecture is non-functional“, and appreciated it very much.
However, the case is most often made for “system” architecture. With the right arguments – as also my experience has proven – that case can be made convincing to business people. But as soon as one tries to translate the same case to the less tangible “enterprise” architecture, I have been experiencing a lot more difficulty, although I am convinced it translates well.
I was wondering if you have any thoughts on this and/or you could help me on this one, which I consider pretty fundamental to enterprise architecture.
There are at least two different ways you could use to tackle this, depending on the context and who you’re talking with.
One is to take the same approach as Richard Veryard describes in his blog-post on ‘So-Called Non-Functional Requirements‘. In IT architecture, the functions are often relatively straightforward, and wouldn’t change all that much between different implementations. But some of the ‘non-functional’ requirements can demand huge differences in system-design, and will themselves demand different supporting-functionality: consider a system for a low-security context (store-directory for a shopping-mall) compared to a high-security-context (funds-transfer in ATM in a shopping-mall), or a low-bandwidth informational system versus high-bandwidth transactional system versus medical-imaging system for use in remote conditions with unreliable power-supplies. As Richard says:
The architect needs to worry about those [‘non-functional’] requirements that have major structural implications, and can mostly leave the functional requirements to the business analysts and developers.
So the same applies to an organisation: it’s relatively easy to plug in new functionality or features into organisation-level systems (which is why projects so often suffer from ‘scope-creep’ or even rampant ‘feature-itis’), but changes to ‘non-functional’ themes such as safety, quality, environmental management and interpersonal communication may well demand a fundamental re-think right the way through the entire organisation. In effect, the ‘non-functional’ determines much if not most of the ‘functional’ – especially when we take it right up to the whole-of-enterprise level and view the overall vision and values of the extended-enterprise as the foundational ‘non-functional requirements’ for the business as a whole.
Hence the second approach to this, which is to draw a distinction between organisation and enterprise.
The crucial distinction is that an organisation is bounded by rules and responsibilities, whereas an enterprise is bounded by shared commitment – in effect, by principles and values.
Each organisation exists within the scope of a broader ‘extended-enterprise’: its suppliers, partners, customers, prospects, overall environment and so on. (For more on that, see ‘What is an enterprise?‘) Without that relationship between organisation and enterprise, the organisation literally has no purpose: or, to put it the other way round, the enterprise is the organisation’s purpose. Which, in terms of what we’re discussing here, means that the foundational ‘non-functional requirements’ for an organisation are defined by its enclosing enterprise.
We then link that back to Richard Veryard’s point, that the ‘non-functional’ requirements create more fundamental demands than the ‘functional’ ones.
To do this, we first need to note that organisations form natural hierarchies, and likewise enterprises also form their own natural hierarchies. (Enterprises actually form intersecting ‘communities of interest’, or ‘communities of commitment’, and occasionally organisations do so too; but for these purposes it’s easier to think of them as simple nested hierarchies.) For example, ‘the business’ is often viewed as a single ‘the organisation’, encompassing a structure of business-units consisting of departments made up of sub-departments which consist of work-teams and so on, each with their own explicit rules and responsibilities. And sometimes the boundaries of an enterprise will coincide with an organisation-boundary: for example, each of those ‘sub-organisations’ is also an enterprise in its own right – a ‘community of commitment’.
Hence the somewhat misleading notion that ‘the organisation’ is also ‘the enterprise’. It’s misleading because of that point above: the foundational requirements for an organisation (whole-organisation, business-unit, department, work-team etc – whatever its level in the business-hierarchy) are defined by the enclosing enterprise for the respective organisation – not by the organisation itself. If ‘the enterprise’ has the same boundaries as ‘the organisation’, the foundational requirements in effect become self-referential – literally detached from the outside world. Which is not a good idea…
[Update: the term ‘Step’ below may be misleading, especially for some non-native English speakers – my apologies. Here it’s not a step within a process, for example, but means a pace or step outward from the boundary of the organisation. If in doubt, use ‘Layer’ as an alternative to ‘Step’.]
In practice the foundational requirements need to be drawn from an enterprise at least three steps larger than the organisation in scope:
- Step 1: partners and suppliers, including outsource and contract relationships
- Step 2: clients and prospects, including ex-clients and anti-clients
- Step 3: non-clients and community, including government and broader environment
Again, these are nested – so for an IT department, for example, Step 1 might include HR, equipment providers and outsourced help-desk, Step 2 would be the business-contacts, project-managers and general users of the department’s services, and Step 3 would include overall business policy and governance. In a production environment, Step 1 is the incoming side of the immediate supply-chain, Step 2 is the outgoing side and the schedulers, and Step 3 is production policy. At the whole-organisation level, the steps are as described above: partners and suppliers, clients and prospects, and non-clients and community.
Step 1 largely defines your costs; Step 2 largely defines your income. The relationships between them are relatively simple to model – such as with the Business Model Canvas. Hence many business-planners stop there, because those transactions do make straightforward business sense: but that’s a dangerous mistake, because as you’ll see from each of the examples above, governing policy is primarily derived from the commitments and values of Step 3 – not Steps 1 or 2.
In ISO-9000 terms, policy is derived from ‘vision’ – the guiding commitments, principles and values of the enclosing enterprise. In effect, policy is ‘non-functional requirements’ that determine response to change. And as ISO-9000 explains, it is indeed possible to run an organisation for a while without high-level guiding policy: but as soon as there’s any significant change, you’ll run that organisation straight into the ground – which, again, is not a good idea. So as enterprise architects, we need to understand and model all the way out to Step 3, in order to identify the overall requirements for the ‘system’ of any type of ‘organisation’ at any level within the organisational hierarchy.
To summarise in perhaps over-simplified form:
- Step 0 (‘the organisation’) is the boundary of the ‘system’ in scope
- Step 1 (‘partners and suppliers’) describes functional requirements for input-side for that system
- Step 2 (‘clients and prospects’) describes functional requirements for output-side for that system
- Step 3 (‘non-clients and community’) describes non-functional requirements for overall governance for that system
To paraphrase Richard Veryard again, we can mostly leave the functional requirements in Step 1 and Step 2 to the business analysts and developers; the architect needs to worry most about “those [‘non-functional’] requirements that have major structural implications” that arise from Step 3.
So perhaps use this as a way to explain to others the criticality of ‘non-functional’ requirements at “the less tangible ‘enterprise’ level” – in other words, how far out we need to model ‘enterprise’ in order to identify the real requirements for ‘the enterprise’ that is the organisation as a whole.
Hope this is useful, anyway – and as usual, constructive comments / suggestions etc would be gratefully received! 🙂
May I propose Step 4 to your summary, please?
Step 4 describes an implementation (preferably explicit and executable in the case of a complex ‘system’) of how to satisfy all mentioned above requirements. The implementation provides the boundary, functional and non-functional requirements for all its components.
Processes are examples of such implementations.
Thanks,
AS
Hi Alexander, and thanks.
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’).
Thanks Tom for extra explanation. I interpreted your 0-3 steps as defining business capability (ies) and addition of next step (i.e. implementation or further decomposition of a complex system) with processes (i.e. explicit and executable relationships between components) will provide a nice fractal “picture” of relationships between capabilities and processes. Sure that in such decomposition sometimes we use services (black-boxes) instead of processes (white boxes).
I think, that in this context my ”step 4” is not “step -1” inside “step 0”.
Thanks,
AS
Alexander – again, many thanks.
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.
Thanks Tom for your efforts. Obviously I am wrong with positioning my “step 4” – your steps are similar to a “unit of work”: 0) black-box, 1) its inputs, 2) its outputs and 3) its governance.
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
“What’s different about how business-anarchists work? The quickest one-line answer is that analysts rely on rules and algorithms; anarchists rely on guidelines and principles.”
and what about the anarchist that breaks the wall down and stretches the playing field? Aren’t they helping to develop new rules?
Alexander – Yes, agreed, but that’s actually an entirely different subject from what I was dealing with 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.
Hi Pat – uh, you may be responding to the wrong post here…? – this is about non-functional requirements, not the ‘business-anarchist’ book… 🙂
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.
Tom, obviously I agree with everything you are saying here, except for the statement that “it’s relatively easy to plug in new functionality or features into organisation-level systems”.
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
Following my previous comment, I saw a quote from the retiring chairman of the House of Commons’ Public Accounts Committee, suggesting that ministers are particularly subject to the illusion that it is easy to add functionality.
“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
@Richard Veryard – You’re right, “it seems easy enough” is the key point, here: I probably should have emphasised the ‘seems’ bit!
‘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.