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

Limitations of Business Natural Languages
Business logic can be highly complex and unrelated. A Business Natural Language becomes more complicated as it expands the scope of problems it addresses. As the complication increases the value of the language decreases. Therefore, when designing a Business Natural Language it should address only related business logic. One application can contain several Business Natural Languages. By limiting the scope of each Business Natural Language it will be easier to understand and use.

Every application should not include a Business Natural Language. In fact, businesses should not invest in creating a Business Natural Language unless the application contains logic specific to the business. An example of an application that, despite being a complex application, likely doesn't warrant the use of a Business Natural Language is a content management system (CMS). Creating a CMS is no easy task; however, the business simply wants an application that allows them to easily display static information. There is no reason to design a Business Natural Language when an application, such as a CMS, does not contain any business logic.

Business Natural Languages are designed to empower people who contain specific knowledge. By empowering these individuals the business can run more efficiently. However, Business Natural Languages should not be used as an excuse to delegate work. For example, even though you could empower a subject matter expert to specify the database connection string, you shouldn't do it. Maintaining a database connection string is the responsibility of the IT staff. Creating a Business Natural Language is unnecessary in this scenario since the IT staff should be perfectly comfortable with XML, YAML, or some other form of configuration file.

It should be clear that you could use a Business Natural Language within a configuration file. This makes sense because configuration files are simply files that contain logic expressed in a Domain Specific Language, and Business Natural Languages, XML, YAML, etc are all DSLs. However, before investing the effort to develop a Business Natural Language you should ensure that someone would benefit from the investment. While it may be technically interesting to use a Business Natural Language to configure an Inversion of Control container, it is likely a waste of time. When determining whether or not to make the investment it is important to consider the following questions:

Who will be responsible for writing the business logic?
What are the chances that this logic will change?

If the answer to the first question is "a subject matter expert whose role does not require technical depth" and the answer to the second question is "it's possible" then you likely have a good candidate for a Business Natural Language. When thinking about the first question it is more important to consider the subject matter expert's role than a specific person's skill level. If you only think in terms of the person currently in that role you risk creating an un-maintainable system if the technically savvy subject matter expert leaves their current role. However, if you design a Business Natural Language that can be understood by any subject matter expert in that role, then your systems maintainability is greatly increased. The second question and answer should be fairly straightforward. It makes sense to abstract the logic in a way that allows a subject matter expert to maintain it if the logic has the possibility to change.

Another situation where it could be unclear whether to use a Business Natural Language or not is when a subject matter expert creates a specification that is not specific to the business. For example, a subject matter expert may create a requirement for the system such as 'the message entry textbox on the invitation page should not allow more than 500 characters'. While this requirement does come from a subject matter expert it is not a requirement imposed by the business. These types of requirements do not often warrant the investment of creating a Business Natural Language. A major reason why a Business Natural Language loses value here is because the business probably does not have specific language around field validation. So, from their perspective it's almost the same level of effort to read either of these two DSLs:

'the message entry textbox on the invitation page should not allow more than 500 characters'
page: invitation; field: message entry; limit: 500

That being said, if some of your validations were tied to business logic then it does make sense to use a Business Natural Language. Examples of this could be to only accept 9-digit social security numbers, Florida driver's licenses must always start with the first letter of the driver's last name, or if you claim a dependent you must specify their social security number also. Clearly, if some of your validation logic belongs in a Business Natural Language then it makes sense to express it all in one or more Business Natural Languages. If you were to maintain logic in two places, such as an XML file and a Business Natural language logic script, usability clearly suffers. On a similar note, if your Business Natural Language begins to explode with all the types of validations you are supporting, you should consider grouping similar validations in separate Business Natural Languages. As previously stated, you should look to separate a Business Natural Language when it will increase readability and ease of use.

One major advantage of creating a Business Natural Language is empowering subject matter experts to specify the behavior of the system in the language of their business. Unfortunately, language rarely transcends multiple corporations. Therefore, it is unlikely that a generic set of Business Natural Languages could be created to address the needs of a business vertical. (I.e. insurance, leasing, etc)