Context sensitive Rule Management – Part 2

In my March 28th blog, I discussed process centric thinking and mapping business rules to process. As I stated earlier, business is a set of processes/services that it provides to its consumers. Business rules define how each process functions and how processes taken together allow a business to function. Let’s take an example of e-Commerce web site which takes orders from customers and fulfills customer’s orders. In this case, one process for this organization is, “Order fulfillment”. At the highest level it can be defined as
Gather customer information
Gather items that customer ordered
Take method of payment
Place a block or authorization on payment
Check the stock to fulfill the items that customer ordered
Place them in one or more boxes
Ship them to customer
Upon customer receipt, charge him.

Each step may itself explode into complex multiple sub steps or processes. So depending on organization size and number of processes; interactions between them may be very complex to define. When enterprise wide initiatives are made, even at the process level, people quickly get confused in communications primarily because they lack a common enterprise-wide vocabulary. The solution is to get control over what business can be defining by:

1) Creating common enterprise wide vocabulary thru which every one can communicate. (No interpreted meanings. Clear definitions)
2) Creating processes by using the vocabulary defined above to the granularity desired
3) Creating teams to define a process or sub process with an understanding of its functionality in end to end process definition.
4) Defining Requirements using common vocabulary (Enterprise repository) and creating any additional vocabulary before using it in Requirements

Strictly following the above rules automatically applies the concepts of “Contract first”, “SOA”, “Integration from day 1”, and handful unambiguous documents.

Context sensitive Rule Management

In my 15 years of IT experience, I have visited quite a few companies. Every company attempted, to some degree, to document business process in the form of rules. At the beginning, everyone is over enthusiastic and starts writing every detail as a business rule. At this stage, when a new rule is added, majority of BA's will not look into whether new rule would contradict with existing rules. This is starting point for contradictory / conflicting rules documents. Worst of all, at the corporate level, these initiatives happen in parallel and each department starts documenting rules whenever something comes to mind. IT builds applications based on a set of business rules which develop themselves into a concrete process with an input and output. An individual business rule is always a statement or a fact in the process, but can never be a process by itself. IT builds an application for a set of business rules which are cohesive in nature and accomplish a goal. This means that BAs should start from business PROCESS, not from RULES. After all, a business is a set of well defined processes/services to its consumers. Addressing rules from a process-centric viewpoint gives rules a context. Then BAs can ask themselves questions such as “How many processes are defined?”, “What portion of a process is defined?” Definition of a process can be expressed in business rules. Process-centric thinking while defining business rules has lots of advantages. It brings lots of new perspectives into the picture. In my next blog, I will take an example and explain how this process-centric thinking helps bring context to business rules. I will also explain the benefits BAs would gain by adopting this process-centric thinking.

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

General Reading:
What is the business rules approach? - by Barbara von Halle

The Business Rules Manifesto - by Business Rules Group

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

What are the characteristics of rulesets?

Managing Business Rules

So…maybe this post will sound like a rant, but why aren’t there any fully mature business rule management systems (BRMS) to be found anywhere?! I can’t even count the number of times clients ask me to recommend a system and I have to give them the bad news.

Naturally, each rule engine vendor will tell you that you can perform full rule lifecycle management within their authoring/development environment. Very quickly however you will discover that although it might be possible, the solution is generally about 80% skewed towards the vendor’s rule engine and the management aspects always take second place. Simply not good enough for business users!

Our clients’, you, more and more require a truly focused approach for large scale rule management. While managing and versioning Word/Excel documents in a code repository and providing change management via a defect/issue tracking system sometimes works, I think rules have become such a significant part of a system these days, that they really do need their own management environments. Similarly requirements systems, while a frequently used approach, still don’t provide adequate support for ensuring that rules conform to the fact model and that proper rule syntax/patter is being followed. Better for business users, but still not great.

There seem, however, to be some promising efforts under way! I am sure anyone who has actually spent some time looking has come across RuleArts' RuleExpress, and BRSolution’s RuleTrack. These two I believe have been around the longest.

Next, as a result of the new SBVR specification, Unisys is working on a business rule manage ment system that closely integrates with MS Word. You’ll have to dig deep on their site to find it however. Just give them a call-- they will happily show it to you.

