During these days of smaller and smaller budgets, way too many times, vendors, especially the smaller vendors, don't care about standards unless they directly affect sales today or next month. OK, maybe if they affect sales this year. But, here's the problem: Belonging to a standards committee is, many times, a defensive measure (to keep your product from being written out of the standards) or an overt attempt to directly influence the committee into accepting that YOUR standards as the only (or maybe just one of two) standard. A third, and unusually rare problem, is that the vendor is seen as doing one of the above when, all the time, their intentions are totally altruistic and in the interest of the industry as a whole - meaning that they are one of the "good guys".
And that is what we should be doing: Writing standards that help our industry to establish definitions so that we can have a common language so that when we talk with customers we can say that we adhere to standard XYZ and the customer know that when they say "blatherskater" it has the same meaning to both of us as well as any competitor that adheres to that standard.
But what if we adhere to our industry standards, what if we are concerned about our industry and we (all of us) are trying our best to be sure that we all agree on standards. Now, what if one of us should fail to adhere to one of those standards and produce a product that claims to adhere to that standard and the product does not adhere to that standard. What happens then? If there is no governing body to reinforce some kind of sanction, the standard is valueless. If the standards are not enforced by a governing body that can enforce some kind of economic sanction, or even a legal sanction, when there are violations of those accepted industry standards, then the standards have no value.
Back to the original question: Why should I care if they are not being enforced? Because we, all of us, have a duty and an obligation (especially the "Thought Leaders" such as FICO and IBM) to "do the right thing" even when no one is looking nor checking. The servant of the most value to the master is the one who does what is right and proper even when the master will never know nor find out. That is what is known as a "trusted servant." And we, the leaders of the industry, must do what is right and proper with respect to standards and ethics even when we know that we don't have to those things and that there is no retribution when we get caught doing the wrong thing. We, the "thought leaders" of our various industries, must be "Trusted Servants" of the industry.
All that being said, we MUST follow our own standards upon which we all will have agreed even when it means that we will take some kind of financial hit. The hardest thing of all is combating the argument, "But if we do this thing (that we know is wrong) it will cost us more money and if we don't do it no one will find out and even if they do find out, so WHAT? There's nothing that they can do about it." (Yes, I worked in sales for a year or so and heard all of that kind of thing.)
Hopefully, this won't be my last blog on this subject. Maybe next time I'll go after JSR-94 and what it means to have a standard that can be observed but means absolutely nothing to anyone whether you adhere to it or not. Maybe...
SDG
jco
3 comments:
JSR94 is a completely pointless and worthless standard. It could have been so much more, too bad the advice of others was ignored. I know the ruleml guys gave plenty of advice and I contributed a few comments. Yet none of them made it in the spec. JSR94 is a complete and total failure in my mind.
As the spec. lead for JSR-94 I think "failure" is somewhat misleading. There seems to be a general misunderstanding of the goals of JSR-94. Whether attaining those goals moved the industry forward at all is open for debate of course!
Here is a snippet from the JSR-94 proposal original (http://jcp.org/en/jsr/detail?id=94):
"2.1 Please describe the proposed Specification:
This specification defines a Java runtime api for rule engines.
The api prescribes a set of fundamental rule engine operations. The set of operations is based upon the assumption that most clients will need to be able to execute a basic multi-step rule engine cycle, which consists of parsing rules, adding objects to an engine, firing rules and getting resultant objects from the engine. The set of operations also supports variations of the basic cycle, particularly variations that would occur in J2EE server deployments.
A primary input to a rule engine is a collection of rules called a ruleset. The rules in a ruleset are expressed in a rule language. This specification defines generic api support for parsing rulesets, but does not define a rule language standard."
I.e. the JCP explicitly ruled out (no pun intended!) JSR-94 addressing language and runtime semantic issues. Trying to get the major contributors (IBM, BEA, Jess, ILOG, Blaze) to agree to even the simplistic runtime interfaces we ended up with major challenge in itself!
I've written several pieces on standards work. See these two for examples:
http://www.javarules.org/?p=98
http://www.javarules.org/?p=64
With RIF/SVBR et al perhaps another standards push is warranted? That said, there is still an awful lot of innovation going on and it is not clear whether a useful "lowest common denominator" exists yet.
In my mind, tackling the language issue was very touchy and difficult to get concensus. Without a standard rule language, portability is largely impossible.
I seem to remember ruleml commented on deployment API and runtime semantics. My bias feeling is both of those should have been addressed in a standard specification. I did listen in on some of the discussions silently and the job of reaching a concensus is a monumental task. I don't blame daniel for the short falls. It's just sad that political issues prevented JSR94 from achieving more.
Post a Comment