The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 94 mentions that JSR-94 has reached the Proposed Final Draft stage. Yes, it's oldish news by now, but I finally got around to reading it. Was pleased to see myself mentioned in the Acknowledgements section.
Proposed Final Draft 29 Oct, 2003
I've been doing a lot of writing lately, and I've also learned that many folks simply are not familiar with The Elements of Style by Strunk and White. Everyone seems to own a copy of The Elements of Java Style or The Elements of UML Style but are somehow blissfully unaware of the origins of these books.
If you write, you need a copy of Strunk and White sitting right next to your Websters Collegiate Dictionary.
The fact is, the vast majority of so-called book doctors are garbage. An exception would be Strunk and White's classic Elements of Style. It was originally written during WWI by William Strunk who was then a professor at Cornell, and it has since been updated by E.B.White, one of his former pupils. Strunk's strategy was to edit down the complexities of English grammar into those few basic elements which would help people to improve their writing skills. His central rule is simple:
So, my mother-in-law called me the other day, asking me to diagnose her Windows Millenium Edition machine that'd freeze after running for about 10 minutes. Now, I'm completely Windows ignorant, but I poked around anyhow. Basically, all I could come up with was "ayup, you're right, it freezes after ten minutes." I figured maybe I could upgrade to WinXP as a solution. Upon further thought, I decided that was just a bandage to a bloody head wound. After doing a cost/benefit analysis, considering the hours of my time over the lifetime of the in-law relationship, I simply decided to amputate and replace.
So, I knocked upon the door today with a bag of new hardware and said "congratulations, you're a Mac user now!" She's now been vaulted into the 21st century with a G4 iBook, Airport Extreme, Wifi route/WAP combination and a bundle of new software. It was easier than dying a slow death diagnosing Windows.
So, I'm finally back from the Business Rules Forum and have one thought about what I witnessed. One of the BoF sessions I attended was all about rule management, addressing concerns about rule authoring, permissions, analysis and deployment. 98% of the audience came from "the business side" of the enterprise. A repeated theme was that they don't trust their business people necessarily to write and deploy rules. They still want the IT staff involved to do rule analysis and the actual deployment. Some audience members raised concerns that folks on the business side don't know how to write business rules. This scares me. If you're on the business side of the enterprise, your job is to write the rules, whether they are implemented via IT resources or if they are merely policies in a manual or the way you deal with customers. Business rules are the way you do business, and IT is certainly not (or shouldn't be) the expert in that regard.
I'll admit that currently there are technical limitations to allowing business folks to write and deploy rules on IT infrastructure without the intervention of IT staff. But ultimately, IT should be transparent and the people who write the rules (ie, who run the business) on a daily basis should simply be able to do so. If a business person can't write business rules, perhaps he should be flipping burgers down at Krusty Burger.
Of course, I'm also fully aware that some/many business folks don't know how to write rules and only can keep their jobs because it takes IT quite a while to realized bogus rules in code, and by then, it's assumed that it's IT's fault the system doesn't work or make sense. A transparent business rule facilitating technology will make the business side of the enterprise more directly accountable for their decisions. Be careful what you wish for.
As noted previously, I'm attending the Business Rules Forum in Nashville (insert obligatory "yee-haw!" here). In addition to being in the hotel where the Country Music Awards are taking place tonight, the BRF has been a veritable motherlode of knowledge. This is the absolute first conference that has been beneficial to me. In my head (and soon in some LaTeX) I've been sketching out some future directons for drools including rule management, repositories, deployment and analysis.
I've learned that the rule engine is but a small portion of the entire space of "business rules". There's plenty of room to grow. Nothing quite like a swift kick in the ass to get excited about a project again.
So, I am attending the Business Rules Forum in Nashville this week (yee-haw!) and heard this quotable quote:
Agile methods don't produce agile enterprises because you're still writing code.
The context is, of course, that a business rule approach and technology can move a lot of your logic out of code entirely, allowing the enterprise itself to be agile. If you're using agile methods to write code, you're still locking business logic up in a form that's not easily mutable. Somewhat similar to doing agile brick laying instead of reconfigurable cubicle farms.
