Speaking My Mind

We had such fun doing the SOA reference model (we have just had a successful vote to go to Committee Specification status) that I thought we might be able to repeat the exercise in a different domain. The primary benefit of the RM4SOA was that it establishes a common technology-neutral way of talking about Service Oriented Architecture. Precisely because we didn't take a stand on the technology meant that it was less useful to potential SOA vendors (who want to know what to implement) and more useful to everyone else (who want to know what all the fuss is about). I see a similar need and potential for Policy. Policies are becoming more and more visibly important; specifically declaratively stated policies. The reason is clear enough: who do you want to be setting the policy in your organization: you (or another relevant stakeholder) or the programmer who built the system that you are trying to use. Explicit, declaratively written policies are a key technique for putting decisio

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

The key premise of running a research lab is that it is a form of investment. There may be many motivations for investing in research, but some of the more common ones include The big payoff This is, in effect, a form of gambling. You put up a lot of money and hope that some of it will lead to a new ground-breaking profit that will allow you to clean up. Insurance You want to reduce your exposure to some long-term risk that might come out of left-field and blow you away. Fill the pipeline You need someone whose skills are developing new products, but not necessarily manufacturing products, to keep the pipeline full. All of these are legitimate, although the first 2 are for 'hi-rollers' only: research labs are inherently expensive and these uses are particularly unlikely to pay off. When and if they do pay off then the rewards can be immense (think of Xerox Parc). But, like the lottery, you could live and die without seeing the benefit; and think that your mone

IBM has some interesting thoughts and papers on Governance in the context of SOA. This is clearly an important topic: let's get it right this time is my feeling. (If you need an example of what can go wrong when these issues are not properly thought through just consider the email fiasco: SPAM is essentially a throw back to an era before there were stamps on envelopes and only the rich could afford to receive a letter.) However, IBM's stance appears to focus on what we (the OASIS SOA Reference Architecture committee) call the “Enterprise SOA”. In contrast to the situation where there is an easily definable corporate body that owns the SOA, the “Internet SOA” corresponds to the real Internet. In the Internet SOA there are no governing authorities to set up nice committees to decide what can and cannot be published. However, just because there is no Big Sibling does not mean that governance is not a critical issue for Internet-scale SOAs. We simply have to find another way. It

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