Quite understandably the IRS has a massive rule management need and will share their experiences with BRMS systems at their BR Forum Conference presentation coming up in November in D.C. Bummer, the presentation is scheduled for the same day and time slot when I’ll be presenting Open Source Rules just next door.

So, I guess the question is…what is a “good enough” business rules management system? Artemis Alliance can certainly help you and your organization answer that question more precisely, but, as a brief blog entry, I have compiled the flowing preliminary wish list of features in no particular order. Please feel free to add in the comments section:

• Overall change and history tracking at the rule level
• Enforcement of the rule management process
• Role based security
• Rule authoring, storage, search and retrieval
• Terms Dictionary
• Fact modeling capabilities
• Rule language and pattern definition
• Natural language rule writing (yes…no…maybe?)
• Enforcement of fact model within the rule expression
• Rule syntax, grammar and spell checking
• Linking or matching of fact models from different departments/divisions
• Capability to document rules as decision tables/trees
• Easy access to rules by business people
• Ability to support both distributed and centralized rule management approach
• Import/Export capabilities of rules using available standards

This I believe represents a list of maybe the “obvious”. Note however, that at this time, I doubt you will fine any one solution that will offer all of the above features and be usable by your average business user. I naturally welcome any disagreements with this list and hope to hear from those who would wish for something different. Again, your exact needs will heavily depend on your organization, application and approach.

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

Senior Artemis Alliance staff, drawing on their practical experience with what can go wrong from management, technical, and business analysis perspectives, provided insight into how and why business rules initiatives fail and strategies to assure the success of such initiatives.

by Alyce Neperud, Artemis Principal and Senior Business Analyst

Significant analysis pitfalls include:

• Resistance to change
• Separation of rules from requirements
• Poor repository planning
• Selecting the wrong people to be rules analysts
• Solving the same problem in different ways
• No champion

Success Strategies
To overcome resistance to change:

• Educate to provide better understanding of why the organization is doing it this way.
• Build support within all areas.
• Development
• Analysis
• Testing
• Project Management
• Enable them to “skin their knees”.
• Let the team make mistakes quickly and see the value of the approach.
• Bring understanding of the “big picture” and the value of the approach down-stream in the development process.

To prevent the separation of rules from requirements:

• Teach them to write good requirements and good rules.
• Avoid having one group writing requirements and another writing rules.
• Use concrete examples.
• Show the new version of artifacts after introducing the concrete examples.
• Tell the entire story in an integrated manner.
• Use short, fast iterations with experienced review to provide experience and feedback

To encourage good repository planning:

• Do not take a document centric approach--focus on writing good rules rather than on where they fit in the document.
• Use knowledgeable people in designing the rules repository.
• Work through the versioning and change management in detail.
• Execute full rule lifecycle testing of the repository.

To select the right rules analysts:

• Do not assume that every subject matter expert will be a good analyst.
• Do not assign critical tasks to people who are unproven.
• Have internal or external mentors who have time to help
• Pair experienced people with inexperienced.
• Explicitly determine skill levels of team members.

To avoid different solutions to the same problem:

• Establish model for sharing information and lessons learned.
• Consistency is essential to precision.
• Do not let separate groups make their own decisions.
• Have some experts looking across the entire set.
• Do not overwork your experts.
• Be careful in how you tasks are assigned to avoid overlapping work.

Alyce’s advice for the ‘no champion’ problem ia simple: Get one! No champion equates to a greatly reduced probability of success.

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

Senior Artemis Alliance staff, drawing on their practical experience with what can go wrong from management, technical, and business analysis perspectives, provided insight into how and why business rules initiatives fail and strategies to assure the success of such initiatives.

by Krzysztof Karski, Artemis Senior Consultant

Significant technical pitfalls include failing to:

• Architect the concept model at the beginning of the project.
• Manage change.
• Establish an overall design vision for the rules engine and repository at the beginning.
• Establish appropriate testing methodology.
• Understand the capabilities and limitations of the rules engine.
• Understand that rules are not ‘just’ code or a new way to write if…then statements.

Success Strategies
For the concept model:

• Reduce change by having a well thought out and architected concept model.
• Have enough of a concept model architected so that future changes are additive, not structural.

For managing change:

