The meaning of process

What do we mean by the term ‘process’? What is a process? For that matter, what isn’t a process?

This came up in a great Skype-conversation today with Kevin Smith, creator of PEAF (the Pragmatic EA Framework), about yet another LinkedIn somewhat-circular discussion – “going down the rabbit-hole”, as Kevin put it – about the definition and meaning of ‘process’.

Not surprised at the ‘rabbit-hole’, though. (And this time I won’t curse at the IT-guys for creating it, either, because they didn’t. 🙂 ) ‘Process’ is one of several terms that are used in horribly-blurry ways within business, and worse, it’s also part of that appalling terminology-tangle of process versus service versus function and the rest, where processes can contain functions can contain processes can contain services can contain functions which can contain other functions or services or processes… Yeah, it’s a mess.

Yet whilst the rabbit-hole isn’t the IT-folks’ fault as such, somehow their IT-centric approaches to everything do seem to succeed only in screwing-up this one even further than it is already. For example, one of the IT-folks in that LinkedIn discussion argued that the word ‘process’ should be reserved solely for automated processes, or linear processes: sequences of exactly-repeatable activities with consistent inputs and equally-consistent outputs. Anything that didn’t fit this description wasn’t a ‘real process’, and either could or should be ignored – by IT-folks, anyway. When asked how, given that constraint, we could then describe those parts of customer-journeys and other activity-streams that didn’t fit this description, he suggested the alternate term ‘practice’. Which might be considered okay, except that we would now have two equally-blurry terms for what is, in effect, the same activity-stream, differing only in how they’re implemented – which in practice might change at any moment. Further and further we go down the rabbit-hole…

So let’s back off a bit. Back right up out of the rabbit-hole. Start again – but this time, instead of fighting about which definition is the ‘correct’ one, we start by acknowledging that it is a mess.

What actually is a process, in the way that people tend to use the term? And how does the definition get to be such a mess? Here are some points about it that most people seem to be able to agree on:

  • ‘process’ is a blurry kind of term – in fact one of its advantages as a term is that it is kinda blurry
  • it’s something sort-of to do with sort-of-sequences of activities that, overall, probably result in something being done to or with something – it’s all a bit blurry and uncertain
  • we use the term for sequences that mostly seem to repeat; for sequences that barely repeat at all (and sometimes could barely even be described as sequences); and for just about anything in between, and any mix of in-between as well
  • business-folks in particular use ‘process’ to describe things that automated systems do, and things that people do, and any combination of those – including contexts where the process passes back and forth between people and machines, or where people can sometimes do the tasks of machines, and vice versa
  • process can be just about anywhere, and at just about any level, from a server-process or web-process to the process of an entire production-line
  • processes can be decomposed into smaller sub-processes, and aggregated into broader-scope processes, but we still use the same term regardless of what level of decomposition or aggregation might apply

If ‘process’ is as blurry as that, it’s no wonder that process-taxonomies don’t seem to make much sense…

But let’s turn this sideways on. All of those definitions seem to assume that ‘process’ is the work itself. It isn’t: it’s a description of work – a description of perceived relationships between activities, in terms of some kind of overall objective or goal. It’s a way of looking at the ways in which work is done.

And we already have another term for ‘way of looking at something’: a model.

A process is a map, a description, a model, of ‘work being done’, or ‘work to be done’. A selected subset or view into the totality of ‘work being done’. Processes are a way to view perceived-relationships between activities; and those views (‘processes’) may encompass a spectrum from exactly-repeatable to exactly-unique.

And just as with any other architecture-type model, if there’s a view, there’s a viewpoint from which to observe that view. And we should be able to describe and define the context for that viewpoint – not least, the intended-audience for that viewpoint and view.

The selection of whatever is considered to be ‘part-of’ or ‘not-part-of’ the process is not ‘objective fact’ as such, but a choice as to what will or will not be considered relevant in the view from the viewpoint.

So if a process is, in effect, just a view, and the set of activities or whatever to be shown in that view are just a choice, then it’s no surprise that the term ‘process’ tends to be a bit blurry…

Using ‘process’ solely to mean ‘predictable sequence of automation-delivered activity’ is a term-hijack, much like using ‘enterprise-architecture’ for EITA only. Term-hijacks block the view of the whole, and make it almost impossible to make sense of anything in a real-world context. For example, if the definition of ‘process’ is automation-only, then in effect the EITA-guys are classing every non-automated activity as a SEP – and SEPs don’t cease to exist simply because you choose to ignore them. Not a good idea…

