I’ll answer all of this from a ‘service-oriented enterprise-architecture’ perspective – i.e. ‘everything is or represents a service’, where ‘service = function + capability’.

Function/Business Function: Your 1:

a) From an architecture perspective, there’s no intrinsic difference between a ‘business function’ and any other type of function: the ‘business’ label is literally just a label, just a way of viewing the possible role of the function. The only architecturally-meaningful notions of ‘higher’ or ‘lower’ are level-of-abstraction (e.g. Zachman ‘rows’) and composition/aggregation (e.g. ‘parent’-to-’child’ relationships); be careful not to confuse arbitrary notions of ‘higher’ or ‘lower’ in role-labels (e.g. ‘business’ versus ‘process’) with level-of-abstraction or implementation-method or anything else.

b) We tend to create a sort-of hierarchy of functions, but it’s a hierarchy of aggregation (‘child’-functions and -services). It’s not a true tree-type hierarchy in the classic business sense because some ‘child’-functions may be used in multiple higher-aggregation – it’s a M:M relationship, not a M:1 relationship.

c) The lowest-level function could be right down at the molecular level – for example, ‘molecular tweezers’ in nanotechnology applications. Remember there’s no intrinsic between ‘business function’ or any other function: ‘business’ is just a label that we may or may not choose to place on a particular view of a specific function or aggregated-function.

Function/Business Function: Your 2:

a) The same applies as above: ‘business’ here is just a label placed arbitrarily on a particular type or clustering or aggregation of capabilities. Do not use ‘Function’ or ‘Capability’ or ‘Service’ or ‘Process’ to mean different layers of aggregation and/or abstraction of (usually) services: if you do so, you are guaranteed to cause confusion further down the track. I fear this is what you’re doing here? General business-folk can usually get away with being careless about this, but architects can’t: we need stable precision here.

b) A capability is literally the ability to do something; a function is a placeholder for where something can be done in accordance with an identifiable protocol and identifiable rules, principles or guidelines. On its own, a capability literally has no function: it’s just the ability to do something, not the actual doing of it. (A car engine has the capability to drive the car, but the car-frame and transmission and so on provide the functionality for the car to actually move.) Conversely, a function has no intrinsic capability. (In general, the car won’t move without the engine.) We bring them together as a service. (The services provided by a moving car.) Note that we can substitute alternate capability within the same function, to produce a somewhat different service, usually with different ‘non-functional’ attributes. (If the engine won’t work, we could tether a horse to the front: the overall service would still be deliverable, with [almost] the same function, but probably a lot slower!)

c) We typically assign a capability to a function, but again there’s an M:M relationship here – as you’ve suggested above. A capability may be used in multiple functions, and a function may (and often will) call on multiple capabilities. There’s another slight complexity in that a single function-interface may actually serve as a front-end for multiple services with different capabilities. The obvious example is escalation at a customer-service call-centre, where a problem will typically first be offered to a capability with basic rule-based skill-levels (e.g. web-based FAQ), then escalated to a different higher-skill-level capability (a real-person with some technical background or experience), and perhaps further onward to a higher-level capability again (subject-matter expert with deep experience).

Business Capabilities: Your 1:

a) I’m a bit worried because you again seem to be using ‘function’, ‘capability’, ‘service’ and ‘process’ as semi-interchangeable terms, and/or as labels for different supposed ‘layers’. Don’t do that – it’ll cause you endless trouble (as seems to be evidenced in some of what you’ve written above). Instead, use definitions that remain the same regardless of what ‘level’ you’re working on: either my definitions as in the post, or any other definitions you prefer – the crucial is that the definitions must be consistent throughout the whole of the architecture.

b) To clarify the specific point you asked: from a service-oriented perspective, an activity is the application of a capability within a function (and hence within a service). The capability is the ability to do something; the activity is the doing of that something. In practice, when most business-people use ‘activity’ in a model or whatever, it seems that what they actually mean (in terms of the definitions I’ve used above) is, in effect, a service, but without any usable definition and/or description of the service-interface – which isn’t helpful from an architecture-perspective…

