<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
   <title>Business Rules Cafe</title>
   <link rel="alternate" type="text/html" href="http://www.businessrules-cafe.com/" />
   <link rel="self" type="application/atom+xml" href="http://www.businessrules-cafe.com/atom.xml" />
   <id>tag:www.businessrules-cafe.com,2009://1</id>
   <updated>2009-10-28T22:00:36Z</updated>
   <subtitle>Serving up casual and technical discussions about the business rules community, technologies and methodologies</subtitle>
   <generator uri="http://www.sixapart.com/movabletype/">Movable Type Pro 4.21-en</generator>


<entry>
   <title>Only Special People Need Apply</title>
   <link rel="alternate" type="text/html" href="http://www.businessrules-cafe.com/2009/10/only-special-people-need-apply.html" />
   <id>tag:www.businessrules-cafe.com,2009://1.14</id>
   
   <published>2009-10-28T02:00:16Z</published>
   <updated>2009-10-28T22:00:36Z</updated>
   
   <summary>members (of a business rules) team must have a dual grasp of technology and business acumen, in one brain</summary>
   <author>
      <name>Rick Schwartz</name>
      <uri>http://www.ressysinc.com/</uri>
   </author>
   
      <category term="Business" scheme="http://www.sixapart.com/ns/types#category" />
   
      <category term="General" scheme="http://www.sixapart.com/ns/types#category" />
   
      <category term="Implementation" scheme="http://www.sixapart.com/ns/types#category" />
   
   <category term="3" label="Business Rules" scheme="http://www.sixapart.com/ns/types#tag" />
   
   <content type="html" xml:lang="en" xml:base="http://www.businessrules-cafe.com/">
      <![CDATA[This is my first blog entry on <a href="http://www.businessrules-cafe.com">businessrules-café.com</a> and so I'd like to start out with a brief introduction of my philosophy as it relates to the business of implementing business rules.  

I have been implementing business rule systems for about ten years and in general have been working in enterprise environments for well over twenty years. I consider my self a technologist, but more than that a pragmatist. By that I mean I have seen my share of IT failures and (jaded by these experiences) I've grown weary of the mumbo jumbo that is touted in so many "industry experts". Rather, I've ended up with the saying "git'er done" ringing through my temples. Not that I think expediency is a best practice mind you, however I've seen enough mega-projects get bogged down in debates about architecture. In the end, the projects that fly low, under the radar, with a small agile team, is more likely to be successful than a monolithic undertaking with MS Project Gantt charts coming out the yin yang.  
]]>
      
My experience with business rules is that the ratio of failures to success is not that different from other endeavors, but seems to favor of success when the approach is agile in nature.  So this brings me to my first item regarding agility and success factors: the members of the team must have a grasp of technology and business acumen,... in one brain. Now I&apos;m going to get somewhat controversial; this skill is not something that can be outsourced.  By that I mean, the traditional approach of writing a spec and throwing it over the cubicle/wall/ocean does not work well when we need people to embody both IT and business acumen. To do that you need proximity, communication, face time, trust, understanding, ...the list goes on. 

 I can hear the howls already, but if we are talking about automating the aspects of a business that makes it unique, it&apos;s not enough to break the problem down into the duality of business and IT, rather the endeavor is the integration of the two. In my experience, the only way to do this in a light and agile way is to have people on the team that can embody both the ways of the business with the means of the technology. 

Business Rules, perhaps more than any other enabling technology demands, even requires, synergy between what continues to be two departments, budgets, chains of command. The old ways have to fall to the new, and for business rule endeavors to be successful, you need a unique human being. In fact if you manage to get more than one, say a handful, your chances of a successful implementation of Business Rules just went way up. 

   </content>
</entry>

<entry>
   <title>CEP and Business Rules</title>
   <link rel="alternate" type="text/html" href="http://www.businessrules-cafe.com/2007/12/cep-and-business-rules.html" />
   <id>tag:www.businessrules-cafe.com,2007://1.8</id>
   
   <published>2007-12-31T21:33:29Z</published>
   <updated>2008-07-07T18:25:11Z</updated>
   
   <summary>IBM is currently exploring the CEP space with their Active Correlation Technology (ACT) initiative. IBM&apos;s CEP ACT is IBM&apos;s answer to handling CEP (complex events processing) - a little bit different than traditional &quot;event rules&quot; because CEP is designed to...</summary>
   <author>
      <name>Chris Collard</name>
      <uri>www.dell.com</uri>
   </author>
   
   
   <content type="html" xml:lang="en" xml:base="http://www.businessrules-cafe.com/">
      <![CDATA[IBM is currently exploring the CEP space with their Active Correlation Technology (ACT) initiative.

<a href="http://www-128.ibm.com/developerworks/autonomic/library/ac-acact/">IBM's CEP</a>

ACT is IBM's answer to handling CEP (complex events processing) - a little bit different than traditional "event rules" because CEP is designed to handle high capacity events and situational modeling - not just "returning an answer". CEP has been around for a little while, but just not formally called "CEP" - basically anywhere where high numbers of events occur simultaneously and situational content is derived e.g. In today's fighter planes – the onboard CPU takes in simultaneous flight data, targets, physical data, strategic data, etc. and processes it all into suggestions and actions for manual and automatic compensations.  The distinction can be made: business rules and event rules are designed to simulate the decisions of one simultaneous person (make a loan decision, determine eligibility, etc) - CEP is designed to simulate the decisions of many simultaneous people (all of these events just occurred - what situation does that present, what decision(s) should be made, etc?) 

David Luckham has developed a site dedicated to <a href="http://www.complexevents.com">CEP</a>. I am interested to watch as the paths of <a href="http://www.edmblog.com">EDM</a> and CEP continue to move towards each other. To my knowledge there are no COTS packages associated with either CEP or EDM to date...
]]>
      
   </content>