‘Process’ and ‘activity’ are orthogonal – or rather ‘process’ is simply a view into activities. And, in turn, what is or is not considered to be an ‘activity’ is also often just a choice, a way of partitioning what’s going on, as a way of making-sense of what’s going on.

Every ‘process’ is an arbitrary grouping of activities – a view. (Note the word ‘arbitrary’ there…). So processes can always be decomposed and/or aggregated, because a process is just a view.

For example, automated actitivies can be decomposed right down to a single machine-code instruction, or aggregated up to (part of) an overall business-process: a process is an arbitrary (self-chosen) view into activities. And activities themselves may be perceived as ‘being’ at some level of decomposition/aggregation – which itself is a view. So in effect, a process is an arbitrary view into an arbitrary view.

A process is an arbitrarily-selected view from an arbitrarily-selected viewpoint into perceived-relationships between perceived-activities.

That’s it: it’s arbitrary, and it’s completely recursive – hence the rabbit-hole. (More accurately, the rabbit-hole occurs whenever some idiot insists that some arbitrarily-chosen view is ‘the process’…)

In short, ‘process’ means what we choose it to mean – no more, and no less. A blurry kind of term, but usefully-blurry nonetheless: a definition that works because it doesn’t actually define anything.

Hope this makes some degree of sense, anyway – and hope it helps, too. Comments, anyone?

[Update: yep, I admit it: I screwed up somewhat on this one. The screw-up is not actually that fatal – it doesn’t invalidate the key point about ‘inherent-blurriness’ – but as can be seen in the comments below, Nick Gall and Ivo Velitchkov both rightly lay into me about various aspects of this post.

The main screw-up is best summarised by Nick: “I can’t believe you’re still getting bogged down in the ‘thing’ vs. ‘description of thing’ quagmire”. As Nick says in his comment, I’m muddling ‘process’ (‘thing’) with ‘process-description’ (‘description of thing’): that arbitrarily-selected view is the process-description, not the process itself.

So, another try:

  • a process is the/a set of overall activities, inputs, outcomes and context, in terms of whatever is chosen to be summarised in a process-description
  • a process-description is an arbitrarily-selected view from an arbitrarily-selected viewpoint into perceived-relationships between perceived-activities

The real point is the blurriness, the arbitrariness, the uncertainty: a process is whatever we choose to say is ‘the process’. Any definition of ‘process’ that tries to be any more precise than that is missing the point about the need for and value of ‘non-definitions’ of this type.

Hope that makes a bit more sense this time?]

Tagged with: , , , , ,

