At BPM Portugal 2013

Some quick notes on the BPM Portugal conference in Lisbon last week.

It was international in the sense that there were a few ‘foreigners’ like me, who did their presentations in English, but otherwise most of the conference was in Portuguese. And although these days I can read most business-oriented Portuguese, I definitely struggle when it’s spoken-language at full speed… So I’ll have to admit I missed a lot of the detail and the nuances there – though at least I did better than some of my compatriots, who didn’t know any of the language at all. Anyway, this is a brief summary of those parts that I did manage to catch.

First up was Jose Tribolet, professor of information-systems at Instituto Superior Tecnico, Lisbon, on BPM and enterprise engineering. Which, I will admit, tells me straight off that it’s not a good way to go: the very notion of ‘engineering the [human] enterprise’ makes no sense to me at all… The presentation itself was in Portuguese, but the slides were in English, fortunately, which made it just-about possible for me to follow what he was saying. His focus was the DEMO methodology [in Dutch] developed by Jan Dietz, and promoted by the Enterprise Engineering Institute, which seemingly depends on a plethora of impenetrable terms such as B-organization versus D-organization, C-fact versus P-fact, ‘actagenic’ versus ‘factagenic’ and many, many more. Yuk.

I’ve probably said it elsewhere, but to me, Dietz’s ‘Enterprise Ontology’ is the kind of thing that’s exactly what not to use in whole-scope enterprise-architectures: something that only an academic could love, full of absolute assertions and an IT-centric style of spurious pseudo-precision that falls flat on its face at the first sign of real-world requisite-fuzziness. Sigh… To me, the quick-summary version of DEMO is that if you’re doing only IT-automated processes, applied only to information-systems, take an exclusively transaction-oriented view of the business, and don’t need to make any allowance for any form of modality or uncertainty or wicked-problems in any aspect of your modelling, it might perhaps be relevant for you; but for my own part, let’s just say that I’m not a fan, and leave it at that? 🙁

Next up was Keith Swenson of Fujitsu America, on making BPM more amenable to the increasing needs for agility and adaptability. I was much happier with this presentation than the previous one, perhaps because he often gave design-advice that was the exact opposite from that implied by DEMO: for example, he warned that “complex systems can not necessarily be decomposed”, and that “if we enforce a single process, we increase fragility; enforcing a single best-practice on an organisation creates fragility”. And he also talked about the key distinction between ‘plan’ versus ‘planning’ – the ongoing “process and discipline of planning” itself, rather than the usual over-focus on ‘the plans’, the artefacts of that process.

There was nice quote from Ilya Prigogine, that “uncertainty is the heart of creativity”, which lead to an exploration of a spectrum of process-management from most-structured to least-structured, or from classic automation-oriented BPM (which expects everything to be the same each time) to adaptive case-management (which doesn’t really expect anything to remain the same). There was almost nothing I would disagree with there: the only point where I kinda winced a bit was where he said that “case-management is data-centric”, an assertion that, to me, runs the risk of falling back into IT-centrism – but that was probably just a misinterpretation on my part. Overall, very good stuff, anyway.

After that was a round-table with senior folks from various of the larger local enterprises – all in Portuguese, of course, and soon well beyond my limited ability to follow, so I really can’t comment on that.

Then the usual long Portuguese lunch, which gave an opportunity for some very good conversations on EA and the like; and then back to the conference itself, for which we split up into three streams. Which was a pity, because I’d really wanted to see the presentations by Ivo Velitchkov on ‘taskless BPMN’ and Denis Gagné on process simulation, both of whom were on at the same time as my own slot. Oh well: next time, perhaps?

My own presentation was on linking EA and BPM together around a service-oriented concept of the enterprise. Here’s my slidedeck for that presentation, anyway:

