Transitioning From “What” to “How” With Business Rules and Conversational Semantic Decision Support (CSDS)

Let’s take a closer look at a possible conversation between a SME and a machine.

1. A Business Analyst (BA) writes a line of requirements: “application starts with login” and the service would reply “Do you mean the Authentication Service?”

CSDS consumes a line entered by the BA and uses a semantic model to map the line to one of the existing service names. In this case it was the Authentication Service. CSDS will ask for a confirmation, following the rule: a decision has to be made by a person, not a machine, while the machine performs all the boring part of work, like scanning against models and catalogs and mapping to proper terms and formats.

2. The BA confirms and the service asks “What Roles and Privileges do you have in mind for your users?”

The machine started a conversation to retrieve important information that otherwise can be omitted. Of course, this conversational script was prepared by someone upfront.

While Business (a SME) knows the answers, an Architect, trained with a systems approach, can provide good questions for the conversational scripts.

3. The SME’s answers are checked against the terms of Data Dictionary, Business Model and growing ontology. This “Reality check” and the following feedback to a SME help fill in the informational gaps. If the BA introduces a new Role that is not known to the model, CSDS would ask to define the role via known properties.

This is not an artificial intelligence (yet) but a good combination of a computer’s power with people’s expertise.

Every step should provide more help to a SME, which in turn will help grow the tree of knowledge and related productivity. This is a natural result of daily interactions between a SME and the system. Here are several examples, practical business cases where CSDS will shine:

a)      Formalization of Business Rules

One of the current development trends is a shift from built-in code business logic to rule-based applications. Since they are more flexible and quickly adaptive to business changes, rule-based applications live a longer life and provide higher return on investment. Conversational semantic decision support can be very helpful in collecting and formalizing the rules [5]. CSDS will make sure that the rules are expressed in known terms and rules criteria are directly tied to existing data.

b)      Service integration and data mapping

In its evolution, service integration has developed from Point-to-point interfaces to the Centralized Integration Design Pattern and then to the Canonical Interface Design Pattern.

c)      Enabling best practices in development

Not just teaching best practices, but in a very practical way helping their implementation.

Let us start with requirements. Business Analysts traditionally write requirements in MS Word documents with a mix of “what” and “how”, with both: informational gaps and unnecessary details. This old and comforting practice on the business side causes extra time on the development side for re-discovery and translation layers. We can effectively optimize the development process from requirements to implementation by using Conversational Semantic Decision Support. We can retrieve necessary information from business users by asking the right questions. The architecture diagram below serves us as the base for creating conversational scripts or forms.

We go far beyond drawing diagrams. We actually enable best practices and decrease information gaps.

The simplest example of the Conversational Support is a form, like the one below.

The form will retrieve initial information and check information against a growing ontology. The system’s feedback will include hints to help a user providing valid entries. For example, it will not accept unknown names in the parent field (BF supports other business functions or goals), and will re-enforce a hierarchy with no gaps. At the same time, internal items can include new names and the user will be invited to define them later.