Business Capabilities: Your 2:

a) (Thanks for the pointer to the ‘MECE principle’ – ‘mutually exclusive, collectively exhaustive’. Didn’t know the term before; I do now! )

b) Once again, be very careful not to use ‘capability’, ‘process’ and so on as labels for layering: it’s guaranteed to confuse. At a more-abstract level, what we might describe as a ‘business-capability’ may be realised via specific more-concrete services, but those services in turn rely on the actual implementation-layer capabilities, without which the service that underpins the ‘business-capability’ cannot be realised. Hence implementation-layer capabilities aggregate into ‘higher-order’ (often more-abstract) capabilities, and implementation-layer services aggregate into ‘higher-order’/more-abstract services; but if we’re to be consistent about our terminology (and we should be!), capabilities do not actually aggregate into services or processes, nor services into capabilities, or anything else. I know it probably sounds very pedantic, but believe me, that level of precision is the only way that works in an implementable architecture.

c) Re M:M, yes, as per my 1(b) above, it’s a ‘sort-of M:M’. They’ll tend to cluster as a sort of hierarchy, so that it’ll look like an M:1, but in quite a lot of cases we’ll find implementation-layer capabilities being used within multiple distinct implementation-layer services, which in turn realise multiple distinct ‘business services’.

Hope this helps?

(Oh, and on your “Your feedback would obviously be worth a lot =) ” – depends what you mean by ‘worth’, but hey, a small consultancy-fee would be very welcome, of course! On a slightly more serious note, I do work as an independent consultant in whole-enterprise architectures, so if your company wants my professional assistance in this, please let me know? – many thanks!)

Trouble is that I forget, way too often, that what’s ‘obvious’ to me isn’t obvious to anyone else at all. And I try cram so much into every post, with so many ideas that depend on other ideas that depend on other ideas that I might remember but others probably don’t, that it can sometimes be a bit (or a lot?) too difficult to follow. Oh. I Must Do Better Next Time, etc. Oh well. My apologies, anyway?

“I am but a mortal too” – yeah, that’s the problem. Not just in that sense, but at my age I’m acutely aware of just how mortal I am, which brings on a quite different kind of urgency… – in particular, an urgent need to get things down in some kind of usable form whilst I still can. Which means that things can get a bit rushed and a bit too compressed. Oh well. Again, my apologies.

Sometimes you are literally too brilliant!! This is a great post but I have to be honest (I’ve read all of your books and) you were beyond my comprehension a couple of times in this post. I am but a mortal after all.

Looking forward to the anti-post!!

This makes sense to me, even though my background is purely “non-IT”.. I’ve been working as an operational developer for seven years, and the latest three years been “into” EA and model “aided” business development. I am now ending up with these question because I am trying to verify and hopefully improve our meta model, and end up with a basic set of definitions independent of abstratction level (today it is a bit messy). Since my last post I’ve found some more questions, of course.. I dont expect you to have time for these questions, but I’ll pop them and hope for response from anyone. At least someone might help me express them in a better way or point me in a good direction =)…but I will first try to brief you about our current situation.

We are currently working with Business Services, Business Functions and “lower level” Capabilities. Business Services are realized by sub processes, and supported by “lower level” capabilities which relates to corresponding processes and activities. We also work with domains and sub domains (often derived through information and city planning) and Functional blocks. The former I have found to be what many other standards/framworks call Business Functions, and other organisations might identfy/derive them in other ways.

Since recently we are also implementing higher level capabilities derived from the business model as means to tie strategy down to our activites. So… we got Business Functions, Business Capabilities and Business Services and lower level capabilities (Process Capabilities).