10 Comments on “The meaning of process

  1. Tom, I like much of what you have to say about process views, but I can’t believe you’re still getting bogged down in the “thing” vs. “description of thing” quagmire.

    I thought ISO/IEC 42010(formerly IEEE-1471) cleared this terminological confusion up once and for all for architecture:
    * architecting: process of conceiving, defining, expressing, documenting, communicating, certifying proper implementation of, maintaining and improving an architecture throughout a system’s life cycle
    * architecture: fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution
    * architecture description (abbreviation ‘AD’): work product used to express an architecture
    * architecture description language (abbreviation ‘ADL’): any form of expression for use in architecture descriptions
    * architecture framework: conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders
    * architecture viewpoint: work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns
    * architecture view: work product expressing the architecture of a system from the perspective of specific system concerns
    * concern: interest in a system relevant to one or more of its stakeholders. A concern pertains to any influence on a system in its environment, including developmental, technological, business, operational, organizational, political, economic, legal, regulatory, ecological and social influences.
    * stakeholder : individual, team, organization, or classes thereof, having an interest in a system

    The same should apply to process:
    * Process: <>
    * Process description: work product used to express a process

    So “process” should NOT refer to a description! It should refer to the actual thing, eg, the actual activities carried out to bake a cake. “Process description” (or the subset term “Process viewpoint” should be used to refer to the description/viewpoint of the process, eg the recipe for the cake (especially the steps listed).

    See for more on ISO/IEC 42010.

    • Nick – ouch… point made… 🙁

      You’re right, of course, re 42010 – in fact I was thinking mostly about 42010 and its distinction between ‘view’ and ‘viewpoint’ when I wrote it. Oops…

      Yet the point about ‘blurriness’ still stands, and the real value (and also problems) of an explicit not-really-definition. So what’s a better way to describe this, rather than what I’ve done (further-scrambled?) above?

      • Maybe it’s just the enterprise architect in me, but I think the complete description of a process would look just like a complete enterprise architectural description of a system. To fully comprehend a process you need to describe:
        * The sequence of activities
        * The agents performing and interacting in the activities (both sw and human agents)
        * The organizational structure(s) in which the agents and activities are situated
        * The architecture of the objects upon which the agents act (eg the case file)

        What shocks me about current BPM/process thinking is that the activity sequence diagram “viewpoint”, eg captured in BPMN, is 90+% of the description of “the process.” I put it more around 10%!

        • @Nick: “I think the complete description of a process would look just like a complete enterprise architectural description of a system” – yes, yes, yes! 🙂

          As you’ll see, I’ve added an update to bring the post more into line with your critiques above: hope it’s somewhat better this time? (I didn’t edit the post itself: it’s best if I leave my mistakes out in public, in part so that others can avoid the same mistakes, but perhaps even more to remind me (and others) that I do indeed screw up sometimes. Or often, probably. Oh well. 🙁 🙂 )

          Many thanks to you (and Ivo) for hauling me over the coals somewhat on this one – was definitely needed.

  2. My question is: why do we need to agree on a definition of the process?

    Yes, it’s true that some people call process a process instance, others a set of instances, then others certain combination of patterns that have high probability of occurrence, other refer to the diagram, others to narrative description, other talk about “state space”, and yes some refer only to automated, some mean only the structured, then we have less- or un-predictable and so on.

    Taylor and Ford had some ideas what the process is and that worked for them. Sloan had another and that worked for him. Then Deming, Box etc etc. Nothing is value-free. For those applying Lean, a good process description is that which makes waste transparent, for Six Sigma people is the one that shows deviation, for BPMS people it’s either an application integration tool or a workflow automation one or both, for process mining people process is what the analyzed logs tell process is, for ACM people the process has a goal that’s about the only certain thing, and of course others just see the process as what they do most often and can have local agreement how to label it.
    Whatever you think the process is, what matters is what you can do with it.

    • @Ivo: “My question is: why do we need to agree on a definition of the process?”

      Exactly. It’s the linear-paradigm that ‘needs’ a static definition – mainly to ‘prove’ that its own view is the one that is ‘correct’.

      To me, ‘process’ is a bit like ‘thing’ – an inherently-blurry term (a ‘metasyntactic variable’ in formal grammar, I think?). Its value is not in the precision of its definition – as with most(?) terms, but in that it remains imprecise rather than precise.

      @Ivo: “Whatever you think the process is, what matters is what you can do with it.”

      Exactly – that’s the whole point here.

  3. 1) Process is explicitly-defined coordination of activities to create a particular result (outcome); process template is abstract description of a process; process instance is enactment of a process template

    There are several variants how template and instance can relate –

    2) I am with Nick – process is more than one relationship between activities, it defines relationships between goals, events, roles, rules, documents, KPIs, etc. Of course, there are many other relationships between those artefact in the EA.

    3) There is a real effect of views/viewpoint: different functional roles may see (perceive) a process differently (like seeing it in their swim-lines only). Usually, this is the case when there is no explicit definition of the cross-functional process.

    4) Processes and services are recursive:
    – all processes are services,
    – some operations of a service can be implemented as a process, and
    – a process includes services in its implementation.

    Such a recursion is enterprise-dependent which creates some “arbitrary” feeling.

    5) It seems that your definition “A process is an arbitrarily-selected view from an arbitrarily-selected viewpoint into perceived-relationships between perceived-activities.” implies that processes are rather implicit.

    Ideally, processes should be explicit and executable (to reduce the wickedness).


    • Many thanks, Alexander.

      Strongly agree with your 2), 3) and 4).

      Other than in certain special-cases, strongly disagree with your assertion about “explicit and executable”, in your 1) and 5) – I’ll explain why in a separate post.

      Thanks again, anyway!

    • Thanks, Ondrej – and yes, re “helpful comments guys”, as can be seen all too easily, I do indeed get it wrong sometimes (often?), and I do “need a little help from my friends” when I, uh, get too far down the rabbit-hole with my (mis)-understanding of ideas… 🙁 🙂 That’s what a community of peers is for: very helpful indeed!

Leave a Reply

Your email address will not be published. Required fields are marked *