• Establish a communication process between teams that might affect the concept model.
• Ensure the external entity model and the concept model evolve in the same direction.
• Agree early on data types, data constraints etc.
• Preferred approach: Iterative.
• Iterate quickly and often.
• Communicate frequently
• Integrate differences quickly and often
• Alternate strategy: Delay concept and entity model integration.
• Isolate concept model from external entity model churn.
• Figure out rules and concept model first, then figure out how to integrate with the external entity model.
• Get the concept model correct first and then figure out how to integrate it with external models.

For establishing an overall design for the rules engine:

• Choose an organizational paradigm and follow through.
• Establish rule organization, naming and categorization standards.
• Establish a vision for evolving the repository.
• Architect for rule portability and compatibility across the repository by having a well thought out and architected concept model.

For testing:

• Test early and often.
• Do not skip rule authoring steps including testing inside the rule authoring tool.
• Test in your environment first, not in application.
• Conduct quick, targeted testing.
• At minimum, set up quick and targeted smoke tests for your rules.
• Establish a reusable base of testing plumbing and base test data.
• Catch 80% of mistakes in the tool.
• Let the application testing strategy catch the remaining 20%.

For best use of the rules engine:

• Understand configuration options and their differences.
• Use wizards and auto generation techniques where possible.
• Use full tool set.
• Use the appropriate data types, built-in functions, etc.
• Understand your vendor’s work flow:
• Take full advantage of productivity aids by following the vendor’s rule authoring workflow.
• Understand the order of events when writing rules to avoid rework or unnecessary manual work.
• Use the rules engine for rules.
• Rule engines are not integration, data transformation or translation platforms.
• You should not have to write a ton of rules just to access, understand and return data.

For understanding why rules are not ‘just’ code:

• Use intermediary concepts.
• Define intermediary concepts globally and reuse them.
• Define simplification concepts that are used in everyday conversation and use them in the rules.
• Revisit OO analysis fundamentals and apply them.
• Write rules that sound like English.
• Follow rule writing best practices.
• Have each rule deal with one issue.
• Break up large decision logic blocks into many rules.
• Don’t write techie rules.
• Remember that rules are just not a different way to express if….then expressions.

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

Senior Artemis Alliance staff, drawing on their practical experience with what can go wrong from management, technical, and business analysis perspectives, provided insight into how and why business rules initiatives fail and strategies to assure the success of such initiatives.

by Michael Krouze, Artemis CTO

Significant management pitfalls include:

• Management sees the initiative as ‘only’ a technical investment or enabler, and fails to take into account ALL of the costs involved.
• Management views business rules as a tactical, single application investment, and does not see the ‘big picture’, strategic benefits.
  
• Management hasn’t bought into the value of business rules, and fails to provide consistent support.
• Management does not understand the scope of the initiative and short changes the investment.

Success Strategies
Regarding determining the costs:

• Clearly analyze all rule costs and communicate to management.
• Make sure to include the following types of costs:
• Purchases
• Culture/process change
• Education
• Implementation
• Testing
• Maintenance

Regarding the strategic benefits:

• Examine all the benefits of business rules.
• Think of business rules as a strategic tool.
• IT agility
• Management of knowledge as an asset
• Leverage the investment in tools and skills.

Regarding management support:

• Educate, review competition, review success statistics to build confidence.
• Communicate strong support.
• Don’t vacillate – make a decision and stand behind it.

Regarding not short changing the investment:

• Understand the costs.
• Recognize needs for education and/or consulting support.
• Allow for proof-of-concept work and learning curve.
• Contract for support services from vendor.

Based on Michael’s experience, shortchanging the investment and viewing a business rules initiative only as a short-term, tactical investment are the two biggest barriers to a successful project. Management must understand that a business rules initiative is strategic in nature and represents a new way to manage its business.

Decision Trees

This second and last article in this series discusses decision trees, what are they, when to use them and when not to use them.

Decision trees help systems reach a predictive decision that relies on navigating a path of historic knowledge to reach the end conclusion. An analyst or rules writer lays out the decision path with branching conditions leading to different outcomes. Decision tress during execution very closely resemble structured programming. The serially arranged branching statements can be compared to nesting if…then…else statements in traditional code.

