There is a system on the Web that works as a kind of Wiki, and also as an SOA endpoint, for content in open vocabulary, executable English.
As befits a Wiki, shared use is free. Just point a browser to www.reengineeringllc.com .
Since the executable knowledge is in English, Google indexes and retrieves it, acting as a kind of registry.
You can use your browser to specify applications in English, run them, and get English explanations of the results.
Read more »
The need for a bridge is not just when an application is being developed but also when it is being maintained and evolved for the rest of its useful life. Unless the business people whose business it impacts and the technical people who support it can collaborate effectively and constantly, things will not go well. The use of business rules in an application or service can ensure that the bridge gets built and kept in use over time. This is the core value proposition.
Read more »
“The biggest problem we have in software is communications between the business people and the developers.”
“We are used to seeing and hearing about big IT failures, but often the communication gap is in small things, delivering things that aren’t very useful.”
You want programmers to apply their unique skills (abstraction, technology know-how etc) while allowing business users to manage how the system implements their business.
So if business users do not want to write code, and programmers are challenged to write the code that embodies the way the business "thinks", what's the answer?
The method begins with the intentions of the people inside an organization who know what a program should do. Mr. Simonyi calls these people “domain experts,” and he expects them to work with programmers to list all the concepts the software must possess.
The concepts are then translated into a higher-level representation of the software’s functions called the domain code, using a tool called the domain workbench.
Read more »Jeremy then lists some great questions along with proposed approaches to address them. Some of them seem to me to relate very strongly to business rules:
* Can I find the code related to the problem or the requested change?
And once I find it can someone who understands the change also read the code?
* Can I understand the code?
And who am "I"? A programmer or someone who runs the business?
* Is it easy to change the code?
Can I change the "rules" and put new rules into production without downtime?
But aren't business rules the same as requirements? No, not really. As Kulak and Gurney4 say, "Use cases ... cannot portray all the subtleties of how a business is run. For this, we need business rules ... A list of business rules is not the same thing as a list of requirements ... Business rules are the written and unwritten rules that dictate how a company or agency conducts its business. Requirements relate to a specific application being considered or developed."
Read more »