BNL: Introduction - Update

I'm wrapping up another project these days and I'm revisiting my previous Business Natural Language information. The project provided many more lessons learned that I'm eager to add to the existing material. The first 'chapter' remains much the same; however, I made a few small changes. I'm also hoping to generate some more feedback this time around.

Business Natural Languages: Introduction
Business Natural Languages: The Problem
Business Natural Languages: The Solution
Business Natural Languages: DRY code, DAMP BNL
Business Natural Langauges: Moving to the web and multiple contexts
Business Natural Languages: Limitations
Business Natural Languages: Common Pieces

Introduction
Why use a Business Natural Language?

Since the introduction of computers to the general workforce businesses have searched for a solution that will enable subject matter experts to specify the business logic of an application. This solution is highly sought after since it will allow the application to be changed without the assistance of a programmer. Programmers are still required to create the application; however, the application is written in a way that empowers the subject matter experts to maintain the business logic. Enabling the subject matter expert greatly increases efficiency of maintaining an application as the needs of the business change.

Using a Domain Specific Language (DSL) is the most recent solution to this problem. A Domain Specific Language can be defined as a language created to describe a specific set of tasks. A Domain Specific Language is often used to define a specification or business rule without using a general purpose programming language such as Ruby or C#. Domain Specific Languages have been around under various names for many years. In fact, it's rare in today's business world to find a subject matter expert who isn't fluent in the Domain Specific Language in which they define their spreadsheet macros.

Unfortunately, there is a problem with the term Domain Specific Language. Programmers commonly know YACC as a DSL. Spreadsheet macros are widely used within the business community. Recently Rake and Ruby on Rails have gained popularity as DSLs. Some even consider Cobol to be a DSL. Thus the problem, you can make a case for almost anything to be considered a DSL.

Is that a really a problem? Yes, it turns out it is a problem. When we are unable to be specific about what type of Domain Specific Language we are using we are forced to eliminate types of DSLs that are not relevant to the current conversation. This elimination process often slows discussions down. Or worse, people dismiss the conversations because they don't believe that DSLs can work in the way described. This, unfortunately, is fairly common because of DSLs of the past that have failed.

Because of the previous reason I think it's clear that there is a need to classify the different types of Domain Specific Languages. I believe using specific classifications will allow conversations to become more productive. The primary focus of this book is enabling subject matter experts to specify the business logic in a natural language. For several months I used the term Business Domain Specific Language to describe this type of work; unfortunately, the business prefix was generally lost in conversation and the same issues emerged. Because the prefix was not effective at solving the problem I chose to coin the term Business Natural Language (BNL).

A Business Natural Language is a Domain Specific Language; however, not all Domain Specific Languages are Business Natural Languages. Business Natural Languages use natural language to represent business logic. Business Natural Languages are expressed as descriptive and maintainable phrases.
For example, a marketing executive for an airline could specify point award descriptions as:
award 1 point for each mile flown where the total flight length is greater than 500 miles
award 500 points for each flight where the total flight length is less than or equal to 500 miles

A Business Natural Language is a specific type of Domain Specific Language that will not contain unnecessary commas, semi-colons or any other constraint imposed by a general-purpose programming language. Additionally, a general-purpose language should not influence the structure of a Business Natural Language phrase. Any domain expert, with no explanation required, can read a well-written Business Natural Language as if it were simply a phrase specifying logic.

The previous airline example appears to be a specification written by a business analyst. The specification could be used to describe business logic to be implemented in a general-purpose language. However, when using a Business Natural Language the above example is a specification, but also much more. The above example is executable code, which will be used to determine point allocation after each flight flown. The above example is also documentation of the business rules contained in the point allocation application. And, the above example can be used to formulate a test case to verify the system works as expected.

Business Natural Languages allow you to specify, in one location, exactly how your application should work. By reducing duplication the maintainability of the system is greatly increased. When using a Business Natural Language the lines are not blurred between the specification and code, there are no lines. The specification is the code.

When should you use a Business Natural Language?

Business Natural Languages are ideal for systems where the behavior often changes. Generally the value of these types of systems can be directly linked to their ability to be quickly changed. In most traditional applications the business rules are specified in a general-purpose language. Changes to this style of application generally require a programmer to understand and alter the existing code base. However, a superior approach allows the behavior of the system to be specified by a subject matter expert. A Business Natural Language is an obvious choice for this scenario because it removes the programmer from the equation, often greatly reducing the time required to alter the application's behavior.

Frequently changing systems are not the only applications that can benefit from Business Natural Languages. Systems that contain a large number of similar business logic are also ideal candidates. For example, imagine a payroll system that is used to compensate your sales force. In this payroll system each employee has specific variables that determine their compensation for each pay period. Their pay could be altered by variables such as the amount of business sold, profit margin per transaction, years with the company, etc. Each employee could have their own negotiated parameters for determining their pay:

employee John Doe
compensate 500 dollars for each deal closed in the past 30 days
compensate 100 dollars for each active deal that closed more than 365 days ago
compensate 5 percent of gross profits if gross profits are greater than 1,000,000 dollars
compensate 3 percent of gross profits if gross profits are greater than 2,000,000 dollars
compensate 1 percent of gross profits if gross profits are greater than 3,000,000 dollars

When a system utilizes a Business Natural Language it becomes easy to add a new employee into the system and ensure that their compensation will directly match exactly what their offer letter details.