In contrast to decision tables, decision trees have the advantage of being able to contain an inconsistent set of parameters without necessarily making the tree more complex. For example, each branching point does not need to concern the same parameters. Trees become more complex when each parameter potentially has a large number of different values. This is the inverse of decision tables. Each possible parameter value becomes a node at a branching point in the tree. Trees are generally complex and unruly to represent and even more so when the number of branches and levels grow.

We do NOT recommend using decision trees as an implementation for rules unless there are very good reasons to bypass inferencing and force the execution of one rule before another. We do not recommend decision trees for the following reasons:

• Decision trees are very brittle when rules change and require significant maintenance.
• Decision trees quickly become complex and difficult to manage.
• Rule engines utilize inferencing to determine the execution order of rules. Decision trees hardcode the execution order of rules which circumvents the entire inferencing capability of rule engines and make rule maintenance equate to the maintenance of hard coded and nested if…then…else statements.
• The entire decision making process is triggered by making a choice about one parameter (the root element). With inferencing, the rule engine can start anywhere and work its way towards the same answer from any angle as it executes rules.
• Ordering the execution of a small number of rules within a ruleset is better done through rule execution prioritization using weights rather than trees. Even so, this should rarely be necessary.

Trees can be made more user friendly and manageable by writing a high level rule flow around the execution of rule sets and decision tables.

We DO however recommend using decision trees during the rule analysis process for the following reasons:

• Decision trees will help analysts identify groupings of rules, which generally trigger together, which will assist with the identification of rule sets.
• Identical smaller branching structures at different places within a larger tree expose ruleset reuse opportunities within a ruleflow.
• Analysis using decision trees may expose business processes currently hidden within a larger chain of rules.

Decision Tables and Trees

Rules can be graphically represented in multiple ways for usability purposes. Two structures are primarily used: decision trees and decision tables. Rule engines do not really care about the rule representation since either structure is compiled into similar executable rule statements.

This is the first of two posts that will hopefully give some helpful tips about when to use and when not to use decision tables and/or trees.

Decision Tables
The decision table is a very familiar decisioning structure. Price lists, bus , and train schedules are often represented as a table and function very similarly to a decision table. For example, given your current location (input parameter 1) and where you want to go ( input parameter 2), the table will tell you when the train will arrive (your outcome). At a most basic level, two different parameters are represented along the axis of the table in columns and rows. The intersections of the two axes constitute the decision point for the given combination of parameter values.

A decision table simplifies the structuring and representation of repetitive rules where only the value of the same parameters differs in determining the outcome. Decision tables are also context free. Unlike decision trees, no prior path must be completed for the table to arrive at a decision. Only input values for the necessary parameters along the axes are required.

Here are some pointers when to use and when not to use decision tables:

• Decision tables are best used for a consistent, but limited, set of parameters , where, potentially , there are a large number of possible values for those parameters.
  
• A table with many different parameters quickly becomes complex which diminishes its usefulness as a simplification concept.
  
• Business analysts often use decision tables to represent a particular set of requirements, so replicating that structure in the rule engine reuses a familiar concept.
  
• Decision tables can quickly highlight where an outcome or decision is missing.
  
• Each decision table should only make one particular type of determination .
  

Also, not all parameters have valid decision outcomes in all cases. A decision table with a very sparse decision matrix may indicate that:

• The business may need to better define the rules that drive the matrix.
  
• The table may attempt to use too many parameters in one decision step and the table should be split into several decision tables connected by a rule flow.
  
• A table structure may not be the best structure to represent a particular set of rules and the rules should be converted into individual rule statements.

Here are some additional helpful links about decision tables:

• History of Decision Tables
• Decision Tables: Wikipedia

The Value of Assessments

Many organizations have considered assessments, formal and informal, of business rules technology when looking at reengineering efforts or at new enterprise development projects slated to involve business rule technology. The promised value of using business rules—often generated by one or more of the business rule vendors---is hard to ignore, especially for industries whose IT systems have ever changing and complex functional logic, or where the rules that run the business needs to be outside the control of the internal groups that implemented the old rules in a cryptic, traditional manor. The “leap of faith” many organizations currently take when they assume that detailed requirements are being translated into production code makes little sense for regulated industries or for any industry where the implementation of business rules is a business asset.