</entry>

<entry>
   <title>Reusability Across Rule Projects</title>
   <link rel="alternate" type="text/html" href="http://www.businessrules-cafe.com/2007/11/reusability-across-rule-projec.html" />
   <id>tag:www.businessrules-cafe.com,2007://1.7</id>
   
   <published>2007-11-26T22:25:47Z</published>
   <updated>2008-07-07T18:24:50Z</updated>
   
   <summary>at what point does reusability, extensibility and consistency play a part in enforcing a robust and fruitful rule application</summary>
   <author>
      <name>Jeremiah Connelly</name>
      <uri>http://www.businessrules-cafe.com/</uri>
   </author>
   
      <category term="General" scheme="http://www.sixapart.com/ns/types#category" />
   
      <category term="Implementation" scheme="http://www.sixapart.com/ns/types#category" />
   
      <category term="Technical" scheme="http://www.sixapart.com/ns/types#category" />
   
   
   <content type="html" xml:lang="en" xml:base="http://www.businessrules-cafe.com/">
      <![CDATA[As a business rule developer, I tend to notice that a good amount of business rules projects tend to be linear across the business.    What I mean by "linear", is that I tend to notice projects that share a good amount of similarity between one project and another, all within the same business application.   For example, Business_A has 5 separate rules projects, Project1, Project2, etc...   

That being said, at what point does reusability, <a href="http://en.wikipedia.org/wiki/Extensibility">extensibility</a> and <a href="http://en.wikipedia.org/wiki/Consistency_model">consistency</a> play a part in enforcing a robust and fruitful rule application, beyond the scope of the current requirements and utilization?     Does it come into play during architecture?  Implementation?   Or does it fall all the way back in the <a href="http://en.wikipedia.org/wiki/Iterative_and_incremental_development">Iterative</a> cycle to flush out the best place to implement a scalable project?]]>
      <![CDATA[Let's take a step back and look at each of the phases listed above and see where it should fit in.

<strong>Architecture Phase:</strong>
The design phase of rule development usually includes a large amount of rule analysis, but rarely includes a deeper scope of all rule projects that will be built and used within the business.    Without this deeper understanding of the future implementations is it possible to know how extensible to make each individual rule project?   I believe within reason it is, but only by making the project as "generic", as possible without sacrificing core functionality.

<strong>Implementation Phase:</strong>
Again, as with the Architecture phase, Implementation is usually done on a project to project basis.   As work continues on one project, another projects scope may be introduced or need to be modified.   As this is usually the case, there is the ability to enhance the previous project(s) with knowledge gained during implementation of the secondary (or other) projects.    Opening up the ability to pull in similarities between projects or alternate execution points into the rule project.     

<strong>Iterative Phase:</strong>
In my opinion and experience, this seems to be the most optimal, although sometimes not the most time conscious, location to perform a thorough reusability assessment of all projects.    This is most likely being said with the knowledge that everyone knows this to the be the best location and time to perform this.   However, it should be strongly noted that it is at times, a very time consuming process to navigate through multiple rules projects simultaneously and put together a strong reusable set(s) of project code and/or implementation, that is effectively reusable between the multiple project while maintaining strong rule code design and business functionality.

<strong>Overview:</strong>
It should be noted that most of the time, there simply is not the resources nor time available to perform these necessary updates to a project.    I have stated the word, necessary, due to the fact that this is, at times, one of the most often overlooked aspect of a rules project.     In my opinion reusability and extensibility should be a cornerstone of a single site multiple rule project implementation.   

Reusability and Extensibility within rules projects, allow for (among other things):
1.  Faster development through code reuse or reference
2.  Ease of code interpretation
3.  Faster knowledge transfer between new and existing team members
4.  Robust reusable implementations
5.  Cleaner future code maintenance
6.  Easier code and deployment manageability]]>
   </content>
</entry>

<entry>
   <title>Welcome to the Business Rules Cafe</title>
   <link rel="alternate" type="text/html" href="http://www.businessrules-cafe.com/2007/10/welcome-to-the-business-rules.html" />
   <id>tag:www.businessrules-cafe.com,2007://1.6</id>
   
   <published>2007-10-18T20:02:38Z</published>
   <updated>2007-12-19T20:31:26Z</updated>
   
   <summary>The Business Rules Cafe is a blog about technical, business and casual discussions that center around the Business Rules community, tools and methodologies.</summary>
   <author>
      <name>Jeremiah Connelly</name>
      <uri>http://www.businessrules-cafe.com/</uri>
   </author>
   
      <category term="General" scheme="http://www.sixapart.com/ns/types#category" />
   
   
   <content type="html" xml:lang="en" xml:base="http://www.businessrules-cafe.com/">
      The Business Rules Cafe is a blog about technical, business and casual discussions that center around the Business Rules community, tools and methodologies.

The authors of the Cafe are daily busines and technical users of various enterprise rule engines.   We invite you to comment on the posts and contribute to the growing user base of the business rules community.    If you would like to contribute to the Business-Rules Cafe, feel free to send an email to us at anytime.
      
   </content>
</entry>

</feed>
