Speaking My Mind

When I was growing up, the overwhelming reaction I got from people from all walks of life was that change was something to be avoided. I found it frustrating because, to me, it seemed that there was so many exciting things that could be happening but noone was interested. That has changed today. Nowadays, it is accepted wisdom that you must innovate - or suffer the consequences. Providing services, providing products We can classify, roughly, a business into two primary styles - a service provider or a product provider. Be aware that the line between these can get pretty fuzzy. However, a key difference is in the nature of the relationship with the customer: a service provider 'takes control' of the relationship by offering to directly meet some requirements. A product provider is also focused on meeting requirements; but is more indirect: the product provider sells a tool to the customer that enables him or her to meet his or her requirements. There are other differences betwe

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

Today it was the turn of participants to get a hammering. A SOA is all about people; about people getting things done. What is more, people have all kinds of relationships to each other :-). What, you might ask, has that got to do with SOA? A lot in my opinion. Here is an example. Suppose that someone wants to set up a system that allows, among other things, groups, teams, and societies (such as the Society for the Preservation of Cats in the San Francisco neighborhood) to be formed and policed. There are many situations where that is already happening, just take a look at MySpace. Well, each society is going to want its own rules for governing itself. Of course, there is always an overarching set of rules that we abide by: the state and federal law; but federal law tries not to interfere too much in the way that the SPCSF is run. Our SOA that is supporting all these societies might allow people to execute actions via the SOA: such as declaring that someone is the president, a meeting

We are currently writing our first draft of the SOA Reference Architecture. Everyone is very busy doing their bit. My current section is on the Real World Effect of using a service. The RA is really an abstract architecture: we are not focusing on things like SOAP, or any of the other 60+ Web service specifications out there. We are trying to get at the essence of makes SOA special and how it can be made to work. It is a pretty basic aspect of services that we are trying to get something to happen: buy a book, get the weather forecast whatever. In other words: its action at a distance. I am communicating with you in the hope that we can get some mutual benefit. This already distinguishes SOA from the Web, whose basic abstraction is to acquire a representation of a resource will be rendered locally for human consumption. Actions are not inherently about representations, they are about changing the world - one book at a time. Action itself is a very difficult concept to get hold of. It

Recently I have been involved in collecting requirements for two separate activities; both standards activities though. One is the Service Oriented Architecture Reference Architecture and the other is the Rules Interchange Format WG . It is interesting how difficult it can be to get technical people to understand what is really meant by requirements; although my experience with the two groups has been very different. Being clear on requirements is, of course, critical in any venture. This is especially true for projects that are technically difficult. But the real trap, it seems to me, is where the participants already think that know how to solve the problem. For them, requirements capture is one of those necessary evils that the administration imposes but everyone will actually ignore. Well, necessary or not, I intend to nail people's feet to the floor where requirements are concerned! This is my first post on this blog. My intention is to cover those aspects of my work which h

My job is a research job, so a reasonable question is what is research in a corporate environment really for?. This is a two-part article; in this part I will concentrate on the problem. In the next part I will talk about the solution. So, what is the problem of research? If you ask an average person, even an average technical person, even someone who job is in research, what the role of research should be in an industrial context, my guess is that you will get an answer along the lines of the job of research labs is to invent cool products for the business units to sell Sometimes this is modified a bit: the role of research labs is to support business units in whatever they want I argue that this job description is both a poor mission for research labs and a poor use of the money spent. First of all, consider an arbitrary business unit. Presumably, if they are doing their job correctly, they will have a constant eye out for products that they think they need - based on customer reques