When else is a Business Natural Language appropriate? Business Natural Languages are ideal for any application that contains logic specific to the business. The more business specific logic you can abstract out of an application the less programmer involvement you will need to alter the business logic. Ideally all business specific logic can be contained in one or several Business Natural Languages within your application. By enabling the subject matter experts to maintain the business rules of the application the teams can work together to quickly develop a robust application.

I was recently involved in developing an application that was estimated to take 6-8 months using a traditional development approach. Because of time to market issues this was not a viable plan. The alternative approach, using a Business Natural Language, allowed the general application to be written by the developers while the subject matter experts wrote the business logic. The application, including business logic, was complete in 4 months. During the 4 months the programmers and subject matter experts worked in parallel constantly evolving the application. While the application was being developed the subject matter experts found they needed more flexibility in their Business Natural Language. Because the teams were working in parallel the programmers were able to immediately expand the boundaries of the Business Natural Language to meet the needs of the subject matter experts.

These types of stories can vary in value due to the fact that we will never know how long it would have taken to complete the task in a traditional manner. However, what is measurable is the level of effort that the application requires to change the business logic. For this application the logic of the business can change on a monthly basis. If the rules were written in a language that required a programmer to make the change, each month a change request and prioritization session would be required. The customer for this application stated that this process generally took 2 to 3 days. Following the change, regression testing was necessary to verify that the programmer correctly implemented the change. Compared to what we actually delivered, this process is greatly inefficient. Because we chose to use a Business Natural Language, a change could be made to the business logic directly by the subject matter expert. We also provided a test environment to run the proposed business logic. This allowed the subject matter expert to make a change, execute, and verify without any programmer support. The result, in his words was "A change that used to take 3-4 days now takes about 10 minutes."

Traditional applications waste precious time in various ways. While developing software, much time is spent educating programmers on every minute detail of the business. With this knowledge, programmers are busy developing code in a general-purpose language that mirrors the specifications given by subject matter experts. Following completion of the programming task there are often issues discovered. This cycle repeats until the program executes producing correct results. This common development loop is a time consuming process. Systems that are able to introduce Business Natural Languages avoid this loop entirely by empowering the subject matter experts to create, test, and approve the business logic with little or no assistance.

Clearly, the decision to use a Business Natural Language depends greatly on the ability of the business to provide at least one subject matter expert. At first glance it appears that a Business Natural Language creates more work for subject matter experts; however, it is important to remember that traditional application development requires subject matter experts to write specifications for the application being developed. Business Natural Languages also require the subject matter experts to create specifications, but by following some simple conventions the specifications are used within the application as actual business logic. Furthermore, anyone who has been involved in conversations where subject matter experts explain business logic to programmers has seen how challenging it can be to bring everyone's understanding to the same level. Also, even following the conversation the programmer still only has as much context as the subject matter expert was able to express. This can lead to costly assumptions because the programmer does not posses the full context that a subject matter expert has. In these scenarios a Business Natural Language can reduce the amount of overall work for a subject matter expert.

Using a Business Natural Language can also greatly simplify deployment of new business logic. For example, in the last application I delivered the business logic was stored in a database. The application provided a UI that allowed the subject matter experts to make changes to the business logic. When a subject matter expert was content with their changes they would save their changes back to the database. In this application all changes are required to pass through a workflow before becoming active. The entire workflow process is also done through the application's user interface. Submitted changes require approval from another employee before being included in the application. Once the logic is approved it may be immediately activated through the user interface. Each time a process executes it will execute all activated logic. In this scenario, the workflow is the deployment.

Program execution when using a Business Natural Language

A common concern when using a Business Natural Language is that the logic is executed in an expected way. For example, if you work for a casino and you want to find high rollers you could use these phrases to segment your player population:

include players who bet less than 100 dollars a hand in the unimportant category
include players who bet between 100 and 150 dollars a hand in the valuable category
include remaining players in the high roller category

If the last phrase executes first, all of the casino's guests will be considered high rollers. Obviously, this is a serious problem. To mitigate this issue each phrase should be executable in isolation without dependency on any other phrase. The last phrase could be rewritten as such to conform to this rule:

include players who bet more than 150 dollars a hand in the high roller category.

When statements can be executed in any order the dependency problem is solved; however, this does require that each statement contain all information required to execute the business logic. For this reason it is acceptable and even expected that duplication will exist in several if not all of your descriptive and maintainable phrases.

Along the same lines, it should be clear that you wouldn't chain or link multiple statements together. Also, a Business Natural Language would not contain variables or looping constructs. Again, each Business Natural Language phrase should be valid entirely in isolation.

Because of these limitations it should be clear that a Business Natural Language is not a silver bullet. For example, some companies use rules engines to manage their business logic. While a Business Natural Language could replace the simpler implementations, I do not expect that you would ever attempt to replace a complex implementation with a BNL. The value of a Business Natural Language can be derived almost directly from the narrowness of the scope of the problem being solved.

Tracability is fairly simple due to the the constraints associated with Business Natural Languages. As the amount of logic increases the complexity does increase; however, since each phrase can execute in isolation it is fairly easy to follow behavior as the phrases execute individually. Also, at the heart of it a Business Natural Language is really a facade to an API. Therefore, if necessary, a programmer can step through each line of the Business Natural Language while as it executes.