Over the last six years, I have noticed how companies have increasingly struggled with the upkeep of business decisions and processes. If new opportunities arise and prompt changes to software applications and systems, the IT group comes under renewed pressure to roll out these changes faster than ever before.

The pressure toward faster business decision management occurs both internally and externally. Have you noticed floods of privacy notifications arriving in your inbox recently and asked yourself, “What the heck is going on?”

The answer lies with the European Union, who introduced a new set of data privacy protection policies: the General Data Protection Regulation (GDPR). It has caused companies around the world to scramble to update internal systems with these new rules and inform customers of the new policy changes, which have a direct effect on the way business is conducted.

To meet all these internal and external decision/rule changes, companies have started to invest in Business Rules Management Systems to allow for the implementation and management of rules in a consistent, visible and traceable manner, separated from other IT systems.

Great! Problem solved, but not so fast. Are we now placing the management of business rules/decisions in the hands of the IT organization? This is the dilemma that most companies face today. We have the tools, but who will police and author these rules and processes? Traditionally, the business side produced the high-level rules and threw them over the fence for the IT group to implement, but that has not been working so well. This is where our new sheriff arrives on the scene.

Wielder of the Domain Model

As an organization grows and matures, it needs to recognize the importance of managing policies, regulations, decisions and processes to stay competitive. The need for managing knowledge in an organization has become a critical factor for success. Whether organizations want to acknowledge it or not, knowledge has become the center of modern software architectures, but:

• Who is responsible for managing it?
• How can we as an organization be successful at managing knowledge?
• What is exactly being managed and what does it look like?

A new position emerges: the knowledge engineer. But who exactly is a knowledge engineer? Are they a software engineer or a business analyst? To answer this question, let's first look at the knowledge life cycle diagram that we’ve developed here at Vizuri.

Knowledge Life Cycle

It all starts with the Concept Model on the business side, which includes the concept of operations (inflow and outflow of information), process/workflow definitions, decisions/rules, policies, regulations, and key performance indicators (KPIs). The knowledge engineer holds the responsibility to produce a well-formed lexicon that can be understood by all parties involved. To digest knowledge for this purpose, the knowledge engineer, like a true sheriff, wields four processes which they use to police all knowledge/information:

• Collection
• Assimilation
• Protection
• Governance

Next, multiple Domain Models need to be developed hand in hand with the IT organization to separate and decouple business rules and processes from the underlying IT infrastructure through the translation and expression of code and data to conform with the Concept Model. The Domain Model forms the foundation for rules, process development, and the vocabulary that bridges the historical gap between the business and IT sides of an organization.

Using the Domain Model, the knowledge engineer will be able to author and implement new rules and processes using BRM (Business Rules Management) and BPM (Business Process Management) tools to remove the shackles that handcuff organizational processes and decisions to code and technologies.

Sourcing Your Knowledge Engineer

So what skills and capabilities would a typical knowledge engineer require and who would make good candidates for this role? From the business side of the house, a business analyst may present compelling qualifications. Traditionally business analysts have all the skills needed to harvest and understand complex business rules and processes. However, they lack the skills needed for authoring or implementing rules using BRM and BPM tools. The also lack the ability to interrogate IT systems and develop a proper domain model. This is where a systems analyst from the IT side would be a desirable candidate.

In the table below, I have listed the skills and capabilities required by a knowledge engineer and how it matches up with these two candidates from both sides of the organization.

So who is managing your operational business decisions and processes? With these skills in mind, this list should help you identify the right candidate in your organization for the job or what to look for when hiring. To provide further details on the day-to-day activities and responsibilities of this role, I would like to refer you to the article, The Role of Rule Analyst, written by one of our partners: Business Rules Solutions (BRS).

The well-appointed new sheriff- the knowledge engineer fits in naturally between business and IT as they perform the roles of go-between and lexicon enforcer, bridging the communication/knowledge gaps in your organization. This keystone role emerges amid an ever-increasing need for business agility in today's quickly changing business environment.

If you need any assistance or would like to learn more about Vizuri’s proposed knowledge life cycle, including decision management and/or business rules management systems, just reach out and I'll be happy to personally schedule a time to answer specific questions that you may have.