This was followed by someone from one of the big-consultancies (whom I won’t name) with a, uh, thinly-disguised sales-pitch for their tools and services, all wrapped up in a sort-of case-study for a government-department – all a bit odd and ‘political’ in places, though perhaps unsurprising given that the respective government minister was part of the show… (Sure, we need to keep our clients happy, yet it kinda reminds me of that wry aside in a Tweet yesterday from Jon Ayre, that “The problem for true #entarchs is that they strive for what is best for the business rather than the man who thinks he is the business”… painfully true! 😐 ) In addition to all the sales-pitch we had to endure here, I was also underwhelmed to note that their ‘new’ approach to architecture and process-management was almost identical to what we’d learned not to do back in Australia a full decade ago… but again no real surprise, given that that kind of systematic myopia and ‘old-wine-in-new-bottles’ is how large-consultancies have always operated. Oh well.

And finally Michael Poulin, on business-processes in the service-oriented enterprise. I’d been looking forward to this one a lot – for obvious reasons, if you’re familiar with my current work and writings here – but I’ll have to admit it was a bit of a disappointment. Michael has some very strange usages of terminology that are, yes, consistent within themselves, but to me just don’t make sense in relation to much from anyone else: for example, asserting that “a business process is predictable, repeatable, robust”, with no term at all to describe any activity that doesn’t always incorporate all three of those attributes; or “business process is a repeatable sequence of conditional steps”, with no means of integration with activities that don’t fit that assumption. The result of these oddly-constrained definitions in turn leads to some very strange assertions: for example, “an outside-in view cannot differentiate between process and service”, or that “a business process is a business service, but the opposite is not always true”. There also seemed to be an assumption that every activity and service-implementation is exactly fungible with everything else – which in real-world practice, especially with any kind of human-in-the-loop, they rarely are. I do like and respect Michael’s work, yet I just couldn’t make sense of this – and I know I wasn’t the only one, either. Will have to explore this more, I guess?

Anyway, overall, a good conference: hence thanks again to Alberto Manuel of ProcessSphere for setting it all up and hosting on the day, and to training-company Grupo Rumos for organisation and coordination. For anyone in BPM or EA, it was well worth attending – and good to see that there’s good work going on in that space, in a country I’ve long admired.

5 Comments on “At BPM Portugal 2013

  1. Tom tells us that:

    Keith Swenson … warned that “complex systems can not necessarily be decomposed”

    This observation stopped me in my tracks. Isn’t “decomposability” the very essence of “systemness”? If something is atomic, it can only be drawn as a single, monolithic “component”. How does one model (as a system) something that cannot be decomposed, especially if its behavior is not amenable to a manageable “input/output function”?

    I have become increasingly convinced of late that treating something as a system is simply our imposing a view on it that renders it to some degree tractable to analysis and thus understanding.

    Calling something a “system” is in some sense a tautology; everything is a system. The insight of systems thinking comes from simultaneously adopting an integrative system-wide (“holistic”)perspective and a reductionist (“components and their relationships”) prespective, and keeping the two in balance.

    That is, its “systemness” really only exists in our minds, depending on where we choose to assert the existence of boundaries between regions (for lack of a better word) of the “system”, and how we relate them to one another and to the whole.

    We may choose these boundaries based on observations of what appear to us to be properties (physical or metaphysical) shared by regions, but we have to understand that these boundaries are determined by the properties we choose to use to delineate them.

    And these boundaries in turn determine the interfaces between the regions they partition the system into. This works both ways — one way to approach the partitioning problem is to look for a partitioning that requires the simplest interfaces between the regions.

    I think what Swenson meant to say is that it may not be possible to decompose a “complex system” into components whose interfaces are not themselves arbitrarily complex (both statically and dynamically)


  2. I reread my comment and noted that “shared by regions” may be misread. A better way to put it would be “shared within regions”, the implication being that different regions share different properties (or sets of properties).


  3. Hi Tom:

    First, I would like to express that your point of view reflects a style that should be taken as reference, rather than being polite.

    Nevertheless, and taking into consideration some opinions regarding others presentations, I would like to express that the community needs to start explaining more about the HOW to do it and relevance of concepts, because this is what the people expect to understand.

    For example I’m not a big fan of DEMO,I think is very fine grain and only focus on profess operation conformity checking. Hence is not a fully and complete enterprise architecture, but is being pitched as such. Hence, my point of view is more that we should teach more and opinion less if want help people out.

    This is more an outside in reflection than a criticism to your blog post, that again should be taken as reference once people only highlight what like most.

    It was a pleasure to have the you at the conference.


  4. Tom,
    nice post.

    I wanted to respond to the comment by Len Fehskens who said ‘ Isn’t “decomposability” the very essence of “systemness”?’

    A complex system can not be decomposed into components that stand on their own because all the part of a complex system are interdependent on each other.

    An automobile engine is complicated. You can take the spark plug out, hook it up to an electric source, and produce sparks without the rest of the engine being there. The transmission translates the rotational velocity with or without an engine attached.

    However, if you look at a system like a hurricane, you have definable features, like the eye which is a calm spot. However, the eye of a hurricane can not be removed from the hurricane itself. It is intrinsically tied to the rest of the system. Storms are complex, and they certainly are systems (so this is not a tautology) but you can not break a storm into pieces that function on their own.

    Ecosystems are the same thing. What is the function of a predator? It is more complex than you think. There is a famous case where they started removing the predators from Yellowstone National Park. This caused an over abundance of deer and moose. They started eating and wiping out all the foliage, which caused the deer and moose to die out. The predators are clearly a part of the ecosystem, but they can not function on their own, and it is not really clear what the full dependency between predators and prey are. This is what I mean by a system that can not be composed: we see parts, but they do not have a clear function independent of the rest.

    I guess that is pretty much the same as what was concluded: the interfaces are not clear or are arbitrarily complex themselves. They way I would say it is that every part depends on so many other parts that you can not break out a part to stand on its own.

    Human organizations are like this. We like to think of an organization as a machine, but it isn’t. Treating an organization like a machine gets us into a lot of trouble.


Leave a Reply

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