So, how can an organization move from this vague feeling that business rules can help them to a specific, thought-out strategy for the inclusion of business rules? An excellent first step is a business rule assessment. These short-term, focused efforts can be done with internal staff, or by using an outside consulting services provider.

During the assessment, a series of discovery meeting are scheduled during which thewhich the attendees answer questions grouped in various ways to help determine the organization’s readiness and aptitude for adopting business rules technology. There are usually separate meetings for technical management, development staff, business analysts, production deployment, and testing staff.

These assessments can have several outcomes. The organization should develop a final report, based on the information gathered at the discovery meetings, concerning the suitability of business rule technology for the organization. Another possible outcome is the definition of a proof-of-concept (POC) project. A POC is a detailed description of the requirements of such a project along with a project plan illustrating how the POC can be implemented within the structures and processes of the organization. A previous Down to Earth Business Rules blog entry discusses the merits of these POC projects. In other cases, the assessment will focus on helping make specific vendor choices for business rule development technology, again, based on specific information gathered during the discovery process.

After the assessment, an organization can be ready to step into a business rule project with a much-increased knowledge base as to how this technology will impact their firm specifically. I highly recommend firms just beginning to think about business rules take the time to conduct an assessment. If schedules and the staffing model permit, the assessment can be internally conducted. An internal assessment has the added benefit of allowing for even more learning about the organization and about business rules by the internal group conducting the assessment. This knowledge then stays within the organization. When time is short or the staff is not available, an alternative is to contract out the assessment to a firm with previous experience in these areas. Deciding whether to outsource an assessment is akin to a make-versus-buy analysis on the business rule applicability knowledge derived from the assessment.

Why do so few companies actually manage their business rules?

The products and services offered by today’s modern companies are increasingly virtual constructs modeled and defined through business rules and enforced by automated computer systems. Insurance policies, lending agreements and other financial products are often essentially contractual agreements between a provider and a consumer. These products and services amount to risk mitigation or behavior governance strategies to produce a financially beneficial outcome to the provider while offering something of value to the consumer. Such contractual agreements are really nothing other than a product or service modeled through the use of business rules and resulting actions, which combined, govern the relationship and responsibilities of both the provider and consumer.

Products and services that are defined through business rules force the creation of additional business rules that govern the company’s operations. Activities such as billing, fee and rewards calculation, verification of eligibility, and compliance require that a new, but related, set of business rules be put in place which both support and constrain daily operations to ensure that the terms of the agreement are met. In addition, most companies must comply with federal and state regulations, resulting in another set of business rules that must be enforced.

Through all of this, we can see how business rules lie at the foundation of modern business, from being the actual product or service itself, to governing the necessary supporting operations that make adhering to the agreement possible while also complying with regulations. Executing, enforcing and complying with ever more complex and numerous business rules is, increasingly, becoming the business.

Interestingly enough, very few companies actually document and actively manage their business rules as the intellectual property, legal commitment, or competitive advantage they are. A business rules management approach, at a minimum, provides us with knowledge about what the rules are, where they are, and what the overall impact of a business rule change will be. Business rule management is not necessarily the centrally controlled or bureaucratic process it appears to be. However, scattering business rules and their documentation across the enterprise in use cases, requirements management tools, manuals, and -- most often – in code, does not a business rules management approach make.

So, given the importance business rules play in the modern enterprise, why do so few companies actually manage their business rules?

Here are a few high-level business reasons that I could think of for this lack of management, in no particular order:

• Business rules have only recently become recognized as key company assets.
• Although rule engines have existed for over 20 years, business rule management tools and methodologies are still in their infancy.
• Only in the last 10-20 years has the business and regulatory landscape, products, and services become so complex that a rules management strategy is becoming essential.
• Since business rules change so often, old rules go away, and new ones are created, companies treat them as throwaways rather than as assets that need management.
• Companies are overwhelmed managing other aspects of their business that were positioned as critical much earlier than business rules (i.e., BPM, CRM, ERP, Just in time XYZ etc.).
• Companies have seen so many past promises about management approaches and technology evaporate that they are reluctant to adopt new trends until they have been proven by others.
• Managers are not around long enough to see value or implement long term strategies.
• Companies generally do not take an overall view of their business which means efforts are departmentalized and large efforts uncoordinated.
• Companies do not realize the savings from retaining and maintaining their intellectual property such as the expertise embodied in their employees.
• IT shops are unfamiliar with rule engines so anything related to rules management is equally unfamiliar.
• There simply hasn’t been enough hype around business rules for most managers to notice.

