« XBRL Ends Spreadsheet Hell | Main | Yahoo Pipes »

XBRL Killer App: A Radically Tailorable Tool

Several different parties are dancing around the idea of what the killer application for XBRL might be.  Consider these three sources:

  1. Neal Hannon and W. David Stephenson, in their article What Recovery.gov Could Learn from TurboTax,talk about an application as easy to use as TurboTax which is pre-formatted and has a strong set of business rules running behind the scenes.
  2. Philip Elsas gave a presentationat the University of Kansas 2009 International Conference on XBRL.  He discussed the idea of a "smart XBRL application", gave some examples of a Deloitte smart audit support application, and discussed the idea of a killer application for XBRL assurance.  He discussed how business rules (formulas) could be used and an off-the-shelf "builder based" application (similar to template driven).
  3. Thomas W. Malone, Kum-Yew Lai, and Christoper Fry discuss ideas behind what they call
    "a radically tailorable tool" for cooperative work in a paper unrelated to XBRL, but whose ideas, I belive, are quite applicable to XBRL. In the paper this radically tailorable tool is configured by modifying four different types of building blocks.  Now, I don't think the building blocks outlined there are the right building blocks for XBRL (but then again, who knows), however the idea of building blocks is a good one.

A couple of things and then let me summarize my view of the characteristics of the XBRL killer application.  First, the idea of building blocks has been of interest to me and seemed to be the right idea for quite some time.  If you look at the XBRLS architecture document and the XBRLS Business Use Cases (see http://xbrl.squarespace.com/xbrls) you will see the notion of building blocks used there.  Part of these building blocks are the XBRLS meta patterns and the neutral format tables.  Another thing that really got me interested in building blocks was an application I saw during a parent/teacher's conference at my daughter's school of all places.  They used an application called Scratch (see http://scratch.mit.edu/).  The application lets its users use what remind me of Legos to construct programs.

Now, if you take all of this information from the wrong perspective, you will not see how all of these ideas combined to paint a picture of what really could be an interesting way to create business reports.  Another way to miss the point here is to be fixated on XBRL's physical model and not realize that the thing which could (a) make this work and (b) help realize the potential of XBRL and allow for the creation of a logical model which is a missing piece of the puzzle here.

This is what I think:

  • TurboTax is the right target in terms of "ease of use".  Frankly, I think there are more elegant interfaces (such as Microsoft Money or Microsoft TaxSaver) but TurboTax is better known.
  • But when you think of TurboTax, you need to think of the piece that you DO NOT see.  How do you think the folks at Intuit modify that application, adjusting it for changes to the tax code from year to year?  They either (a) have an application which allows them to adjust the forms and rules or (b) they have a whole lot of programmers working at really low levels, changing the application at the code level. I speculate they have an application which they use to make modifications and then they "compile" the application providing the updated forms for the new year.
  • That piece you don't see is the "radically tailorable tool" piece of this puzzle.  You can look at this as pre-formatted templates which users can adjust, allowing them for DYNAMIC business reports, not the STATIC forms of TurboTax.  Users can change the templates.
  • But the templates are not infinitely flexible in all directions.  That would make the application so hard to use that it would be useless.  The application highly flexible, within a very rigid framework.  The user does NOT work at the XBRL level, they work at the logical model level, using a fairly small number of building blocks to configure the application.  Again, users do NOT work at the XBRL physical level, they work at the logical level.  That is why a logical model is needed, because XBRL needs ONE logical model, not one logical model per software vendor which would hinder interoperability between software applications which is sort of the entire point of XBRL in the first place.  It is this logical model which hides the physical model of XBRL.
  • Part of these building blocks is a set of rules which makes errors literally impossible.  This is done by writing rules to say what is RIGHT, not to try and detect everything which can go wrong.  This is a HUGE difference.
  • Users only interact with building blocks.  All the complex stuff is dealt with below the building block level.  This is created by really smart programmers who specialize in this sort of thing.
  • The application is integrated with the internal audit process.  How could you possibly create a correct report if you cannot prove to yourself that the report you are created is correct?  Now, there may be additional internal audit functionality and even external audit functionality.  The application is integrated with that also, using XBRL.  External audit processes audit the same data as the internal audit processes.  The only real difference is that external auditors are "arms length" and perform work that helps ensure that no fraudulent activities are occurring, checking to be sure that policies and procedures were actually followed, etc.

Well, that is what I think.  Maybe I am right, maybe I am wrong.  Do you have any better ideas?  If you do, please comment to this post.

Perhaps a nice white paper to write might be something like "Blueprint for the XBRL Killer App".


Posted on Thursday, April 30, 2009 at 11:43AM by Registered CommenterCharlie | Comments3 Comments

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (3)

One of the most exciting presentations I ever heard about XBRL was Walter Hamscher's on its use for compliance (see http://hitachidatainteractive.com/2007/05/11/xbrl-compliance-and-soa/). How wonderful it would be if we could sharply reduce or eliminate the "providing this information costs business too much" component and just focus on what compliance we should or should not have.

Your thinking on how XBRL can automate things like disclosure checklists (see question 11 at http://hitachidatainteractive.com/2008/05/05/an-interview-with-charlie-hoffman-part-iii/) also seems central to a discussion of the XBRL killer app.

Bob Schneider
Editor, Data Interactive (the Hitachi XBRL blog)
May 1, 2009 | Unregistered CommenterBob Schneider
Think that it is great!!

Consider 3 ideas:
- Application(s) <<<<<<<<<< add an 's' as the components approach is very interesting and provides an enabler for market collaboration
- Enabling collaboration among the business users is a key idea. Empowering the consumers/analysts is a pretty compelling idea when dealing with market adoption. Our internal iDP platform has realized significant 'market' adoption largely due to the fact that it empowers the consumer groups and enables them to collaborate.......... analytical iTunes/Wikipedia library of analytical rules and reporting templates leads to a collaborative mash-up for analytics and reporting.
- Place an emphasis on 'Agility' as it enables proactive assessments and real-time processing of transactions for cost/logistics/tax optimization. There is likely a range of tooling components that would be needed in this type of internal implementation and it is on the 'other end of the supply chain' from the external reporting discussion.

Ditto on Bob's comments on WH's presentation.
May 1, 2009 | Unregistered CommenterMike Willis
My compliments!

I think you make an EXCELLENT point to unify:

1. Tax forms: "How do you think the folks at Intuit modify that application?"

2. The builder-player-platform architecture for XBRL assurance

3. The radically tailorable tool concept

By addressing these three subject areas in combination, as different angles towards one common denominator, helps to get the right insight fast.
May 3, 2009 | Unregistered CommenterPhilip Elsas

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):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.