On Function/Business function:
1. On the “business” side, how would an business function hierarchy look, and how would it be derived? (ofcourse I don’t want to build hierarchys if it’s not needed, but your thoughts on this would be helpful for my understanding). What would be the lowest function, i.e. on an “activity level”?

2. Since a capability can support mulitple functions (answer above) – does this imply the same for Business Capability and Business function as well? I was originally thinking about this relationsship as (M:1) and a “belongs to” relationship, but I was a bit off track here?

On Business Capabilities:
1. We have defined Business Services at our level 3, and these are realised by Sub-processes (at same level). We have a (M:1) relationship – one or several Sub Process may realize a Business Service. The sub-process is broken down to process components which are an abstraction of the actual activity flows. We have not yet defined services for lower levels, but this Sub-process breakdown is the foundation for our lower level capabilities (which in fact could be called business services as well I suppose)

…given this – how would you define the relationsship between a lower level capability and an activity? We used to define it as (1:1), but this seems a bit off if one would like to refer to capabilities as more stable than the process architecture, doesn’t it? Shouldn’t it rather be (1:M) – One or many activities realizes a capability.

2. I am also having trouble to define the relationship between a Business Capability and a “lower level” Process Capability (wich supports our Business Services). If there should be any relation, should it be a strict (1:M)-relation based on the MECE-principle – or should (M:M) be used (allowing for a lower level capability to support several higher capabilities in capability maps)?

hmm… I got a bit carried away.. I apologize for this long and somewhat blurry and detailed post. It might have been more useful for you to see the meta model right away.. But ofcourse I won’t hesitate to share it with you. Your feedback would obviously be worth a lot =).

Many thanks also for the compliment Yet note that the most important point there is that I only provided some of the ideas, whereas you put those ideas into real-practice – which is where it really counts. Important to acknowledge the real hard work that you did there to make that outcome happen: credit where credit’s due on that, I think?

Quick summary: yes, strongly agree about it being a) almost all IT-only, and b) almost all about ‘clean up the mess’. And, as you say, ‘clean up the mess’ is only one part of the overall picture.

What I’ve added to this is exactly where each part such as ‘clean up the mess’ and ‘strategy top-down’ fits into the EA picture, following the maturity-model and matching development-plan that I described in Doing Enterprise Architecture. The relevant first part of the book is in the free-download sample-ebook that’s accessible from that link. Would be very interested to see your comments on that at some time! Hope it’s of interest, anyway.

Thanks again!

Anyhow, I began to put together a story of their strategy, the transformation that the Enterprise was going to have to undertake and all the various components of that and the sponsor turned to me and said…”Wow, I’m truly sorry. Please excuse my ignorance. Your actually working for me, it took me a little bit to figure this out.”

Was great and now he sees Enterprise Architecture in a whole different light.

This external drive, architects with the right understanding of EA, along with Enterprises feeling the pressure to change from an inside out perspective will only help our cause. Anyhow, hope all is well with you Tom. I know you made me feel right about my thinking and approach, I’m positive your influence has alot to do with Gartner’s thinking as well.

1. Application consolidation / re-engineering.
2. Business process efficiency
3. Technology standardization
4. Business-IT alignment
5. Service delivery
6. Resource optimization
7. Functional integration
8. ……..
9. …

Besides the fact that nearly all of these are IT-centric, they are also overwhelmingly “housekeeping” type of activities that are retrospective in nature, i.e. trying to fix mess that already exists. Sure, these might bring in some benefits, but they clearly lack the “forward-thinking” type of activities. Enterprise Architecture (and Enterprise Architects) must provide foresight to the rest of the enterprise. The foresight then enables the leadership to envision the future.

Yep. It’s been going on for a while now. I remember writing a post about this almost two years ago: ‘Hoist by their own petard‘. The behaviour of the ‘big fish’ would be bleakly amusing if it hadn’t caused so much mess that will now still take years and much expense to sort out… Hey ho…

In the meantime we keep on plodding on, ‘fighting the good fight’ and suchlike, yes?