Repeated biennial surveys by the Standish Group since 1994 have shown that nearly three-quarters (73.3%) of US software development projects fail, either through cancellation at some point during the development cycle (25.9%), overrunning their budgets or time estimated and offers fewer features and functions than originally specified (47.4%).

http://www.standishgroup.com/sample_research/chaos_1994_1.php

One of the major causes given for cost and time overrun is restarts, where for every 100 projects that start, there are 94 restarts (This does not mean that 94 of 100 will have one restart, some projects can have several restarts.)

The reasons given for project fails were (in order of factor):

• Incomplete Requirements
• Lack of User Involvement
• Lack of Resources
• Unrealistic Expectations
• Lack of Executive Support
• ....

Several Items of the list point to develop centric culture of many IT development organizations, often developers expect user to learn their language in the form of flow chart or UML diagrams, it is an error. Project teams must develop languages based in simple conceptual model of the domain, written in easily terms that can be understood by users and developers. BRMS have a role to play in this challenge for IT in today's fast-moving competitive environment.

Also, the cost of maintenance: 85% of all software development costs occur after the product has been released, where 80% of maintenance is due to unmet or unforeseen user requirements and only 20% is due to bugs or reliability problems. The cost of change is 1 unit in the definition phase, 1.5 to 6 units during the development phase, and 60 to 100 units after release (Pressman).

From the perspective of the developer, one of reasons that object-oriented based development is so attractive: If the maintenance is localized to the change objects, these changes do not propagate to other objects. However this benefit does not extend to changes to the business rules if they are scattered around the application or tightly bound to interface definitions. A typical change involved numerous groups of people and a multitude of processes to ensure that a business change was translated and effected into the business application.

The change in business policy is driven in large part by the change in the marketplace, in that businesses have to react to several different competitors and have to cater to an increasing number of diverse customers. It is important to react to change faster than competitors are, and the reaction time is decreasing every single day. The combination of change and reaction time is placing even more pressure on information technology teams as time goes by.

Many products in the industry today profess features that can solve the issues of complex processing. There are also a few technologies that permit the development of a rules-based processing system. Rule programming languages such as 'lisp' and 'prolog' have existed for a couple of decades.

Smart Rules offer the solution to remove the definition of policies from implementation and code details and place them in a central location (the rule space). Smart Rules systems allow to externalize business rules and to provide a facility for centralized business rule management. This addresses an urgent need businesses do have nowadays: to change their business rules in order to adapt to a rapidly business environment, and to overcome the restricting nature of slow IT change cycles.

SmartRules based applications are computer applications that use rules to provide recommendations or diagnoses, or to determine a course of action in a particular situation or to solve a particular problem.

The SmartRules Suite allow to rule-based applications

• Capture policy and rules that are subject to frequent changes.
• Implement those changes quickly and easily within a business application.
• Manage and writing rules in a familiar business language.
• Business users can update software according to their schedule, rather than IT's.

The success of a rules-based application is achieved when the business logic – the policies and knowledge of the business – is abstracted from the application logic; expose them across the enterprise via enterprise-class technical architecture. This makes the process of creating and changing business logic much easier. The same change requested by business users can be implemented without changes to program code by isolating the change and testing only the rules that were modified. Rules-based applications tend to be easier to maintain and at a lower cost because code does not have to be redesigned, retested, recompiled and redeployed for every minor change in business processes.