Naturally, it is too simplistic to say companies do not manage their rules. Insurance companies have been forced for years to manage rules to some extent due to mandated state filings on changes and proposed coverage. Similarly, companies who regularly audit their business activities must be able to prove certain practices are in place and business conducted according to regulations.

In that case, why aren’t companies managing most of their rules the same way they manage some of their rules?

The Strategic and Tactical Reasons for Prototyping

We have found that organizations considering the application of a business rules solution to a specific business problem reap both strategic and tactical value from prototyping prior to embarking on a full-blown project.

Strategically, prototyping identifies risks and avenues for mitigation of those risks as well as providing the basis for informed decision-making. Management has the information to decide on the most cost and process effective approach to achieve business goals.

The risk management value comes from projecting tasks that allow the organization to identify potential problem areas in technology, process, resources, or skills. The risk management goals of most prototypes typically revolve around evaluating multiple approaches in order to select one to move forward with, validating certain assumptions, and learning enough to be able to, with reason effectiveness, plan out implementation details.

The decision-support value, while similar to the risk management value, often has somewhat different goals. Normally, prototyping for decision-support revolves around gathering enough information to make a business decision with regard to the use of the business rules engine. Decision points may include whether or not to use a rules engine, which engine to use, or how to approach or plan for the use of the business rules engine.

Fortunately, a single set of prototyping tasks often provides both strategic values.

Tactically, prototyping builds practical experience in staff, allows for testing of integration mechanisms and process changes, and can ‘prove’ that the selected business rules approach will add value.

Many organizations have never used or have no experience with a business rules engine. Prototyping provides a mechanism by which people can get their hands dirty and experience the details of how business rules engines work. This is important because real life is frequently quite different from the theoretical concepts esposed by salespeople. Additionally, prototyping gives the organization the means to effectively plan how to shorten its staff’s business rules learning curve.

The best way to integrate a business rules engine into an existing or new architecture is not always obvious. Prototyping allows the technical staff to test and evaluate integration alternatives including evaluating both in process and out of process approaches, data marshaling, and transport mechanisms. When, as is often the case, existing environment limits the viable options, prototyping can surface the costs associated with working with or around those constraints.

Technical integration isn't the only area that may require validation of approach. Oftentimes organizations need to evaluate how implementation of business rules may affect their software development processes and approaches. Prototyping allows the organization to test their preconceived approach to handling business rules in their processes by applying their proposed process to the implementation of business rules.

Finally, and possibly most importantly, prototyping provides a low-cost approach to validating that the proposed business rules approach brings business value to the specific project. Business rules is a relatively new technology in many industries with all of the concerns regarding the expense, resource cost, and change management that accompany any significant implementation. Prototyping allows management to "get their feet wet" with minimal risk.

Welcome

As CTO of Artemis Alliance, I want to personally welcome you to the Down to Earth Business Rules blog. If you are tired of academic, theoretical discussions on business rules and want down to earth conversations with people like you who deal with the day-to-day issues of doing real business rules work, then this is the blog for you!

The Down to Earth Business Rules blog is for both business and technology professionals faced with the challenges presented by adopting and realizing the value of a Business Rules approach. As anyone who has worked on a business rules project knows, the theory of business rules does not always match the reality. Artemis Alliance consultants will draw on their years of working in the business rules trenches to bring the issues out of the Ivory Tower and down to the earth where we all live.

Lively comments about all aspects of business rules are expected and encouraged. There are no restrictions other than the highest level of professionalism is required. The Down to Earth Business Rules blog is moderated by Artemis Alliance.

Again, Welcome. If you have topics you would like to see addressed, please contact me at mkrouze@artemisalliance.com.


Michael Krouze, Chief Technology Officer, Artemis Alliance, Inc.


Artemis Alliance, Inc (http://www.artemisalliance.com), in the trenches since 1993, is an information technology services firm specializing in Business Rules Management.