I assert that OPA content (excluding the input controls) frequently changes independently of the rules. 

 

For all OPA project architects, please bear with me on this long blog post.  Please just follow along for a bit.  It will be worth it if you take the time.

 

Let's look realistically at an example project included with OPA: the example Warranty project.

 

Realistically, the example Warranty project screens would need to be enhanced with much more information content prior to production.  Examine all the Warranty project screens to see what I mean:

 

 

My point in going through all the above screens is that in many (most?) real-world OPA applications, questions and answers (input controls) are accompanied with content. If the application above were to be published and maintained, the project team would need to anticipate frequent changes to the content independent of the rules.

 

Consider the following guidance:

Intent

Separate the architectural concerns of policy and content, putting policy management in OPA and content management in a CMS.  Policy is realized in rules and attributes collected with input controls.  Content is realized in html paragraphs, images, videos, documents and such. 

Problem

Content is often changed separately from rules, and content may contain separate life-cycle from rules. If content changes require new publishing of OPA policy rulesets, then that introduces additional life-cycle management issues.  Further, content addition directly inside of interviews tends to "clutter" interview screens. Content placed directly in interview screens is not easily shared, managed, and searched outside of the interview screens.

Discussion

An example follows.

 

The problem is most often seen when important notes, textual descriptions, and graphical media types are coded directly into OPA interview screens.  There are even interviews where the interview goal is to direct the interviewee through content.   The content itself frequently changes, but the rules to get to the content do not change. 

 

By using a CMS and having the CMS content show up in-line in the interview, the content can follow a different lifecycle than the rules.  When a CMS is used, the only requirements of the OPA interview screens are the interview control settings to display the content.  Generally, an OPA control that retrieves CMS content via a REST API is utilized.

 

The interview control to retrieve CMS content is written once, and used everywhere in the interview that content is needed.  The interview control can be displayed or not displayed based on OPA visibility rules.

 

As an added benefit, any content media types available in the CMS becomes available in OPA. Additional OPA controls do not need to be written for OPA to handle video or other media types.

 

Whats more?  The content can be formatted in a WYSIWYG editor in the CMS.  That means no more need to put html into labels...

 

Structure

In demonstrations, we tackled CMS integration by having an OPA label extension that displays content retrieved from a CMS REST API.  The interview control properties are set to either search, filter, or directly access content from the CMS.

 

The effect is that in the Interview, labels are placeholders for content and take up very little interview design real-estate.  That allows the interview focus to be on the various questions (inputs) and on the flow in general.  This has been seen to greatly simplify OPA interview screen development where a lot of varying content is involved.

 

Example

I put up a WordPress site (modern WordPress is a CMS for those architects living under a log) with information regarding Warranty.  This information can be changed by the business on the WordPress site with a WYSIWYG editor independently of OPA.  Changes appear real-time in OPA.

 

For OPA, I added a control extension that uses the WordPress API to retrieve content.  Content can be directly retrieved, retrieved via search, or retrieved via filters (keywords).

 

In OPA, the new interview Welcome screen looks as follows (with label properties used for each item of WordPress content):

 

This produces the following interview screen after publishing on the web:

Notice that the red alert, the image, and everything retrieved from the CMS is independent of the OPA rules and OPA interview screen development.  The business has freedom to change the content separately from the rules and input controls.

 

Also notice that the actual OPA interview screen is nice, condensed, and easily read for interview flow.

 

See the huge difference a quick CMS integration provided, compared to the original OPA interview screen shown again here: