Some of the biggest problems in the technology sector are not actually related to any specific technology. 

We hear on both the technical and business sides: “We can’t speak to the other department!” “We can’t get what we need from them!” “I’m not even sure we’re working on the same problems!”

In the spirit of digital transformation, Vizuri has long offered clients a framework to use knowledge-based IT in order to close the communication gap between business and IT.

It’s been well-received, but we only decided to write this post when the team realized how much latent demand there is for this approach. Literally, we connected with hundreds of new people on this topic while at Building Business Capabilities last fall.

Based on the slides from our talk on “Designing for the Knowledge Lifecycle,” now available for download and review, I wanted to share our perspective on 6 steps to make this possible with knowledge-based IT. Email us or post a comment if we can expand on anything here that stands out to you.

Step 1: Document “as-is” problems and “to-be” solutions.

In practice, this means untangling a lot of nested “if-else” statements by meeting with your subject matter experts. At the end of this step, you want a full documentation of both problems and solutions.

As you move forward with this documentation, the following questions are a helpful guide as to whether knowledge-based IT is a good fit for your needs.

First, does the problem lend itself to using knowledge-based IT by exhibiting inherent complexity of the business logic? This may sound a bit technical, but the test is simple:

• Is the problem, by nature, highly conditional?
• Does the problem require a high level of subject matter expertise?
• Is the problem definition mature or is it still being determined?

Second, does the problem lend itself to using knowledge-based IT by requiring visibility, consistency, and agility? Some good checks include:

• Visibility: Is there a need for insight into execution?
• Visibility: Is there a need for all interested stakeholders to understand implementation?
• Consistency: Is there a need for problem to be well-understood by all stakeholders?
• Consistency: Does a Concept Model exist that is agreed upon by all stakeholders?
• Agility: Does business logic change unpredictably?
• Agility: Do business logic changes need to be made quickly?
• Agility: Is the current implementation fragile?

Step 2: Get commitment.

It’s essential to get all stakeholders to make a sincere commitment to improve. Project success is contingent on management buy-in, as a time-boxed modernization effort usually takes 3-5 years!

You want to be able to name influential champions on both the business and IT side; otherwise, if only one side has bought into this process, its outputs will be skewed towards unique approaches and needs.

To ensure the long-term success of your effort, you also want to see an appetite to continue support of center of excellence beyond inception.

Step 3: Unify stakeholders through a common vocabulary.

Please note: For the coming steps, you may want to have a look at the slides referenced above for an understanding of how this should look in practice. I’d also recommend our webinar on How to Drive Business Value with JBoss BRMS for a guided walk-through of some of these concepts.

Once you have everyone onboard, you need to ensure everyone is speaking the same language. This ensures easy communication with clear definitions.

A common vocabulary is unambiguous and understood by all. If it’s not immediately understood, it should be easily accessed in a central reference.

For this reason, your Business Rules will need to be succinctly defined in near-human language. You will want the Rules to be close to real language without inviting ambiguity.

You will also benefit from a high-level “happy path” visualization exercise. In this, you can describe the workflow with any exceptions and pretend everything just works.

Step 4: Decompose the problem into understandable models.
Your goal here is to build systems that effectively separate “plumbing” from “knowledge.” There is no single-way to approach this, but it’s helpful to consider the following.

Select a framework that supports declarative logic. Business Rules Management Systems (BRMS) can model and execute logic in near natural language formats:

• Make sure they support multiple concurrent versions of decisions
• Consider small, precise tools rather than all-in-one solutions
• Wrap interactions in business-centric APIs

Decompose the solution in appropriate layers. BPM projects for instance, are best conceptualized in a tiered approach:

• Idealistic (non-executable) Process Definition
• Complete (executable) Process Implementation
• Enterprise Integration Management (EIM) Layer

Decompose the components of the solution to appropriate sizes. The current buzzword for this idea is “microservices”:

• Make a concerted effort to avoid monolithic solutions
• Size to swap out components without disrupting others

Step 5: Build with quick iterations.
Build as quickly as possible with many feedback loops.

We recommend:

• Choosing an Agile software development methodology
• Keeping time-boxed iterations to several weeks
• Instituting a “show and tell” at the end of every iteration
• Creating throw-away User Interfaces that illustrate the intent

Step 6: Continually monitor, adapt and improve.

Build the system so that it exposes the important details.

In particular:

• Processes must be defined in terms of Key Performance Indicators (KPIs)
• Select frameworks that expose these metrics
• Make dashboards so they can be continually monitored
• Rules should be auditable from a business perspective
• Be able to explain why any particular decision was made

We also recommend a simulation environment comparing results of two different versions of the rule set, enabling business to have the confidence to continually improve Rules.

Hope this is helpful. As noted above, please email us or post a comment if we can expand on anything here that stands out to you.