Monday, July 03, 2006

What does a team member on a rules project need to know?

As part of a new client engagement, I will have to bring my current team mates up to speed on business rules, engine use, the business rules approach, fact modeling, rule writing and analysis.


Short of enrolling the entire team in Artemis Alliance's business rules analysis, and rule engine technology training classes, I decided to turn to some free resources for now…

So…what does an analyst, architect or programmer absolutely HAVE to know about rules before embarking on a brand spankin’ new rules project?
Below, I have compiles a list of both mandatory and helpful readings that I intend to give my team:

Overview and General Resources:

Business Rules on Squidoo

Business Rules Community (free registration)

Artemis Alliance Blog Spot - Down to Earth Business Rules


Business Rules vs. Business Requirements - by Gladys Lam

Term-Fact Modeling - by Oscar Chappel

Business Vocabularies - by Dave McComb


Formal Theory:

Defining Business Rules - by The Business Rules Group


Rule Authoring & Organization:

The Role of a Rule Analyst (Part I) & (Part II) - by Kristen Seer

Launching a Corporate Glossary - by Bonnie K. O'Niel

Business Grammar Rules (Part I) , (Part II) & (Part III) - by Terri Moriarty

Business Rules Validation - by Steve Hoberman

For IT:

Pitfalls and Lessons Learned of Business Rules Implementation - A Technical Perspective

Decision Tables & Decision Trees

2 Comments:

At 7/04/2006 7:55 AM, Blogger Gene Weng said...

Krzysztof,

This is a great reading list. Thanks for putting Squidoo rule lens into it. I also like Oscar Chappel's "Term-Fact Modeling". It fills the gap between high level concept and technical reality.

Gene

 
At 12/11/2006 2:08 AM, Blogger paul browne said...

Thanks for the resources.

I've heard one story about a company here in Ireland that got the answer to the 'what does a team member need to know' question wrong.

They completely deskilled the rule-writing role - great for getting people started, but they had no idea idea of the bigger picture. They ended up with fairly high staff turnover as people viewed it as a 'copy and paste' junior role.

Paul , Technology in Plain English

 

Post a Comment

<< Home