A Policy Reference Model

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 decision making power back in the hands of ordinary people; without requiring that they be alpha computer-geeks.

A Reference model for Policy would identify the key concepts around policies and policy frameworks (such as policy language, policy decision point, policy subject and so on). This should be expressed in a way that is neutral to specific technology proposals.

Like the RM4SOA, a carefully written RM4Policy would establish a common language for policies that could get a lot of traction in the industry.

BPM for machines or for people

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 BPM because it defines their responsibilities in a relatively unambiguous way. eBusiness process designers need it because ‘getting it right’ for business between partners is too expensive at the moment.

How to run a research lab

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 money was wasted.

I have already argued that the third option is not really suited to a central research lab. The leader of the Business unit that owns the product family should also lead the development of new products.

There is another option not often considered, but I think critical:

• Taking care of critical success factors

Addressing technologies, marketing, etc. that are critical to the success of the company; but not inherently directly linked to particular products.

The idea is that there are topics in any business that are ‘at the heart’ of the business but not necessarily contained within a given product.

A great example of a CSF for a software company is security. Security is clearly important: a security failure can destroy a business. Security affects many (all) products but is not easily confined to a single product or technology.

Addressing security is best done from an overall/overarching perspective. Incidentally, as ay security specialist will tell you, security technology is not limited to encryption but includes policy management, architectural considerations and many other factors.

Putting a team to work to ‘own’ security would be a sound strategy for many companies. That team would take responsibility for ensuring that the company had the best security strategy and execution possible. That team is best placed centrally: for example in a central Corporate research lab.

Another good example CSF for a software company would be usability. Usability is another one of those make-or-break aspects that can lead to riches or disaster. It is also something that applies to all the products and services offered by a company. And so, a usability team may also be a wise investment; again placed in the central lab.

The pattern is that these CSFs often denote important properties that one would like to be associated with all the products and services offered by a company. And this importance is inherently connected to the relationship between the company and its customers.

Viewed this way, it is easy to see how and why a company might invest in a research lab that focuses on critical factors; and for that investment to be sustainable in bad times as well as good.

Governance and SOA

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 is said that European law was based on a pre-existing body of ‘Merchant Law’. This was an era of very limited central government, city states and a surprising amount of international trade. Without a recognized legal framework, merchants were forced to settle disputes among themselves. Much like the Internet today.

Anyway, we are looking for the right architectural hooks on which to hang governance and related concepts.

What’s up at OMG

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 might cut themselves? In my opinion, there is a difference between having the sharp edge of the scissors on the outside or the inside of the blades. Some of the most basic features of BPMN (particularly the merges) are downright dangerous.

There is also an initiative to develop a UML profile oriented towards modeling SOA systems. Unfortunately I have not had time to look at it; but it should be a good idea.