Was it Lisbon that attracted me so much or the word Cybernetics in the sub-title or the promise of Alberto Manuel that it would be a different BPM conference? May be all three and more. As it happened, the conference was very well organised and indeed different in a nice way. The charm of Lisbon was amplified by the nice weather, much appreciated after the long winter. As to Cybernetics, it remained mainly in the sub-title but that’s good enough if it would make more people go beyond the Wikipedia articles and other easily digestible summaries.
My presentation was about using task-free BPMN which I believe, and the results so far confirm, can have serious benefits for modelling of both pre-defined processes and those with some level of uncertainty. In addition, there is a nice way to execute such processes using reasoners and achieve transparency in Enterprise Architecture descriptions which are usually isolated from the operational data and neither the former is linked with what happens, nor the latter gets timely updates from the strategy. More on this in another post. Here’s the slidedeck:
In his latest article Ancient Wisdom teaches Business Processes, Keith Swenson reflects on an interesting story told by Jared Diamond. In short, the potato farmers in Peru used to scatter their strips of land. They kept them that way instead of amalgamating them which would seem like the most reasonable thing to do. This turned out to be a smart risk mitigating strategy. As these strips are scattered, the risk of various hazards is spread and the probability to get something from the owned land every year is higher.
I see that story as yet another manifestation of Ashby’s law of requisite variety. The environment is very complex and to deal with it somehow, we either find a way to reduce that variety in view of a particular objective, or try to increase ours. In a farming setting an example of variety reduction would be building a greenhouse. The story of the Peruvian farmers is a good example of the opposite strategy – increase of the variety of the farmers’ system. The story shows another interesting thing. It is an example of a way to deal with oscillation. The farmers controlled the damage of the lows by giving up the potential benefits of the highs.
Back to the post of Keith Swenson, after bringing this lesson to the area of business process, he concludes
Efficiency is not uniformity. Instead, don’t worry about enforcing a best practice, but instead attempt only to identify and eliminate “worst practices”
I fully agree about best practices. The enforcement of best practices is what one can find in three of every four books on management and in nearly every organisation today. This may indeed increase the success rate in predictable circumstances but it decreases resilience and it is just not working when the uncertainty of the environment is high.
I’m not quite sure about the other advice: “but instead attempt only to identify and eliminate “worst practices”. Here’s why I’m uncomfortable with this statement:
1. To identify and eliminate “worst practice” is a best practice itself.
2. To spot an anti-patterns, label it as “worst-practice” and eliminate it might seem the reasonable thing to do today. But what about tomorrow? Will this “worst-practice” be an anti-pattern in the new circumstances of tomorrow? Or something that we might need to deal with the change?
Is a certain amount of bad practice necessarily unhealthy?
It seems quite the opposite. Some bad practice is not just nice to have, it is essential for viability. I’ll not be able to put it better than Stafford Beer:
Error, controlled to a reasonable level, is not the absolute enemy we have been thought to think of. On the contrary, it is a precondition for survival. [...] The flirtation with error keeps the algedonic feedbacks toned up and ready to recognise the need for change.
Stafford Beer, Brain of the firm (1972)
I prefer to call this “reasonable level” of error requisite inefficiency. Where can we see this? In most – if not all – complex adaptive systems. A handy example is the way immune system works in humans and other animals having the so called adaptive immune system (AIS).
The main agents of the AIS are T and B lymphocytes. They are produced by stem cells in the bone marrow. They account for 20-40% of the blood cells which makes about 2 trillion. The way the AIS works is fascinating but for the topic here of requisite inefficiency, what is interesting is the reproduction of the B-cells.
The B-cells recognise the pathogen molecules, the “antigens”, depending on how well the shape of their receptor molecules match that of the antigens. The better the match, the better the chance to be recognised as antigen. And when that is the case, the antigens are “marked” for destruction. Then follows a process in which the T-cells play an important role.
As we keep talking of the complexity and uncertainty of the environment, the pathogens seem a very good model of it.
The best material model of a cat is another, or preferably the same, cat.
N. Wiener, A. Rosenblueth, Philosophy of Science (1945)
What is the main problem of the immune system? It cannot predict what pathogens will invade the body and prepare accordingly. How does it solve it? By generating enormous diversity. Yes, Ashby’s law again. The way this variety is generated is interesting in itself for the capability of cells DNA to carry out random algorithms. But let’s not digress.
The big diversity may increase the chance to absorb that of pathogens but what is also needed is to have match in numbers to have requisite variety. (This is why I really find variety, in cybernetic terms, such a good measure. It is relative. And it can account for both number of types and quantities of the same type.) If the number of matches between B-cell receptors and antigens is enough to register “attack”, the B-cells get activated by the T-cells and start to release antibodies. Then these successful B-cells go to a lymph node where they start to reproduce rapidly . This is a reinforcing loop in which the mutations that are good match with the antigens go to kill invaders and then back to the lymph nodes to reproduce. Those mutations that don’t match antigens, die.
That is really efficient and effective. But at the same time, the random generation of new lymphocytes with diverse shapes continues. Which is quite inefficient when you think of it. Most of them are not used. Just wasted. Until some happen to have receptors that are good match of a new invader. And this is how such an “inefficiency” is a precondition for survival. It should not just exist but be sufficient. The body does not work with what’s probable. It’s ready for what’s possible.
The immune system is not the only complex system having requisite inefficiency. The brain, the swarms, the networks are just as good examples. Having the current level of study, the easiest systems to see it in are ant colonies.
When an ant finds food, it starts to leave a trail of pheromones. When another ant encounters the trail, it follows it. If it reaches the food, the second ant returns to the next leaving trail as well. The same reinforcing loop we saw with the B-cells, can be seen with ants. The more trails, the more likely the bigger number of ants will step on it, follow it, leave more pheromones, attract more ants and so on. And again, at the same time there always is a sufficient amount of ants moving randomly which can encounter new location with food.
The requisite inefficiency is equally important for social systems. Dave Snowden gave a nice example coincidently again with farmers but in that case experiencing high frequency of floods. Their strategy was to build their houses not in a way to prevent the water coming in but to allow the water to quickly come out. He calls that “architecting for resilience”:
You build your system on the assumption you prevent what can fail but you also build your system so you can recover very very quickly when failure happens. And that means you can’t afford an approach based on efficiency. Because efficiency takes away all superfluous capacity so you only have what you need to have for the circumstances you anticipate. [...] You need a degree of inefficiency in order to be effective.
It seems we have a lot to learn from B-cells, ants and farmers about how to make our social systems work better and recover quicker. And contrary to our intuition, there is a need for some inefficiency. The interesting question is how to regulate it or how to create conditions for self regulation. For a given system, how much inefficiency is insufficient, how much is just enough and when it is too much? May be for the immune systems and ant colonies these regulatory mechanisms are already known. The challenge is to find them for organisations, societies and economies. How much can we use from what we already know for other complex adaptive systems? Well, we also have to be careful with analogies. Else, we might fall into the “best practice” trap.
This is in response to the recent article of Richard Veryard “Arguing with Mendeleev”. There he comments on Zachman’s comparison of his framework with the periodic table of Mendeleev. And indeed there are cells in both tables with labelled columns (called “groups” in Mendeleev’s) and rows (“periods” respectively). Another similarity is that both deal with elements and not compounds. The same way the study of properties of oxygen and hydrogen will tell you nothing about the properties of water, the study of any two artefacts from Zachman framework will tell you nothing of how the real things they stand for work together. In fact you may not even get much about the separate properties of what the artefacts represent. Anyway, if there are any similarities, this is where they end.
I’ll not spend much time on differences. They are too many. But let me just mention two. The periodic table is a classification based on the properties of the elements. The order is determined by atom numbers and electron configuration. Both groups and periods have commonalities which make them an appropriate classification scheme. Once the rules are established, the place of each element can be confirmed by independent experiments and observations. That’s not the case with Zachman’s framework.
Richard comments on the statement that Zachman’s scheme is not negotiable:
What makes chemistry a science is precisely the fact that the periodic table is open to this kind of revision in the light of experimental discovery and improved theory. If the same isn’t true for the Zachman Framework, then it can hardly claim to be a proper science.
I haven’t heard the claim that Zachman’s framework is a “proper science” before. In my opinion, Zachman’s main contribution is not his framework as such but the fact that it created a new discipline and new profession. The scheme itself is arbitrary. The columns, as we know, are based on six of the interrogatives: what, how, where, who, when, and why. Whether is missing, also how much. In the old English there is also whither, which is similar to where but has an important specifics – it is related to direction (whereto). But I’m not questioning the number of columns. I have doubts about their usefulness in general.
Let’s just take three of the of the interrogatives: what, how and why and test some questions:
1. What do you do now? Answer: B
2. Why do you do B? Answer: because of A
3. How do you do B? Answer: by means of C
And now with a simple example:
B = buy food
A = I’m hungry
C = going to the supermarket
Now let’s focus on the answers and ask questions to learn more. First on C:
I’m going to the supermarket.
Why? Answer: to buy food
Why you need to buy food? Answer: because I’m hungry
Now let’s focus on A:
I’m hungry. Well, this is a problem. So we can ask:
How can I solve A? Answer: by doing B
How can I do B? Answer: by doing C
So if the relativity of the focus is ignored then what is equal to why is equal to how. (Speaking of focus, or perspective, this is where the rows in the framework come to play. This is a nice game itself which we’ll play another time).
In this example the answer of what is related to activities and not to their object (food) which by itself questions how appropriate is to label the data column “what”.
But of course rigour is not imperative. And neither is logic. After all it shifted its function from a tool to win arguments into a tool to seek truth. And then logic is quite materialistic, while EA seems a spiritual practice. Which reminds me also of the mind over matter one-liner:
If you don’t mind, it doesn’t matter.
In the Australian Aboriginal culture, Dreamtime “is a complex network of knowledge, faith, and practices”. Both the word and thus cited definition invite vivid associations. The latter, with what is commonly referred to as Enterprise Architecture (EA), the former – with its current state.
Note: With this I’d like to depart from further analogies as I respect the culture of Aboriginal people in general in the part related to Dreamtime in particular. I’ll refer to drEAmtime in this article solely as to what I currently see is the state of play of EA.
The drEAm of the common language
It is believed for a long time now that there is a wide spread misalignment between ‘Business’ and ‘IT’. The IT in this context is used to refer to employees that carry out activities closely related to development, procurement and maintenance of information systems, and ‘Business’ – to those who don’t.
The division of labour, which is the predominant way of structuring organisations, naturally invites different specialists with different background (neatly matching the fragmentation of the educational system) and it is to be expected that they would use different terms, or the same but imply different meaning. It is interesting to note that even if this is the case between, say, accounting and production, the miscommunication between IT and the rest attracts the highest attention. Maybe it is due to the increasing dependency on IT combined with stories of spectacular failure, or because IT as an area with incredible rate of innovation, and thus the sense of leading, has to follow orders by those belonging to somewhat lagging ones. In any case, there is general agreement about the problem of miscommunication and the associated high cost.
Here comes Enterprise Architecture to the rescue. Doing what? Introducing a third language. What’s even worse, a language ostensibly similar to both ‘Business’ and ‘IT’. But just check some EA terms to see how people from ‘Business’ and ‘IT interpret them. Take for example the most common ones like service, capability, function, model, viewpoint and artefact. The resulting situation looks something like this:
It is quite absurd but let’s imagine for a moment that it’s not. At best we would see the following vicious circle. The strong IT smell of the EA language decreases the chance of the Business to believe that they would benefit from learning it and that explains the low motivation and buy-in. Even though the cognitive load for IT is much lower, seeing the willingness of the Business to ‘improve’ its literacy, IT people find better things to be busy with. And another funny point. When there is some buy-in by the Business, EA is put under IT, not between business and IT. Then EA people complain they can’t do much from there. But maybe they are put there just because they can’t do much.
Closely related to the dream of the common language is
The drEAm of bridging the silos
Some of this dream is part of the previous. But here is another. The EA people instead of building a bridge between the two silos, create a new one. And at certain point they find themselves in the position where neither Business nor IT regards them as a bridge any more. The Business people trust EA people even less than IT because they see them as cross-dressed IT. IT people loose trust to EA as well because they are not sure they understand the Business and if they still remember what was IT. Further, IT managers need support which EA does not have the authority to ensure.
And there is an additional effect. EA is often in the position to attract some serious budgets for reasons we’ll see in another dream, and this way the new island becomes a safe territory for people that have either failed or lost interest in the pure IT. This as a result further decreases the credibility of EA which slowly, in some organisations, gets the image of a place for people that are not good enough for IT and prefer to hide under EA labels where things are vague enough and much more difficult to measure. The lost credibility either undermines the work of the really good EA practitioners or pushes them out of the organisation or both.
But what part of the work of EA is quantifiable? One tangible result of successful EA seems to be the rationalisation of the application landscape. And as this brings efficiency, it is easier to measure. This I call
The drEAm of IT cost reduction
Big organisations in all sectors, especially in the service industries, tend to gather huge number of applications until they find themselves in a situation where there are far too many to manage. A good number of them are not used at all. Some other part is underutilised. Most of the critical applications have high maintenance or high replacement cost or both. Inevitably there are many which automate different parts of the same process but they don’t talk to each other. And this justifies new spending on building interfaces, or buying application integration packages first and then replacing them with BPMS and then probably with something better than BPMS. As a result – more spending and more applications to manage.
An addition to application integration problems are the redundancy ones. A number of existing functionalities, and I’ve seen in a few organisations this being over fifty per cent, are duplicated in one or more applications to some extent or quite completely.
Yet another common situation are patchwork applications. Those are applications that have certain utility but don’t quite well meet the needs, or just the needs change with the usage or as a result of some change in the business. In any case it is found better to add the missing functionality instead of replacing the whole application. And then again and again, layers of patches of additions and fixes until we have a real monster and the roles of the master and servant are swapped.
One day all these silo applications, functional redundancies, patchwork systems and suchlike create a serious enough mess and shocking numbers in the financial statements to convince the top management that something have to be done and rather soon.
But just when the situations seems really critical, the door opens with a kick and EA cowboys enter. They pull out frameworks and architecture tools from their holsters and in slow motion (a very slow motion), they shoot inefficiency after inefficiency until all of them lie dead on the floor. Then they walk out and go to shoot inefficiencies in some other town and when new inefficiencies appear in this town they come back again to kill them out.
Here is what happens in fact. Some attempts to achieve IT rationalisation fail spectacularly. I’m not going to list out the reasons for that. It is maybe sad that such failures discredit EA as management discipline as a whole. But sometimes Enterprise Architects are really able to find ways to discover what’s not needed and how to remove it, or what is underutilised and how to achieve better ROI for it. After all most of them are smart people using good tools. And indeed they shoot inefficiencies and get all the glory and the money to shoot more. But as they rarely get to the cause of the inefficiencies or are in the position to influence the bigger system that produces these inefficiencies, the overall result is an oscillation or even increase in overall IT spending. The increase is because the success of the EA justifies bigger EA budget which is almost without exception a part of the IT budget.
The drEAm of dealing with complexity
This dream have specifics of its own but it can also be used to explain the whole drEAmtime.
If you are an Enterprise Architect, a popular way to deal with complexity is to arm yourself with a framework. With a good framework, it is believed, you can do two things. First, reduce the variety of the enterprise to just a few things that share the same properties, according to some classification theory and where things doesn’t fit, add more layers of abstraction. And second, reduce the things you can possibly do to just a few but well defined and in a specific order, with well prescribed inputs and outputs, because that was common for so many organisations that did well so that it became a best practice, and the chances are, if you follow this way, it will do you well as well. Now, because of the shared understanding of the beneficial role of the abstract layers, and the boundaryless imagination unconstrained by the reality, there is a serious number of frame-works and on top of them other-works on how to adapt and adopt them.
Then of course modelling itself is believed to help in dealing with complexity. But what kind of modelling? A very complicated architecture diagram does not show complexity. It just shows a lot of effort spent in denial of it.
The part related to complexity certainly deserves a separate post and maybe more than one. As this one got pretty long already, for my standards that is, let me just finish with the following: dealing with complexity is not reduced to finding ways to reduce it. It requires much different understanding of what happens when interactions are not linear. When there is dynamics, adaptation, self-organisation, irrational behaviour, politics and power.
In summary, more often than not, when contemporary mainstream EA is trying to introduce a common language, it creates confusion and additional work to deal with it. When trying to bridge the silos, it creates new silos instead. When trying reduce the IT spendings, it in fact makes no change or increases them. When trying to deal with complexity, it’s just pathetic.
HR Manager: What do you do?
DB Designer: I work with databases.
HR Manager: More specifically?
DB Designer: I design them.
HR Manager: Good, so you are an Architect!
DB Designer: Well, yes you can put it that way, I guess.
HR Manager: Who uses the databases you design?
DB Designer: Many departments, in fact big part of the enterprise.
HR Manager: Great, so you are an Enterprise Architect. That’s your new title, congratulations!
DB Designer: …!?
(related post: Where to start?)
Definitions are attention-seekers. And good ones. They get much more attention than they deserve.
I’ve just read a post by Nick Malik called Many (flawed) Definitions of Business Architecture. There he does a very good job of analysing the existing definitions of Business Architecture. He comes to the conclusion that all of them need to be improved, including his own one.
Tom Graves recently wrote about the Meaning of process. In my comment I asked why do we need to agree on a process definition. For similar reasons I doubt that we need to spend too much efforts on arriving at a better definition of Business Architecture.
Would a better definition, being some-body’s statement or many-body’s convention, make a definition-compliant Business Architecture better? Would making Business Architecture better make the business better? The business may get better without a good Business Architecture and having a good one would not necessarily make it better. Quite similar applies for the definitions. You can have a good Business Architecture with a wrong definition and vice versa.
Nick Malik listed and categorised 20 definitions of Business Architecture. The fact that they are so many speaks about the amount of efforts spent on them including – on discussing them. Not that I’m not tempted as well. Especially by some of them. Let’s quickly check for example the definition of TOGAF, starting not with the explicit statement, but the implicit meaning taken from the TOGAF content. (Here I go, could not resist) If something belongs to Business Architecture domain, it doesn’t belong to Application Architecture, unless I’m misreading something. For example applications are not part of the Business Architecture. Well, if we strip down the Architecture dress, applications does not belong to the business. Although the business paid for them. Nice. Business is practicing Aparigraha. I’m all for.
If the business is split into social and technical part, then applications would rather be in the technical, than in the social. That I can understand. But when we distinguish business and application domain… Or maybe when ‘business’ is used as adjective for architecture, things are different? Anyway, it seems that in some contexts this type of abstraction works. Or at least I hope so, otherwise why so many smart people are following TOGAF? Still, some deductions from the Architecture of TOGAF makes it not very reliable tool for the Architecture of the Enterprise.
If we take the explicit definition itself, things get even worse: “The Business Architecture defines the business strategy, governance, organization, and key business processes.” Business architecture does not define strategy, people define strategy. It might be that there are models used to support the strategy and these models are classified as belonging to Business Architecture. But that doesn’t help the statement make more sense.
Now again back to content, there is very little mentioned about strategy in the TOGAF Architecture Development Method, although it deals with Business Architecture to support the claim that it is Enterprise- and not IT-architecture framework. Then in the Architecture Content Framework, things such as driver, goal, objective and measure appear (recently!) in something called ‘Motivation Extension’. Isn’t it odd to have goals and drivers in an extension? Shouldn’t we rather place them in a… more central place?
May be it’s better to determine things by their relation with other things, such as relating talk with walk (the above example refers), model with reality, common with sense…
On the other hand definitions are important. They really are. Also – a bit less though – in the areas such as Enterprise Architecture. It’s just that spending too much efforts on them often has high opportunity cost.
Beliefs are powerful. Sometimes, to achieve something, all we need is to hold on to our beliefs. Then there are times when we can’t get where we want to be, unless our beliefs are seriously shaken and eventually changed.
Beliefs can influence our capabilities. And the evidence of our capabilities can change our beliefs.
Let’s explore this a bit.
Our conscious actions are based on conscious decision and unconscious determinants and they – on our beliefs. Our actions change the environment and ourselves and then we sense and interpret the changes which in turn influences our beliefs and actions. One way to see these interdependencies is by using the ladder of inference, developed by Chris Argyris. You can easily find a lot of resources based on the original model on the web. Here I’ll use and further modify an interpretation by Gene Bellinger where it’s actually represented not as a ladder but as a reinforcing inference cycle.
From the observable data and experience we select some and affix meaning to it. This forms the basis of our assumptions. And then we come to conclusions which in turn influence our beliefs. Our beliefs are the basis of our actions which bring more data and experience from which we select some, affix meaning and so on. We tend to believe that we affix meaning to the observable data, oblivious of the selection we always make. In a similar way we believe that we draw conclusions by clear reasoning, while we actually always apply some assumptions.
I made a few modification of this cycle. The first one is making some of the choices explicit. We make choices in many places in the cycle, notably before Actions but also after Observable data where we choose what to pay attention to and then when we try to make sense of it. For now I added only one more variable: ‘Decisions’. It comes before Actions and after Beliefs. Our Actions are based on Decisions which are influenced by our Beliefs.
Now the cycle looks like this:
The second modification is the addition of another direct influence, this between Beliefs and the sense we make out of the selected experience. Beliefs limit the way we perceive reality (the balancing loop B2), and they do much the same with the way we make sense of it (the balancing loop B3). Thus Beliefs affect three types of choices we make: on actions, on selection and on interpretation of data and experience. Now we have three loops and depending on which one of them is stronger, the system can work in a different way. It can work as a learning cycle or as an obsession. It can work also as something which I call ‘sustainable system of fallacies’.
Yes, Beliefs influence directly action, selection and interpretation but they go even further than that.
As with believes above, it’s easier to use something that has proved working than starting from scratch. My choice of model here is the logical levels of Robert Dilts. Again I made a small modification but only on the style:
Apart from refocusing, this modification makes it look a bit like a tornado. And I like it like that.
As it seems this model is quite useful in various arias, from communication and therapy to management and leadership. Dilts gives a good communications example with the different choices a teacher has for commenting a student’s poor results on an exam. The suspected cause could be a noisy room, thus the feedback being at environmental level. Alternatively the teacher could point out that particular performance instance, thus addressing the student at the level of behaviour, or comment on student’s current skills on that particular subject which are at present less developed than on other subjects. That would be an example of communication at the level of capabilities. Yet another option is to discuss the importance of this subject and and by doing so touch the value system (level of beliefs). And then of course would be the worst choice, calling the student stupid, which would be right at the level of the child’s identity.
According to Dilts, “a belief is a generalization about a relationship between experiences”. He points out more specifically those about causal relationships, meaning and limits. The latter seems very pertinent to the way beliefs influence capabilities. But there are other ways as well.
An insight on those comes when we merge the two models. All variables in the cycle of inference, with the exception of Observable data and experience are influenced by certain type of capability. The most obvious one is our capability to carry out the chosen Actions. It may be an existing one which we have access to and can use, or one that exists but we are not conscious of and don’t have access to. The third option is the chosen actions need capabilities that we have to build or buy.
In a similar way we need capabilities for data selection and sense-making. Next comes our capability to challenge assumptions. As all reinforcing loops, the inference one can be vicious or virtuous. Sometimes the difference between one or the other may depend just on our capability to challenge assumptions.
While looking at this model we shouldn’t forget that one’s inference cycle is linked with inference cycles of others. One such influence can be easily seen when we look at Decisions. When a politician makes certain promise during elections that would create experience for others and expectation, for example, that the promise will be kept. Many cycles later, that politician may have other beliefs, based on new experience but decide to make actions based on old promised to maintain the perceived trust although she may believe that these actions would not have positive outcome to those whose expectations should be met. Or the opposite. She may follow her new beliefs which would fulfil the expectation of those who did not believe in initial promises and disappoint those that did, thus having less support to carry out the chosen actions although they might be those that would bring better outcome for both groups. The choice would depend on values. And beliefs and values are very closely connected.
There are more findings to share about all the variables in the cycle and those representing some types of capabilities. But let’s first apply it to itself and try to put it in a learning loop:
I believe that this model, which is based on some filtering and sense-making choices, now that is published, will add to the available data and experience, which will provoke hopefully some feedback to add more data, on which we’ll make new selection and will probably change our assumptions, conclusions and eventually beliefs. Then, based on what we’ve learned, we might come up with a better model.
A conversation with Eddy Vanderlinden
Semantic technologies have been some temptation for me for quite a long time. That was mainly due to my growing frustration about the utilisation of data resources both inside corporations and outside, on the Internet. Then all mainstream modelling methods used for analysis or for database design and application development, with all their charms and weaknesses, often leave me with the feeling that they put too much constraints for people to express things and too less for computers to understand them. That and the suspicion about the potential of Semantic Technologies is not new to me. What is new, is the experience of their pragmatic application and the opportunity to see some all too familiar areas through ST lenses. Both of these I owe to Eddy Vanderlinden. In this sort of interview, I asked him a few questions the answers to which might be of interest to the readership of this blog.
Ivo: When was you first meeting with ST?
Eddy: In 2007, when searching for possibilities to avoid the registered dysfunctions.
Ivo: What was the most fascinating thing for you in beginning and how did this change? I mean, which part or capability of the ST is the main driver for you now, after so many years of practice?
Eddy: The most fascinating aspect was the data modelling aspect, so that data became real information. The upgraded function for data towards information covered the common and precise understanding for all stakeholders of concepts through their relation with other concepts. Also the flexibility of the data model was contributing to the great benefit.
There are two main drivers added later on:
1. The knowledge discovery possibilities through the open-world assumption. Under the condition we adapt our state of mind from comfortably categorising "things" into a state whereby we discover through the ST technique new aspects. In philosophical terms, we should become a bit Tao: flexible, accept change as the only certainty and being attentive to capture change and utilise it for our benefit.
2. The possibility to convert knowledge models straight into running applications so that unambiguous goals are obtained through commonly understood and mastered methods.
Ivo: There are people over-enthusiastic about Semantic Web, calling it "Web 3.0", "the next big wave", "the gigantic …. graph" and so forth. At the same time there are many sceptics and even people that had been once enthusiastic about it, and now seem rather disappointed. What do you think about this? Is ST rather overrated or undervalued or somehow both? And why?
Eddy: ST is to my understanding by far undervalued. Lets see first why one could be disappointed. One reason might be because lots of people betted on the possibility that web publishers would start to use html tagging techniques massively so that slightly adapted search engines could simply exploit the semantics in the text. So, the search engines would not only have keywords (from the html header) and page titles but also tags from within the text as source for semantic searches. The most popular standard which was proposed to execute this is RDFa. Personally I never believed this would be a success. Not only because the user needs to put additional efforts but also because tagging does not provide relationship information between the tags. So, these people may be disappointed but can consider text analysis, spongers for email and spreadsheets as alternative approaches (see IBM’s DeepQA).
Another group of disappointed people could be the ones who thought that putting all information on a subject into an ontology would solve all their problems. This is by far not the case. Modelling should be done with a purpose in mind. As Dean Allemang writes, it is a craft. Don’t underestimate the power of the models but accept they provide answers to the questions you want answered. If more than that is needed, ST has to be combined with probabilistic methods (see earlier on IBM’s DeepQA project).
Another group of disappointed could be people who want massive amounts of data treated with today’s reasoners. Although reasoners became much more performing, industries with huge amounts of data (like the finance industry) should approach that data in specific ways, sometimes emulating the reasoners with alternative technologies (e.g. SPIN and rules engines of triple store suppliers). Honestly, if we don’t know what the reasoner should deliver, we cannot model effectively. It would probably mean we are not rightly involving ST.
The reason for my conviction of undervaluation is that for the above objections there are far-reaching alternatives which are opening new horizons in all fields of applications. Furthermore, there are new domains starting to adopt semantic technologies. Artificial intelligence is such a domain. To my knowledge, the most impressive result of this is IBM’s DeepQA project. I know the reluctance of ST people being associated with AI because they feel AI did not bring them much, on the contrary, they brought a lot to AI. In my opinion, implementing the probabilistic approaches, besides other AI techniques, with ST brings a lot of added value to ST. Lets not forget ST is strongly domain oriented, while probabilistic approaches may help generalise solutions from combined domains. I expect a lot of input also from the KM community . While this community used ontologies from the beginning (in different ways than web ontologies), the love between the ST an KM communities is not to be called ideal. When the KM community will embrace the possibilities offered by ontologies in Descriptive Logic (OWL-DL compliant), the benefits will contribute both communities. See http://semanticadvantage.wordpress.com/category/semantic-technology/
Ivo: It seems that you don’t much associate yourself with the Semantic Web community. Is that so? What do you think are the main mistakes, of fallacies of the Semantic Web movement that would actually jeopardise or postpone Semantic Technologies getting more tangible traction?
Eddy: First I would like to stress that the solution proposed for the operational dysfunctions owes everything to the SEMWEB community. I cannot thank them enough. If I am less associated today the reason might be laziness. I have to update my vision of their activities again. You see, when these technologies became of strategic importance for USA and for Europe, lots of financial means were directed to the development of standards. In the beginning, the SEMWEB community was mainly busy developing standards complying with Tim Berners-Lee’s architecture vision.
Later came the tools with pioneers as: Clarks & Parsia (Pellet reasoner), Stanford University (Protégé), Berlin University (software language adaptations for ST), Zurich university (Controlled English communication), HP with Jena Laboratories (triple stores and SPARQL). Very rapidly a vast community of tool producers followed. This was really exciting. I could only participate as tester, commenter in small fields since the main discussion point then was on tool development.
Later commercial players joined the community: Topquadrant with a software development platform including creation of services and web server, OpenLink Software for heavy duty triple and quad stores and a few more. The problem is the applications are mainly being adopted by the academic and scientific world, not yet by business users. I’ll check this for updates again.
Ivo: A recurring pattern in the lessons learnt you share on your site is related to losses when conceptual data models are transformed into physical. And another is related to the missing time dimension. Can you please tell us more about those two and how they are solved by applying ST?
Eddy: On the transformation conceptual to physical, Business analysts have different tools at their disposal to represent the real world operations in a conceptual manner. They are mainly grouped in what we know as the UML diagrams, a collections of diagramming methods. Starting from these conceptualisations, technical analysts, programmers and a collection of other specialised people (data engineers, interface designers, service engineers, …) start developing a functionality involving those concepts. I will not repeat the classic picture of the swing illustrating the difference for the user, anyone can make his own version here. This is solved in ST by software using the ontology as their data source. A perfect example is the Topbraid suite. Another popular tool is provided by Openlinks Software, not to forget the Fresnel lenses.
On the time dimension. There are only few universal laws. Knowledge about facts is merely related to and valid for a portion of time. Meaning, an assertion is true at a certain moment or time-period. E.g. an organisation, the price of an item, the specification of a product. Whoever has been involved in data mining will recognise 2 main challenges: denormalization of related data and time-dimensional information. The purpose is to reconstruct any state of the company at any moment in time. The reason is, we cannot find out cause and effect information if we can’t partition facts into the time dimension. This is done in ST, mainly in a similar way as with conventional data-management systems: adding a time-dimension property to any individual, member of a class.
Ivo: What are currently the best examples of using ST?
Ivo: Is there something that you see as a big potential of ST which has not come to fruition, which for some reason nobody was able to realise so far?
Eddy: To me, it is strange the possibilities for application development are not really applied.
Ivo: You have been and are currently involved in BPM activities. What do you think ST can bring to BPM? Do you see it as a flavour of BPM (there is something called Semantic BPM already) or as an alternative approach to what most of the companies use BPM for?
Eddy: I am not in favour of "semantic BPM". The reason is linked to my answer in the beginning: it requires tagging the models and their objects. I certainly see it as an alternative approach to what most companies use BPM for.
Ivo: You worked in banking for quite a long time. Let’s talk about Semantic Technologies as an investment. It seems that many types of innovation if judged using DCF or other popular methods, look riskier than do-nothing strategies. What type of evaluation would convincingly justify investment in Semantic Technologies today?
Eddy: The answer focuses on semantic technologies as an investment, not as a banker investing in companies with an expected DCF of X EUR/USD. The latter requires a much broader approach than just DCF, RONIC, or similar. Notably what we may understand by "expected" cash flows, introducing Beta factors, sector and currency valuation of future trends, market valuation in economic context,… So working in the banking sector will not help providing an answer here. Prior to the investment selection step, the proposal is to position ST in a strategic perspective analysis. That analysis would answer the questions:
A. On the portfolio management issues: A1. What new products can be offered in our portfolio with ST? A2. How will ST affect existing products in our portfolio? A3. Which new markets can be explored with the products discovered in A1 and A2? A4. How are these new markets evolving in the strategic time perspective? A5. How are the products discovered in A1 and A2 influence our competitive position in the new markets discovered in A3? A6. How is our competitive position evolving compared to A4? Suggested method: portfolio management matrix of the Boston Consulting Group.
B. On the strength of the organisation: B1. How does the application of ST reduce the risk of new competitors coming in the market? Where can the organisation start competing in new markets? B2. How does ST application affect our negotiating power with supplier? B3. How does ST application affect our negotiating power with customers? B4. How is the threat of substitute products in our markets mitigated through ST application? How can we form a defence against substitutes in existing markets? B5. How is our strength affected toward competitors considering the price of our products and services, the quality of our products and the service level? (Inspired by Porter’s 5-forces model.) After a thorough SWOT analysis, when the product/market matrix is finalised, the production simulations ran and the investments are figured out, cash flows can start to be projected on a strategic horizon (3-5 years). Eventually other analysing techniques may be needed. Choosing for semantic technologies gets a completely different perspective when compared to "do nothing" scenario if we make the exercise as mentioned above compared to a pure accounting approach.
Ivo: Now about reasoners. Why there are so many of them? How they differ from each other? How to choose? When to use which?
Eddy: I wished I had a clear-cut answer to that question. When building the finance ontology in 2007-2009, I tested 5 reasoners. On the correctness of the inferences: for an expected inference, I could get 4 different answers. The conclusion at that time was, the best reasoners depended on the inference needed. The reason might have been for a part the shift from OWL 1 to OWL 2 but it makes me test the inferences at each construction of a model with different reasoners. On the speed of the inference: in the beginning some very well performing reasoners went commercial only. Meanwhile some free reasoners upgraded their version and new players entered into the field. Further I would like to remind the relative importance of reasoners in heavy life applications: see higher under SPIN and rule engines.
Ivo: If I start asking about ST languages, the answer might be much bigger that all answers combined so far. May be we can post a separate conversation about that. Still, this one could not do completely without it. About the OWL then… OWL is (arguably) the leader in knowledge representation. Some think that the main advantage is that it is decidable, not probabilistic. Others state that the best thing about OWL is that it’s based on a solid mathematical foundation unlike all OMG standards, which are criticised for lacking it. What do you think are the main strengths of OWL, and the main weaknesses?
Eddy: to me it is the mathematical foundation when this enables advanced inferencing. On the other side, I very much appreciate the profiles with the different syntactic subsets. There is no clear-cut solution and OWL has to be tailored. This strength is also its weakness, together with the fact we cannot reason with classes (for the moment?).
Ivo: Thank you, Eddy! May be there will be some more questions put here from others. Now, instead of a conclusion, and for those wondering why Web Ontology Language is abbreviated as OWL and not WOL, one familiar passage:
He [Owl] could spell his own name WOL, and he could spell Tuesday so that you knew it wasn’t Wednesday, but his spelling goes all to pieces over delicate words like measles and buttered toast.
A. A. Milne, Winnie the Pooh
The previous part focused on areas such as expressive power, readability and enterprise architecture. This one, written jointly with Roland Woldt, dwells on a few more aspects such as semi-structured processes, exceptions, loops and data handling. Some of them could be sorted well under the ‘expressive power’ heading but as stated in the previous post, the intention is just to put some structure to the ideas and experience shared, not to give a list of criteria. If in spite of that the sections are regarded as comparison criteria, then each should get some weighting based on the application objectives. Additionally the ‘points’ should be reduced by the ‘cost’ of the advantage. For example, more expressive power brings increased complexity.
But again, as this was not the intention, the content is not suitable for such usage.
A business process model is meant to show some structure and behaviour patterns that are known or at least expected with a good degree of certainty. For processes with high uncertainty, using a notation – no matter how good – would not be as useful as for well structured processes.
There are processes for which activities are known but not their sequence or number of performances. These types of processes are supported by BPMN via ad-hoc sub-process. No similar construct is offered by EPCs.
Business process notations are used in some way even for managing unpredictable processes. Interestingly, Adaptive Case Management systems such ISIS Papyrus, support both EPC and BPMN which is yet another example that each one has strengths in different application areas.
Exceptions, transactions and compensations
Both EPC and BPMN can support exceptions. However, there is no way to show that something happens during the activity execution in an EPC. Conversely, BPMN is rich in constructs that support exceptions. Those include the boundary events in combination with catch/throw semantics. Situations where an exception could happen everywhere within a process fragment are also well supported by putting the fragment in a sub-process with an exception boundary event. Additional benefits are provided by event sub-processes.
Exception handling is really important. Some claim that this is so only from IT perspective, but I doubt that. However, it is true that some modelling limitations tend to support wishful thinking and many processes are suffering of the ‘happy path syndrome‘. Now, the mere existence of so many exception handling constructs in BPMN might – well, at first frighten but then – prompt some more realistic business representations.
If we are completely fair with EPC, we should admit that there some activity interruption is supported. But this will mean to depart the pure notation discourse. There is an attribute ‘interruptible’ which, when set to “true”, will allow activity execution to be interrupted based on specific resource assignment. This capability is supported by ARIS Business Simulator. A token arriving at an activity will trigger it but when this activity is interrupted (attribute ‘interruptible’=true), it will wait until the activity performance is resumed. The reason for such interruption could be that the resource carrying out the activity has stopped working because of a break.
However, in addition to “interrupting” events BPMN supports “non-interrupting” events that trigger an exception while the process continues – you can show this in EPC with rules (“and” rule) and events, but the solution in BPMN is more elegant.
Transactions and compensations are supported by BPMN and not at all by EPC.
Loops -either standard, parallel or sequential- are a powerful construct in the BPMN notation. They allow to show that a process can run multiple times without the need to draw confusing lines in a model or to repeat process fragments over and over again. In combination with using events or attributes that hold the number of repetitions this is a clean and easily understandable way to model.
Loops can also be shown in EPC notation, even though there are no special markers in the functions that shall be repeated. A modeller has to work with multiple events that are coordinated by rule objects (e.g. “and”) to describe the conditions when a loop or repeating activity has ended. This is not impossible but a less elegant solution when the process becomes more complex.
Additionally, BPMN provides 11 standard attributes for handling loop behaviour. When such formalization is needed, things like loop cardinality, data-based conditions and how multi-instances a produced by the activity can be specified.
BPMN assumes that all data is freely available within a process and can be used in the tasks whenever needed. In addition to this data highlights can be shown by either using the data object or the data store for persistent data (even though persistence means “only for this process instance”). The notation is not meant to allow data modelling and the breakdown of data information in specific data models > see chapter 7 of the specification.
In opposite to this the EPC notation allows multiple ways to show data in a process: either as abstract clusters or technical terms, that describe an information, or depicted as information carriers, such as documents, CDs, etc. And even as fine as showing relations to classes and attributes. The biggest advantage of using an abstract data object lies in the capability of the ARIS overall method -not only the EPC notation- to decompose a cluster into entities and then into its attributes. These can then be mapped to tables or even synchronized with other dedicated data modelling tools like ERWIN (via a 3rd party interface). Strangely, EPC allows better integration between process models and UML Class Diagrams than BPMN do, while both UML and BPMN are maintained by OMG.
Process notation for ERP Systems
As mentioned earlier the EPC notation became very popular when the ERP wave took off and companies had the need to figure out and model their processes. The most popular example here is SAP and until today all SAP ARIS customers use this notation to synchronize three levels of process models directly with SAP’s Solution Manager. In addition to this, EPCs can be used to create test cases that get synchronized with HP’s Quality Center for testing (either through Solution Manager or directly via export from ARIS). There is no BPMN synchronization in place as of today.
To further accelerate the modelling efforts SAP provides two sources of process information that can be included into the blueprint models: The “Business Process Repository” (the transactions) and the “Enterprise Service Repository”. Both sources will be enhanced by non-SAP and manual steps in the blueprinting phase of the ERP implementation.
But SAP is not the only ERP system on the market – its largest competitor Oracle OEM’ed ARIS in its “BPA Suite” tool and in that, the EPC notation is also the standard notation. Opposite to the SAP synchronization, the EPCs will be transformed into BPEL models that then will be exported as BPEL and WSDL files that can – after running an Oracle-specific script that transforms the standard BPEL export file into an Oracle-specific format – then be imported into the Oracle ERP system.
Similar approaches to the BPEL export have been implemented in process modelling for Microsoft BizTalk and IBM’s WebSphere products.
An interesting way was presented by Software AG in the “Enterprise BPM” approach at CEBIT this year. Here it is also recommended to model the business processes in EPC notation, since it is easier to understand for business users and fits into an Enterprise Architecture without workarounds. After the business model is approved it can be transformed into a logical BPMN 2.0 model and then enhanced with technical information, for example to show a split of a business process step like “check inventory” in multiple service steps. After the logical BPMN model is ready it can be pushed into webMethods where the physical BPMN model then gets implemented.
The last use case shows an implementation of the original purpose of the BPMN notation. I expect similar approaches for creating a true business process architecture, while being able to execute the lower level models from other vendors too.
An interesting observation nowadays is the marketing hype around BPMN. To a new user, who is investigating which notation/which tool should be implemented the options and sometimes conflicting marketing information are confusing. On the one side you hear that EPC is a proprietary notation (which is not true) that is only supported by ARIS, on the other side, the EPC templates ship with a standard MS Visio installation for years now, while BPMN (in the old version 1.2) was just introduced to the latest version Visio 2010. In addition to this a quick Google search will show dozens of tools for either notation.
I think the best approach to choose the right tool is to ask yourself about the goals of a BPM/EA implementation. Do you “just” want to model simple processes, shall they be executed in a BPMS or used in an ERP implementation, or is the procurement of a tool just the start of a larger, enterprise-wide implementation with the goal of creating and measuring a performance-driven organization, while using enhanced capabilities such as simulation, process costing or process performance management. Both cases depend heavily on the maturity of the organization and luckily the established vendors provide import capabilities for existing information.
By Ivo Velitchkov and Roland Woldt