Watching ‘Mary Poppins’ and the delectable Julie Andrews administering that spoonful of sugar somehow reminded me of the S.E.C. and of one of the future directions in corporate reporting – namely RaaS or Reporting as a Service. And before you switch off, I don’t mean delivering reporting functionality as an online SaaS application – we already do that. I mean RaaS.
When you file to the S.E.C. today using XBRL you are operating in a ‘push’ mode. You create the filing and transmit/upload it to the S.E.C. But why can’t the S.E.C. simply ‘pull’ the data from your internal XBRL repository as and when it needs to, saving you the bother? Never mind a 10-K or a 10-Q they can have a 10-D (daily) if they really want it. Be my guest.
The reason is that RaaS doesn’t exist but there is no reason why it shouldn’t.
The way Facebook and Twitter and Flickr and dozens of other cloud crowd apps provide access to their data is through something called an application programming interface or API. A geeky term for a software layer that manages how a data provider (providing application) interacts with a data consumer (consuming application). To deliver Data as a Service you need to create an API – most serious enterprise applications have one and so do all the most successful user-generated content services. This is a one to one to many model: One datasource (Tweets), one API (Twitter’s), many consumers (the Tweeterati).
Now what if you want to provide some of your internal data as a service to some deserving third party? You’ll need to create an API. The reason you need to create a new API of your own is because your data appears to be different from that of another business – i.e. it’s organized and stored differently – even though it may be intrinsically the same kind of data (e.g. US_GAAP accounting data). Your API unlocks your specific set of data by providing a standard way to access and consume it.
But what if your data is in fact organized and stored in the same way as the same data being produced by lots of other companies? Say as XBRL instance documents subject to the US-GAAP taxonomy. What then?
Well now lots of companies can share one core API to share their data with each other and anyone else with a legitimate use for it. Let’s call it the SEC US-GAAP API ROUTER or SUGAR for short. For example, vanilla sugar (see how I did that?) is configured to allow access only to the XBRL data that comprises a standard public 10-Q/10-K filing. Why? So the S.E.C., and anyone else who wants to, can consume it directly from the horses mouth – literally whenever they want. Real intentional transparency in other words and no possibility that your data can get lost in translation somehow – e.g. lip my stockings as that nice Japanese lady so charmingly put it.
The S.E.C. and others can now ‘pull’ it from your XBRL repository with the help of a little sugar. That’s a many to one to many model. Many XBRL ‘provider’ repositories (i.e. businesses filing to the S.E.C. in XBRL now), one API (SUGAR), many ‘consumer’ applications (one of which is could be the S.E.C. itself).
Now what if you want to spread a little more of that sugar around or in different measures? Maybe to your business partners or specific stakeholder groups? Easy. You simply extend the core sugar API to reflect which other XBRL data you want to make available and to whom (using rules and roles – just like workflow) – to package it as a service in other words as caster sugar, brown sugar etc.
The RaaS model is a fundamentally different way of doing corporate reporting and one that literally turns the current S.E.C filing process on its head. And a key fact is it depends on the use of shared, agreed XBRL taxonomies and XBRL-enabled data repositories. Something that (ahem) we like to encourage here at Rivet.
Tags: S.E.C.
Pingback: Tweets that mention RaaS or a teaspoon of SUGAR…. | Rivet Software -- Topsy.com