Speaking My Mind

One of the questions that comes up from time to time is how to define your services. This has come up for me in two independent fora: within the OASIS Service Oriented Architecture work and in the context of human provided services, for example at Genietown . In the work on the SOA Reference Model we decided that "services are the mechanism by which needs and capabilities are brought together"; i.e., its about needs and capabilities to satisfy those needs, and the access mechanism. However, this still begs the question somewhat. In the domain of human services, where the services are things like "building a home", "walking the dog", "taking care of my elderly parents"; it gets even fuzzier. Sometimes a service seems to organized around the person offering the service, for example, an architect, or a doctor. Sometimes the service is organized around a particular kind of product, such as doors or skylights. At other times, the service is organize...

Today, in our telcon we invented something. It is not often that we can claim that; but today we did. There are, it sometimes seems, people who think that everything is an event. There are others (including a lot of philosophers) who think everything is an action. (Well, everything that people are involved with anyway.) Well, they are wrong. In human communication, the only way of getting someone to understand something you want them to is by saying something to them: by performing one or more speech actions. In the SOA we interpret this by committing to a view that participants in a service interaction denote the actions to be performed by exchanging messages. I.e., an appropriately formatted message that is effectively communicated between participants counts as an effort to perform an action. But, not all messages encode actions. Some encode events. For us, an event can be defined as something that happened that someone has an interest in. We can encode a description of an event as ...

I have had reason to look at the job boards recently. I am struck by something: nearly all the jobs in the IT industry have a sameness to them: there is some list of acronyms that you are supposed to have had x years of experience with (sometimes x is longer than the technology has been available) and apply those acronyms to the job at hand. There is very little room, it seems to me, for someone who has a deeper experience but who does not fit into the cookie mould. There are several unfortunate consequences of this (apart from the obvious one): any business that seeks to differentiate themselves from the competition cannot do so effectively if they slavishly follow the deeply rutted road trod by those before them; and some of the hardest problems in the Industry have nothing to do with applying the latest technology to yesterday's problems. One thing that I have learned in life (here he puts on his tri-cornered hat) is that there is always someone who will be faster than you, and ...

I do not believe that I am an elitist , but at the same time, I wonder about that phrase. To me, it implies an abdication of responsibility. Which is better: to give the customer what he asks for or to solve the real problem? Here is what I mean. Occasionally, someone asks me for some tool/gadget/software program that strikes me as not really addressing the problem. This can be for any number of reasons; the customer has an immediate pain point and wants to address the specific requirement, the customer is already fixated on the technology and want that solution, the customer has been told that the answer is SOAP (and what was the question?). As a professional, that puts me in a dilemma: either I end up arguing with the customer or I hold my nose and give him what he so plainly wants even if I think that it is not the right answer. Given my temperament, it means that I usually end up contradicting the client and thereby losing the deal. Today I ended up doing that (I think, it may be ...

Someone recently asked me why I was working on the particular topics that I was interested in. I am afraid that in the heat of the moment I had a reasonable but ultimately lame answer (something about reducing friction in the marketplace). In fact, the true answer is simpler and much more powerful. I want to be part of a 'professional' industry, and I believe that we are not really there yet. It is a constant source of amazement to me that there have not been any class action lawsuits against certain high profile software companies. I like the phrase safe and effective , which describes the basic requirements for medicines of course, but should be equally applicable to software. What would the benefits of being able to label a system safe and effective? Primarily it means that someone using the system has some assurance that the software will do what it is supposed to do, and that it wont lead you into trouble. Of course, if you take too many aspirin, or if you misuse a softwar...

I have to say that from a Computer Science perspective, I agree with Tom Baeyens , BPMN seems to reverse many of the lessons that we have learned (we have the lumps on the head to prove it). However, I think that this misses the point of BPM. According to Adobe, some 85% of business processes are executed by people. I think that this figure is not likely to change anytime soon. In effect, this is saying that BPM is a natural descendant of Workflow; except in the modern era where Web services are expected to be plentiful and processes span ownership boundaries. When it is primarily people that are expected to execute a process, they are significantly less tolerant of constraints such as “don't do that, it is too hard to get right”. BPM lives right on the boundary between IT and business. That means that neither 'side' gets to dominate the issues and vocabulary. Business Process designers need BPM because they have to get their multitude of processes right. IT architects need...

Busy week at OMG as usual. The BPDM team presented the latest news on the status of the BPDM; and it seems to have come a long way in a few months. There is something of a fracas about the relationship between BPMN and BPDM: is BPMN 'only' a notation or does it have some semantics. This whole thing was news to the BPMN team as they (including me) were blithely assuming that we were trying to define a language. For us, the major issues seem to revolve around the execution semantics of a BPMN diagram; for others, it is only a diagram notation and we needn't worry our little heads about execution. One might guess where that went! The BPMN effort does seem to be a bit stuck right now. Personally, I think that the issue is that we are trying to have it both ways: have an easily understood execution semantics and allow the business modeler to do whatever and however he/she likes. The image is one of sharp scissors: do we give the modeler sharp scissors in the knowledge that they ...

I am having a little trouble figuring out the details of graph rewriting semantics for BPMN. The issue is merges (pesky things - should be banned). In communication, message receive is by far the hardest to get right. It seems that in BPM, merge has a similar role: get merges right and nothing else will be a problem. Anyway, in traditional graph rewriting, a new 'activity' is created by reading-off a new active copy from the original graph. This corresponds to beta substitution in functional languages. The trouble is that, compared to expressions, BPM graphs are decidedly not well formed: there are loops and all sorts without being specially marked. Well, the issue is, when you copy off a new activity, how do you ensure that the existing activities are properly linked in to the new one. You can see this in the sequence above. (1) is the start point, and the problem shows up by (4). The (inclusive) merge has lots of connections going in, but only some of these are relevant. You...

Recently I have been doing requirements in a few separate places. I got the notion into my head that there was no good notation for describing requirements, particularly non-functional requirements. UML has a diagram for use cases, but no diagram for requirements per se. So this is the legend of the notation I drew up: In the Critical Factors Analysis method, your identify three classes of requirements: the goals that you want to achieve, the critical factors and conditions that must be satisfied to achieve the goals and the measurable requirements on the solution that will meet the goal. This methodology is powerful primarily because it can act as a forcing function to ensure completeness of requirements. I have had difficulty in getting people to understand the difference between goals, CFAs and requirements. I have also had difficulty getting people to distinguish requirements from solutions! (Everyone has their favorite piece of technology that absolutely must be part of the final...

Recently I have been involved with the standardization of BPMN. I find BPMN fascinating because it lies on the precise boundary between the IT world and the business world. Boundaries tend to be uncomfortable places to be around and BPMN is no exception. My focus has been primarily on the semantics of BPMN. There have been many issues concerning the semantics of BPMN features. From a strictly programming language point of view BPMN seems to throw away most of the hard learned lessons of programming in the last 40 years: it is unstructured, full of gotos and no objects in sight. But that is to forget the true purpose of BPMN, it is not a programming language. It is not even a scripting language, it is a language to help humans to manage their own activities. Even when BPMN is supported by automation, it is still primarily humans doing the work. Anyway, the traditional approach to the semantics of languages like BPMN is Petri Nets . The merit of Petri nets is that they are quite simple ...