Why service, function and capability
Ah definitions, definitions – so many to choose from!
But somehow, only a limited number of labels to go around, to share out amongst all those definitions?
Which means that people end up using the same labels for different things, and different labels for the same things, and then wonder why we get into such a mess of miscommunication.
Oops…
Which kinda suggests that along with the definitions themselves, it’s probably a good idea to say why we choose those definitions – and why we use that label with each definition, too.
Hence this post.
For some of the definitions I use, anyway. Or, to be specific, the definitions that I use for service, function and capability.
(This post is only about the why for the link between labels and definitions. For more detail about the definitions for those three terms, and a lot of other terms central to whole-enterprise architecture, see the post ‘Fractals, naming and enterprise-architecture‘. For examples on how those definitions are used in practice in service-oriented whole-enterprise architecture, see the series of posts on service and Enterprise Canvas, starting with ‘Services and Enterprise Canvas review – 1: Core‘.)
Where this started was that Luis Mariottoni came across my now quite old (September 2012) post ‘Service, function and capability (again)‘, apparently liked it, and then decided to tell people all about it, on LinkedIn and Twitter. (Thanks, Luis!)
Which in turn led Archimate-grandmaster Gerben Wierda to add another comment to the already great discussion on that post:
If you write:
– everything in the enterprise is or represents or signifies a service
– a process links services together in some way to achieve some kind of outcome
– a function is an external view of a service – in effect, a description of its interfaces (‘black-box’ view), often together with a summary or overview of what it does and how it does it (‘white-box’ view)
you are exchanging the terms ‘service’ and ‘function’ with respect to how I’ve seen it used so far (e.g. in ArchiMate but also elsewhere).I’ve seen service more often described as the external ‘side’ of some behaviour (such as a process or a function). Service is what the user of the service sees (uses).
I’ve also often seen a process described as linking together functions to produce some sort of outcome. Anyway, there are many, many ways to do this and there is no agreement between practitioners, also because in today’s modern complex landscapes there is both IT behaviour and human behaviour closely intertwined and the IT-culture and the Business-culture have separate languages on the subject.
I like to see a service as ‘the usable part’ of a function/process. The service cannot exist separately from that what makes it happen (unless you define service as the ‘requirements’ and not the ‘actual service provided’).
Or, in short, and in less-polite form, “You’ve got it all wrong, Tom!” 🙂
But have I?
Hmm… – kinda “It depends…”, I’d suggest?
And that’s the real point, because, actually, this is a great illustration of the difference between single-domain architecture and whole-of-context architecture. There are short-cuts and easy fudges that we can get away within a single domain, that we can’t get away with across the whole of a large, complex context – and terminology is definitely one of them.
In most cases it doesn’t matter much if people misunderstand each other somewhat: in fact being over-pedantic about it mostly puts people off, as Seth Godin reminded us this morning. Yet for architectures, we do need people to have a clear shared-understanding of what our technical-terms are and what they all mean. If we don’t, we risk creating our own equivalent of the Mars Climate Orbiter. And the problem becomes more and more extreme as the communication necessarily extends across more and domain-borders.
Mars Climate Orbiter is perhaps the most famous example of this. The US aviation industry has long-since standardised on its own literally-peculiar ‘English units’: inches, pounds, pounds-force and so on. Meanwhile, the rest of the world, in just about every industry, including the space-industry, has long-since standardised on ‘SI units’: metres, grams, newtons and the like. The spacecraft manufacturers were from the US aviation-industry, and specified thrust in pounds-force. The flight-controllers were from the space-industry, and specified thrust in newtons. No-one, apparently, had thought to cross-check – because to each of the players, it was ‘obvious’ that these were the units to use. The end-result was embarrassing, sad, and very, very expensive…
So, to here. Gerben sets out his view thus:
you are exchanging the terms ‘service’ and ‘function’ with respect to how I’ve seen it used so far (e.g. in ArchiMate but also elsewhere).
I’ve seen service more often described as the external ‘side’ of some behaviour (such as a process or a function). Service is what the user of the service sees (uses).
I’ve also often seen a process described as linking together functions to produce some sort of outcome. … I like to see a service as ‘the usable part’ of a function/process.
Right, okay, that’s one position, one set of definitions. He’s also telling me, in effect, that I’m wrong for not using the same label/definition pairings as these. And that the main justification there for asserting that I’m ‘wrong’ is that it’s the other way round from the way that Archimate does it.
Hmm… – kinda red-rag-to-a-bull time, that one. Allow me to be blunt here: I’ve never seen anything resembling sense or consistency in Archimate’s terminology – or structure, for that matter. It’s a mess. Even at first glance it’s a mess; and digging deeper down into its internal anatomy, as I did in that long post a few years back, demonstrated just how much a mess it really is. True, it did start off with a couple of very good ideas, but it got dragged off into the IT-centric booby-trap early on, consistency and logic falling apart very quickly after that, and it’s been downhill all the way from there – especially since Open Group barged into the story. To again be blunt, there’s almost no part of Archimate now that is not a scrambled, inconsistent, IT-centric mess: good example of well-thought-through terminology it definitely ain’t… So let’s just not go there, okay?
Sigh.
The broader argument that “everyone else in IT does it this way” is somewhat more defensible, up to a point – as long as we stay only in that one domain. Once we do need to spread out beyond that one domain, we’re gettin’ dangerously close to Mars Climate Orbiter again. In fact Gerben himself makes exactly this point:
Anyway, there are many, many ways to do this and there is no agreement between practitioners, also because in today’s modern complex landscapes there is both IT behaviour and human behaviour closely intertwined and the IT-culture and the Business-culture have separate languages on the subject.
Yes, they do: and that’s why we need to take some real care about this – otherwise, again, it’s Mars Climate Orbiter time.
To put it at its simplest, what we really need – and what I’d aimed for in my own definitions – is a terminology-set that would be completely consistent:
- at every level
- in every usage
- in every aspect of the enterprise
- for every instance
- in every form of fractality
Virtually every other attempt at service/function/whatever terminology that I’ve seen has thrown away at least one of those concerns, and often all of them. Which doesn’t help…
The trade-off (and yes, it is a trade-off) is that something that’s consistent is going to clash with other terminology-sets wherever they are either inconsistent, or themselves clash with other terminology-sets. Which means that we’d need ‘translation’ wherever there’s a clash – again, exactly as for what should have happened for Mars Climate Orbiter. And that’s fair enough – as long as we do remember to expect it, and expect the resultant need for explicit ‘translation’ wherever required. But the key point here is that a consistent terminology-set, because it’s consistent, can act as a known, common, shared reference-point around which all other conflicts and clashes can be resolved.
In short:
- for a domain-architecture, and within a domain-architecture, we can use whatever terminology-sets we like
- for whole-of-context architectures, and for links between domains, we can’t use “whatever we like” – we must use terminology-sets that are fully anchored and internally-consistent, to act as a stable base for any and all cross-links
The US aircraft-industry uses units such as inches, pounds, pounds-force, and gallons. Within that industry, it all works well enough. But there’s no direct translation between any of those units – instead, there are horrible ‘a cube of five-and-a-bit of those makes seventeen of these’ crossmaps, and so on. And the pound isn’t the same as the French livre, which translates as ‘pound’ and is likewise a measurement of weight, and US gallons aren’t the same as so-called ‘Imperial’ gallons, and short-tons aren’t the same as long-tons even though they’re both measured in pounds… Well, you get the idea: it’s a mess – especially if we need to translate between domains.
So the practical way by which we sort out that kind of mess is that we turn to the SI-units set. Which at first might perhaps seem to make some odd choices – or unfamiliar choices, anyway – but has the huge advantage that it is internally-consistent. Not only can we convert inches to metres, and pounds to grams, and pounds-force to newtons, and gallons to litres, but we can also crosslink between metres, grams, newtons and litres, in a clean, simple, completely-consistent way. It’s a whole-of-context terminology-set, in which each term and its definition is crosslinked cleanly to every other.
In other words, the kind of terminology-set that we need for a whole-of-context architecture.
Which is where we come back to service, function and capability, whose relationships I would summarise visually as follows:
Which Gerben tells me is the wrong way round, relative to the way the IT-industry typically describes it.
Yet, as Gerben also says, we could do it any way round that we like.
So, rather than arguing about which way round is ‘right’, a more useful question would be, which way round is better? – in the sense of providing better support for whole-of-context consistency?
And to decide on that, we need to look beyond the IT-industry alone. What descriptions can we find that do provide consistency across all the domains? – in the same sense, and for the same reasons, that SI-units are a darn sight more of an international-standard than the US aviation-industry’s ‘English units’?
So instead of the arbitrary and frankly-arrogant assumption that only IT is right, and everyone else is wrong, all we need to do is look around in the world that extends beyond IT alone. And what we’d typically find out there is as follows:
— Service is ‘that which serves’ – it’s active, not passive. A service serves someone’s or something’s needs. That’s a generic that’s used just about everywhere, including in most aspects of IT (such as ‘microservices’, for example).
— Function is passive – it’s waiting for something to happen. Or it’s a label attached to something that’s waiting to happen – a somewhat-mangled variant of ‘Business Unit’.
— We talk about ‘product or service‘, not ‘product or function’.
— We talk about ‘IT Service Management’, not ‘IT Function Management’ – though we might well also talk about ‘the IT Service-Management function‘, which again is a kind of label for a somewhat amorphous business-unit.
— We talk about product as a kind of frozen-service, ready to be ‘unfrozen’ to be used in service – the word ‘pro-duct’ literally as ‘that which leads towards’.
— In mathematics, a function is a placeholder for ‘something that will happen’ – for example, ‘outcome = function(withasset1, withasset2, usingthisflag)‘. There is functionality behind the function, but the function itself does nothing at all – it’s just a placeholder.
— Functionality is, in essence, a near-synonym for capability – ‘the ability to do something’. The difference is that functionality tends to be capability that’s hardwired onto some external interface, to deliver some kind of service. In other words, functionality as capability behind a surface-level interface that is described as ‘the function’. A very common usage in IT and in some forms of physical-engineering, but quite unusual elsewhere.
— Capability is ‘the ability to do something’ – it’s the bit that actually does stuff. But it’s also fractal: capabilities can be made up of other services, which are themselves made up of functions and capabilities and more, that themselves can be made up of other services that are made up of… – again, you get the idea.
As terms, they’re used in all but random ways in general business – look at the hopeless inconsistency around terms such Business Function, Business Capability, Business Service, Business Process and Business Unit.
In IT, the terms and the meanings behind them are very often bundled together, with service, function and capability all hardwired together as a single compound unit. And because they’re all bundled together, there’s a strong tendency to use the terms as if they’re interchangeable synonyms for each other. The catch is that we can – and often do – end up with hopeless and near-random inconsistencies of terminology, especially as we switch between levels or contexts or ‘layers’.
But the key to all of this is to keep those terms consistent, and keep them separate. If we do that, we can then describe how different forms of capability can be interchanged, behind the same surface-level interface. Unless we do that, there’s no way to describe the interchangeability or substitutability that we need for concerns such as load-balancing, multi-channel switching, or emergency substitution in disaster-recovery.
The fractality and nesting of ‘capability’ can sometimes seem kinda like a cheat, a kludge, a fudge – but it works. And it’s consistent, and consistent, and consistent – all the way down, all the way round, and all the way back up again.
So that’s why I’ve ended up with definitions such as these:
— Service: literally, ‘that which serves’ – something that enables action, or takes action, to serve a need.
— Process: a perceived sequence of invocations of services, where the perceived sequence may be either structured (repeatable) and/or non-structured (non-repeated).
— Product: an asset acting as static intermediary between services.
— Asset: a resource of some kind, either used within a service or acting as a product between services.
— Function: external-facing interface for a service (‘black-box’ view), responsible for the respective protocols, service-contracts, service-level agreements etc; accepts and returns assets and other resources.
— Capability: the ability to do something (part of ‘white-box’ view of a service), itself typically made up of other services and/or products at deeper levels of recursion. Capabilities use an agent to apply an action upon a specific type of asset, using a specific competency or skill-level.
I don’t claim that this is ‘the proper and only way to do naming’ – which Gerben does kinda suggest for his Archimate-oriented version of ‘function’, ‘process’ and ‘service’. I don’t claim that it’s perfect – it isn’t, and it never can be. But at least it’s a darn good try, and it is defensible, every step of the way – in contrast to the arbitrariness and randomness of most everything else that I’ve seen.
And the key differentiator here is that this naming is consistent everywhere: the same term is used for the same type of thing everywhere, every level, every recursion, every context. Which is a lot more than can be said for anything else that I’ve seen so far… Sigh.
So, what labels do you use, for what terms, what definitions, what usages, where, and why? And can you defend that ‘why’ for each case? Over to you…
I’m honoured you took the time to reply in this fashion.
I never said “You’ve got it all wrong, Tom!”, I did not say your view was ‘wrong’. I don’t think there is a definitive ‘wrong’ or ‘right’ here.
Having said that…
A service is ‘what serves’? The waiter provides a service, is it not? Getting food (and a bill, alas) is what is the service, for me. A service for me is not ;what serves’ but ‘what is served’ (to someone or something). Then again, in English it is ‘serves you right!” and we are talking then about ‘he serves you’. So we have ‘he serves you (a service)’. You choose the first ‘serve’ in that sentence, I choose the second.
Watch out for using “IT Service Management” the way you do. Yes we talk about that, but what we are doing is managing the ‘waiter’ so the customer gets the right food and bill in the right way. Literally, IT Service Management is often IT Delivery Management. Don’t get ‘bewitched by language’ as Uncle Ludwig would say. The fact that wel call it ‘service management’ does not mean we are in fact managing the service, we are managing that other part of ‘serves a service’.
‘Doing’ is a dangerous term to use in mathematics/ A function ‘does’ nothing? What is the function other than ‘the functionality behind the function’? Is there a difference between one and the other? Not in math and not in IT, but there is in the human world and here it seems unavoidable we mix things up.
Have to run. Was a nice piece, definitely. You can create your definitions, but you will be running in so much ‘US Aviation’ that I think there is little chance you (or anyone) would succeed in unifying communication here. That’s what people thought of in the 30’s (significants, esperanto, etc.) but there are problems.
Why is output (or outcome) not part of the definition of a service. I call on a service because I want it to take action to produce something for me. I go to MacDonald’s and use their services (order taking, settlement, cooking and dressing) to make a Big Mac for me.
I like this “Functionality is, in essence, a near-synonym for capability” Not so sure it’s tied just to IT, e.g. a paper form provides Information/data capture functionality.
Sometimes (actually, frequently nowadays) I wonder if we’re approaching this problem the wrong way round, putting the denotational cart before the semantic horse as it were. We start with the words and then try to “define” them.
Shouldn’t we instead start with the concepts we need to successfully practice our art (the “definitions”) and then choose the words best suited to denote them?
As Tom notes, there are only so many words to go around, but ultimately it isn’t the words that matter, it’s the concepts they denote that matter. Perhaps I overstate this, but it seems to me that the words are important only to the extent that they consistently suggest the concepts we need them to denote.
Ideally, the mapping would be one to one, with different words denoting different concepts; a single word denoting multiple concepts creates the opportunity for confusion, and multiple words denoting the same concept waste a precious resource, but more importantly, may obscure the fact that we have overlooked a concept essential to the successful practice of our art.
If we start with the words, how do we know that we have identified all the necessary concepts? A perfect example of this that Tom and I harp on incessantly is the willful confusion of organization and enterprise — because the conventional wisdom is to use the two words almost as synonyms, we lose the ability to clearly distinguish between what something is (one or more organizations), and what it does (the one or more enterprises they are undertaking). What would medicine be like if neuroanatomy and behavioral psychology were thought of as the same thing? They are clearly closely related, but, in language familiar to enterprise architects, they address different “levels of abstraction” (though I’d argue that they’re not different levels of abstraction, they’re different realms of discourse).
I have argued elsewhere that the words we use to denote concepts carry “connotational baggage”, and that a big part of our problem with correctly understanding one another is due to the fact that while we can nominally agree on what a word denotes, its connotations are generally more personal, if not at the individual level, surely at the cultural level. This is a feature of sorts in the context of the expressive arts, but in a professional language it can be catastrophic. This is why, for example, though the international standard for the language of air transport is English, there are still problems with crew members misunderstanding one another and with aircraft crew and ground personnel misunderstanding one another.
Gerben’s remarks about his preferred interpretation of the meaning of “service” is another example of the difference between “what something is” and “what something does”. Gerben prefers to frame the concept one way, and Tom prefers to frame it another way. Both frames, and the concepts they denote are not only equally valid, they are, more importantly, equally necessary to the successful practice of our art. I wrote about an extreme example of this in my article “Eight Ways We Frame Our Concepts of Architecture” in the September 2015 issue of the Journal of Enterprise Architecture.
As long as we persist in starting from the words as givens and trying to fit our concepts to them, we are going to have debates like this.
len.
While I agree that definitions are important, one should also consider perspective. Having spend the last little while trying to determine why two groups have come to considerably different number as to the size of an Organization’s IT Applications Portfolio. One group reports a count some 40% higher than the other. I’ve come to accept that the difference in count is a result of different views of the same thing.
I can see the same problem arising when looking at the different views on the definition of a service. A provider of a service takes a very how to or white box approach to defining a service. A user of a service sees it from an outcomes/output black point of view. A payer of a service see it from another perspective.
I’m learning over and over that one always has to put context and perspective around the definition of a concept.
Tom,
I am probably going to be stepping on eggshells here, but as I regard myself an information architect with over 40 years experience in the information technology industry, 27 years of which has been spent working in the field of strategic planning and having developed a framework and automated it, I have to give my opinion on this. Imho it is all about definitions. So I definitely agree with you on that point.
I also agree that if you mislabel something you will get yourself into a mess. I will call a ‘label’ a ‘domain’ from hereon in.
I will now go one step further, if you do not rationalise every word used in the business domain and understand the true nature of structures and where each word fits into the structure, then anything will equal anything and all we will ever have is chaos and the inane outcome of always having to agree to disagree. We need a common reference point (or a meta model) and I have chosen the work done by Immanuel Kant from his book the ‘Critique of Pure Reason’ as mine.
Having written that I will now address the ‘service’, ‘function’ and ‘capability’ issue. Between the 3 words there exists 2 separate domains that are both encapsulated within the Information architecture domain (which is encapsulated within the conceptual domain). Hence the first thing that I will introduce is the structure of information as having 3 domains: conceptual, logical and physical.
‘Service’ and ‘capability’ reside within the knowledge domain while a function is a business process domain itself. They are two separate concepts and confusing them as one and the same is terminologically incorrect.
Different frameworks handle definitions differently which in why we always seem to end up in the same ‘snafu’ situation.
Define your structures, define your terminology within the structure, ensure that each structure will stand the truth table test and then judge as to which framework will ‘do only good by doing no harm’. Otherwise we will merely perpetuate the status quo.
Regards
I know I sound like a broken record (explanation available for digital natives on request!) whenever the issue of services comes up. But I do like to keep this top of mind in the EA-sphere that there is a fairly recent school of thought, spearheaded by professors Lusch and Vargo, labeled service-dominant logic. This hearkens back to the economics of Bastiat, and makes the case that service is the foundation for economics.
I always also feel a need to remind ourselves that one-word to one-concept expectation is a true chimera, and that polysemy is really an iron-clad rule of human communication. We can almost always assume that we need to not only express ourselves, but also explain ourselves. There’s a cost, to be sure, but there’s also a cost to the generally unwarranted assumption of commonality of meaning. Sorry to be the bearer of bad news 🙁 🙂
Doug McDavid replies, presumably to me:
“I always also feel a need to remind ourselves that one-word to one-concept expectation is a true chimera, and that polysemy is really an iron-clad rule of human communication”
In general yes, of course, and I have made this point repeatedly when exploring the reasons for the EA community’s lack of in-depth agreement on what we mean by the words we routinely use. See my succession of presentations entitled “Why We Can’t Agree on What We Mean by Enterprise Architecture”; the earliest version I can easily find dates from December 2011.
I should have been clearer that I was talking about the controlled language of a profession. For such languages, one word to one concept is not an expectation, it is an aspiration. As I noted, in the expressive arts polysemy is a feature, but in a professional conversation, any ambiguity can lead to misunderstanding, which can create challenges to effective collaboration and thus achievement of the mission. In a surgical suite or a cockpit, disambiguation from context is an expressive luxury that is more of a liability than an asset.
For example, I wouldn’t have used “chimera” in making Doug’s point. I understand the word to mean a hybrid, an assemblage of disparate parts, and as such his remark at first made little sense to me. Then I realized he used it to mean something imaginary, an alternative meaning that does makes sense. Polysemy indeed, but as I am pointing out, an impediment to understanding one another.
“there’s also a cost to the generally unwarranted assumption of commonality of meaning”
You’re preaching to the choir. This assumption, while certainly unwarranted, is also one of the most commonly made, and I have been calling attention to this for years. When an assumption is so widely made, the solution in critical contexts is not likely to be insisting that people stop doing so (which doesn’t solve the problem of ambiguity, only makes people more aware of it), but rather to render the action innocuous; hence the development of controlled professional languages.
len.
One last thing — the real point of my comment was the idea that we should get first our concepts straight and then find words to denote them, rather than start from a bunch of words and try to define them. The one-word one-concept idea is in comparison a nicety.
len.
Discussions about architecture terms sometimes remind me of that passage from Through the Looking Glass (“When I use a word,” Humpty Dumpty said in rather a scornful tone, “it means just what I choose it to mean — neither more nor less.” …). Even if the architecture community can agree that “function” is the external interface it won’t change how the Finance Function (and the rest) use these terms. Perhaps we should put less effort into definitions and more effort into dialogue. I still see an enormous amount of architecture effort go to waste and lots of architecture documents gathering dust because few outside the architecture profession can understand the value or make use of the insights.
Sorry to have let a couple of days go by, and who knows if anyone is still watching this space. I do think one of our most important topics is being kicked around here, so I’ll gamble that this is still relevant.
Len, I actually wasn’t addressing my comments to you specifically, but more at these general kinds of discussion, which keep popping up here and there on occasion. Yes, your second interpretation of the word “chimera” was what I had in mind, and I apologize for introducing more ambiguity. Maybe I should have said “mirage”.
I should also try to be really explicit about my position on this terminology and meaning issue. The underlying issue for me, when I get involved in these discussions, is that I find the subject and discipline of enterprise architecture so doggone *interesting*! I admit to being a lifelong and hopeless generalist, and it’s hard to imagine a more diverse and constantly refreshing area of concern and study than the meaningful interactions among human beings, which is what I think we immediately enter into when we undertake the understanding and depiction of the architecture of enterprise. Enterprises are interesting! We’re so lucky to have the opportunity to do this work and get paid for it! I’m thinking …
So where this leads me is to want a very, very rich set of concepts to be able to apply to such an interesting universe of discourse. I’m afraid this puts me on the opposite end of the spectrum from many colleagues, who argue for a short list of terms that are valid to use in the discipline, and for tightly-specified, locked-down meanings and/or definitions for only that limited short list of terms.
Every time we get to that point in these discussions I want to say “Hey, wait! I’ve been using that word” (say ‘capability’) “in several other ways, and now I hear you propounding a rule that says I can’t use that word in those ways anymore?!” Sometimes I actually do say something like that, followed by my position that anyone who wants to exclude a certain usage has the burden to propose some other way to say what needs to be said, since they’re cutting of a certain avenue of expression.
On various occasions I’ve tried proposing certain conventions so that we don’t have to rely on single natural language (e.g. English) words. Those single words are already overloaded (polysemous) in the wild, and then as technical terms we have to fight many forms of overloading.
Here’s an example, related to, and slightly expanding, this discussion of service, function, and capability. Somewhere along the way I came across an interesting use of the word “job”. I like this, and have somewhat adopted it in the following quote from a paper I published earlier this year: “The ‘jobs to be done’ perspective, laid out in Clayton Christensen and Michael Raynor’s The Innovator’s Solution, which talks about “hiring” a product to perform a job that needs to be done in the life of a customer, … [is exemplified by] ‘the morning milkshake’. A surprising profile emerged from a fast-food restaurant, where researchers found that customers purchased a high percentage of milkshakes in the early morning. The study revealed that commuters needed a certain ‘job, which consisted of a combination of reducing the boredom of a long commute, consuming nutrition that would last well into the morning, and being easy and hassle-free to consume. These commuters ‘hired’ a milkshake to perform a ‘job’ that needed to be done (i.e., a service).”
I personally find this richness of language to be a helpful way of talking about, and modeling, the general concept of a customer desire in the context of product development, and even IT implementations, to capture and compare aspects of a current and potential product portfolio. Now, I probably just stepped on someone’s vocabulary when I just used the word “portfolio” the way I did.
So far, as a discipline, I don’t think we’ve really grappled with the tension between clarity and richness of expression. I’m in favor of both (d’oh!), and I guess my main point is, and will continue to be, “Please, let’s not sacrifice richness in favor of clarity!” The field of enterprise is too interesting and diverse for that, and frankly, I attribute some of the angst that others have with our discipline to the seemingly endless wrangling they hear over the transom, which seems to me to stem, at least in part, from efforts to constrain what we can actually express.
Finally (for now!), Richard brings up another side of this issue, which is the multiple domain-specific lingos and jargons we encounter in our work. He mentions the “Finance Function (and the rest)”, which can be a long and complex list of ‘the rest’. A (very?) few of us think that part of the job of architecting within the enterprise is the need to be agents of disambiguation and clarification across multiple linguistic domains of work. But then I’ve written about that before, and in any event I’ve probably worn out my welcome for today, here, in Tom’s home. Sorry, Tom!
Hi all,
If I could add my own 2 cents worth.
All points made above, from what I can see are equally valid but I would tend to agree with Len (and Doug I think too), that we need to define the key concepts first – though I’m sure that is Tom is tiring to do too.
What I think makes this whole topic so difficult is that we are in the early stages of biggest structural change to human systems of organisation that we have seen in 100 years or more. This means we continue to struggle to describe what we are seeing using language from a different era. Maybe we just need to come up with new words? I don’t have them yet but I’m drawn to evolution as the source. If anyone has some suggestions I’m all ears.
Here’s my take on the 3 key terms using the old language:
Capability = job to be done in they Christiansen & co. define it.
Service = current instantiation of solution for job to be done e.g. Horse & carriage, train, truck, Ubet? You get what I mean.
Function = current mix of people, process and tools that underpin the service (or to get biological for Doug enzymes, proteins and genetic coding – but I might be stretching it there
Hi all,
If I could add my own 2 cents worth.
All points made above, from what I can see are equally valid but I would tend to agree with Len (and Doug I think too), that we need to define the key concepts first – though I’m sure that is Tom is tiring to do too.
What I think makes this whole topic so difficult is that we are in the early stages of biggest structural change to human systems of organisation that we have seen in 100 years or more. This means we continue to struggle to describe what we are seeing using language from a different era. Maybe we just need to come up with new words? I don’t have them yet but I’m drawn to evolution as the source. If anyone has some suggestions I’m all ears.
Here’s my take on the 3 key terms using the old language:
Capability = job to be done in they Christiansen & co. define it.
Service = current instantiation of solution for job to be done e.g. Horse & carriage, train, truck, Ubet? You get what I mean.
Function = current mix of people, process and tools that underpin the service (or to get biological for Doug enzymes, proteins and genetic coding – but I might be stretching it there
Hi, Paddy — Thanks for the nod my way about living enterprise. Just to be clear, though, when I talk about enterprise as life form, I try to steer away from biology, though that comparison seems unavoidable to some extent. I set up a place to explore such issues https://www.linkedin.com/grp/home?gid=6776916&trk=my_groups-tile-grp – a group called Living Enterprise. I’ve elevated one discussion to the top, via the “manager’s choice” function. That discussion has the headline: “It’s not a metaphor!”