« Understanding the Role of SBRM | Main | Federal Energy Regulatory Commission (FERC) Adopting XBRL »

Object Management Group and the Standard Business Report Model (SBRM)

In December 2018 I gave a presentation to the FIBO working group of OMG a presentation about XBRL.  That presentation started a chain of events. That chain of events led to the creation of SBRM. This two page summary describes SBRM as:

SBRM formally documents a logical conceptulization of a business report in both human-readable and machine-readable models.

The Object Management Group (OMG) has issued a request for proposal for the creation of Standard Business Report Model (SBRM). You can find information about the SBRM working group here.

You can download the SBRM RFP here.

The purpose of SBRM is to define business reports in terms of the logical components of a business report (structure and facts).  This is as contrast to defining a report using technical terms that are alien to most business professionals.

This is achieved by specifying a Standard Business Report Model (SBRM) that includes a metamodel for generic representations of report definitions (including component structure, patterns and rules) and report submissions; and can be linked to independent information models or ontologies and transformed into different technical formats including XBRL and Inline XBRL.  Other targeted formats are RDF and OWL and JSON-LD.

Essentially, SBRM is similar in nature to an application profile of XBRL.  It helps people implementing XBRL become more conscious of what they are doing.  For example, becoming aware of the ontology spectrum. Today, people creating XBRL taxonomies tend to not employ XBRL as effectively as it could be employed.

Some of the best insight provided by the RFP can be gleaned by looking at the reporting scenario categories of standard business reporting:

  1. the data set collection scenario: in this case the regulator requests a table of a predefined structure. The scenario doesn't require any structure for the business report type other than a single table form with predefined columns for collected facts.
  2. the data form collection scenario: in this case the regulator has defined a form that has every data point uniquely defined and there is a presentation aspect to the solution such as predefined labels for the facts and predefined report rules about the facts.
  3. the semi-extensible report scenario: in this case the regulator defines structural components and required facts and the reporting entity is allowed to extend the content of the report with additional details at given positions in the report.
  4. the extensible report scenario: in this case the regulator doesn't prescribe the structure of the report but the reporting entity needs to comply with externally defined domain-specific reporting principles that might include variability of reported information (i.e. not a form); the ability of reporting entities to reconfigure the model (which they must do correctly); add additional information within the existing model (i.e. extend the model); and not reporting certain specific line items which leads to the need to use deductive logic to impute unreported line items during analysis,
  5. spreadsheet: in this case regulators and organizations replace the exchange of presentation-based spreadsheets (workbooks, worksheets, rows, columns, cells) with meaning-based reports (facts, dimensions, controlled vocabulary, rules, relations) which might then be rendered statically (similar in appearance to a spreadsheet) or dynamically (similar to a pivot table).

That is basically the spectrum of business reporting use cases.  My interest is primarily #4 and also #5.

What OMG is explicitly acknowledging here is that (a) business reporting is a spectrum and that (b) the use cases fit somewhere on the ontology spectrum.  The use case itself "picks" where you need to be on the ontology spectrum.  Many people creating XBRL taxonomies or systems are completely oblivious as to the existence of the ontology spectrum or what it takes to exist at some specific point within that spectrum.  The result is quality problems.

This blog post explains all this in terms of XBRL-based digital financial reports.

Another thing that the OMG RFP does extremely well is explain something like XBRL in context of the enterprise.  XBRL-based reporting has to work correctly to be useful internally within an organization.  It has to be easy enough for business professionals and accounting professionals to approach and make use of the technology.  Forcing business and accounting professionals to learn technical details simply will not work.  Software engineers need to be smarter about implementing things like XBRL-based financial reporting and other business reporting use cases.

I predict that the next three years will bring profound change to the world of "XBRL".

For more information about SBRM see the SBRM wiki provided by OMG.  If you are a member of OMG and are going to respond to the RFP, let me know.  If you are not a member of OMG and want to be on a response team contact me and I will help you get on a team.

Essentially, this is where I think SBRM will go, something similar to my implementation of the Logical Theory Describing a Business Report that I created using pure, 100% global standard XBRL:

Currently, I am aware of three implementations of my logical model. On of the implementations is a good old expert system. It leverages the structures talked about by OMG. I call the structures "blocks".  Blocks are not my idea.  Others use the idea of blocks.  I got the idea from Blockly and Scratch.  Our ideas and experiences are documented here and here. All this is tested and proven.

SBRM will have to be what I created or better. It cannot be less or worse. SBRM will help business professionals create the rocket fuel that will cause XBRL-based digital financial reporting to really take off.

If you think otherwise, tell me why.

Posted on Tuesday, June 25, 2019 at 08:45AM by Registered CommenterCharlie in | CommentsPost a Comment

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
All HTML will be escaped. Hyperlinks will be created for URLs automatically.