Main

September 25, 2008

Principles are Coming

Principles are Coming

More judgment and knowledge needed

While the finance industry is moving toward more rules and exceptions, and rules-based regulation, financial accounting and reporting is moving in the opposite direction, towards fewer rules and exceptions. Accounting and tax is moving towards more principles-based regulation.

The US is moving away from GAAP (Generally Accepted Accounting Principles) and towards IFRS (International Financial Reporting Standards). IFRS is the reporting framework used by most of the world today, and it has growing support in the US. IFRS relies on professional judgment rather than detailed rules. Under this principle-based approach, management will have a mandate and obligation to exercise its own best judgment when making decisions.

Companies will need to implement systems that use knowledge and judgment to make principle-based decisions.

It is time to adopt knowledgebase technology and knowledge management. It's time to build knowledge bases and embed knowledgebased technology into operations and existing systems.

Knowledgebased systems that are engineered and architected properly can

  • follow principles and guidelines
  • automate management's best judgment
  • ensure compliance
  • and deliver trust. These expert systems can be trusted because they use expert judgment to make the same decisions top experts would make, thus improving the quality, accuracy, and consistency of decision-making.

I don't believe there is any other practical or proven way of automating human judgment, other than building intelligent, knowledge-based systems.

Knowledgebased systems are the solution for principle-based compliance.

Rules are Coming

Rules are Coming 

More rules and regulations are coming

To restore trust in the financial system, the government is moving towards more rules and exceptions, and more rules-based regulation. The trend towards de-regulation is over. Regulatory reform is coming back. That means more rules and regulations than ever before.
 
Management will have an obligation to follow the rules and laws when making decisions. These decisions better be consistent, correct, complete, and compliant if you really want to stay in business. 

Companies will need to implement systems that follow the rules and make rule-based decisions.

It's time to adopt the business rules approach and business rules management. It's time to build rulebases and embed rulebase technology into operations and existing systems.

Rulebased systems that are engineered and architected properly:

  • follow the rules
  • automate management's decisions
  • ensure compliance
  • and deliver trust. Rule engines can be trusted because they implement the decisions management intended.

Rulebased systems and business rules management are the solution for rule-based-compliance.

March 13, 2008

Introducing the BIZRULES® RuleMap™

Documenting business rules is a good first step on the path towards the business rules approach.

But sometimes that's not enough.  Taking the next step and getting to the next level requires simulating business rules so they are easy to review and verify.

Over the past few months BIZRULES has been working on a new product that lets us do both. It's a visual tool that lets us not only draw diagrams of business rule models, it also lets us simulate the rule logic. This tool helps us speed up the rules harvesting process and improves the quality of our rulebooks.

BIZRULES® RuleMap™ is an interactive rulebook that models business rules and simulates business logic.  This logical model lets you see how your business rules really work. It lets you visualize the Reasoning Chain™ that leads to smart conclusions and right decisions.


We use this tool to document your business rules independent of any BRE - yet it can be implemented using any BRE. Again, this is a logical model of your business rules.  It can be used as the rulebook or specs for authoring the rules in any BRE.

Take a look at a sample RuleMap. And let us know what you think. Contact us for pricing or a web demo.

 

 

December 29, 2005

Use Business Rule Analysts for Rule Engines; Use Business Analysts for Code

I'd like to wrap up my blogging for the year with a couple of thoughts that I'd like to explore further next year.

My first thought is about the risks of offshoring rule harvesting. I'll talk about that next year. My second thought is on the state of the rules market. I'll write about that in my next blog. My third thought is about the differences between a business rules analyst and a business analyst. Here it is...

The business rules analyst is focused on separating rules from code. The rule analyst walks and talks business. He or she talks about business terms like customers and products and prices and services and business strategies and rules and policies and procedures and functions and rules and responsibilities and authorities and operations and conditions and action. The rule analyst talks about business rules and business logic. The rule analyst means business.

The business analyst sees rules as code. The business analyst talks about the system. A business analyst is often a systems analyst by nature, and by training. The systems analyst talks about program fields and screen fields, tables, user interfaces, primary keys, referential integrity, and code. When they talk about conditions and actions, they're often talking about what action to you take when the user pushes this button or that button on the screen. The systems analyst talks about program rules and program logic. They talk about the data access layer, and the bits and the bytes. The systems analyst means code.

Most Subject Matter Experts I know will tell you that they are sick and tired of having IT systems analysts come in and ask them the same questions over and over again. A good business rules analyst will ask that question once, and write it down once and for all.

I know it's confusing, and I can understand why some companies that are new to business rules think all they need is a business analyst to do rule harvesting. Maybe it's the title of business rules analyst or business rule harvester.

I don't like any of those titles, because they leave out one of the keys to success with the business rules approach and business rule technology: knowledge.

Back when business rule engines were called inference engines or expert systems, we used to have knowledge engineers. The knowledge engineer would handle knowledge acquisition, knowledge representation, and knowledge engineering.

Three things you miss when you use a business analyst instead of a knowledge engineer is knowledge acquisition, knowledge representation, and of course knowledge engineering. You also miss discovering and retaining the knowledge about the rules and the knowledge behind the rules. You miss the knowledge about what rule to use when and why. You miss the knowledge the experts have and need to use in order to figure out what the rules are. The good business rules analyst, or knowledge engineer as I like to call them, elicits this invaluable knowledge from the experts, digitizes it, and memorializes so it cannot be forgotten.

If you don't use a business rules analyst (i.e. a knowledge engineer) on your business rules project, you won't capture the true business knowledge, and you won't get all the business rules. You will get lots of computer program rules, and you will increase your risk of failure.

Companies often run into trouble when they try to use business analysts instead of business rule analysts to define their business rules.

That's when they call BIZRULES. We help them get back on track with the business rules approach, methodology, and technology.

In many cases, the client's business analysts have invested a lot of time writing use cases, and everyone thinks that the business rules would be in the use cases. Eventually the client discovers that use cases are useful for designing object-oriented systems, but they're really not that useful for defining business rules. That's one problem.

Another problem is that the business analysts are often really systems analysts with a new title. They are coming at this from the systems point of view, from the code perspective, from the technology side, not from the business side.

But the biggest problem is that most companies do not know what the business rules are. There is no rulebook that tells management what the rules in the existing system are, or that tells IT what the business rules in the new system should be.

Companies decide to use rules technology because the rules change often and because they see a lot of value in enabling the business people who make the rules to actually write the rules in the system.

Once they leap into the business rules side (is that the dark side?) companies realize they need a rulebook with the rules of the business. They have specs, and lots of good documentation, but they usully don't have a rulebook that you could use to author the rules into the rule engine. So they need to go thru the rule harvesting phase of the business rules approach.

Some companies new to the business rules approach consider using business analysts (i.e. systems analysts) instead of business rule analysts (i.e. knowledge engineers) for rule harvesting.

That approach works for traditional IT-driven procedural hard-coded applications. But for leading-edge business-driven declarative rules-based applications, traditional business analysis and systems analysis techniques are probably not going to work. Knowledge engineering techniques and business rules analysis techniques, however, will work.

I believe there is a very significant difference between a business rules analyst and a systems analyst.

The rules analyst wants to define the business rules separately from the code. He or she wants to store the rules in the rules engine. Their objective is to write rules for rule engines.

The systems analyst sees rules as code. They want to embed the rules in the program code. Their job is to document the rules so they can be hard coded in whatever language the programmers are using.

There's a lot more to it than that, so I'd like to continue the discussion next year. Meanwhile, I'd like to hear your thoughts on this topic. What do you think is the difference between a rules analyst and a business analyst?

Have a happy and safe New Year's Eve. And best wishes for a great new year!

June 10, 2005

It's Too Good to be True

A short time ago one of our Knowledge Engineers went to a Business Rule Engine software vendor training course with IT People and Business People from one our clients.

Surprise! The client's business people loved the rule engine software (BRE #1) because they could write rules in an English-like language. The client's IT people didn't like it as much because they could write rules in an English-like language. It had something to do with, uh, you know, hey, if we actually used this thing we wouldn't need some of our IT business analysts because the tool is so good that the Subject Matter Experts / Domain Experts could author the rules themselves without IT Business Analysts... And if we ever figured how to really use this engine, we may not need some of our IT Programmers either... (See: "the usual suspects")

So, the client decided to use another BRE software package (BRE #2) that:
  • Required the larger IT infrastructure investment and ongoing IT support that this client was used to

  • Didn't have as "English-like" a language. Because it was more like a typical "programming language", it would be eaiser to the IT People to learn

  • The rules were written in a "Java-like" language that IT People understood better
BRE #2 tool enabled Business People to write their own rules just like BRE #1. It opened up some of their simpler rules so they could be authored by Business People instead of IT Programmers. The more complex rules will still require IT assistance. The Business People believe they will be able to write most of the rules themselves (without IT) using this powerful tool. The IT People see it diferently - they believe that the most of the rules will require some IT support, or that the Business People will call and ask IT to write the rules for them. Time will tell how this plays out.

Now both the Business and IT are happy. BRE tool vendor #2 is happy. BRE tool vendor #1 is not - They lost this sale because their tool was too good to be true.
Locations of visitors to this page