Back in the 1980s, when the VisiCalc spreadsheet program launched on the Apple computer, it was the first real instance of a "Killer App". The Wikipedia article is informative and entertaining reading. The spreadsheet is such a killer app that it is arguably the single most critical piece of the enterprise IT infrastructure even today. Your organisation will survive ERP failure, e-mail downtime, ECM trouble, but not spreadsheet extinction.
Why is this? For a set of related reasons. first of all, your enterprise systems are terrible in the sense that they inevitably do not comprehensively address the users' needs and when they do, they will often do so badly. In this article, this is dogma; we can dissect this assertion another time, but it's something we know instinctively is true. The circumstantial evidence lies in the enterprise's hidden application portfolio, which the CIO either doesn't know of or is unable to address: the pervasive and omnipresent undergrowth of custom purpose spreadsheets.
The spreadsheet which is used to track the application portfolio. The spreadsheet which is used to categorise and segment contracts. The spreadsheet listing which clients are overdue. The spreadsheet listing job candidates according to criteria the shiny expensive SAP HR system can't process. Spreadsheets are everywhere, and they are very local to the processes they support, therefore they are very high quality data model representations of the organisation's real needs.
I have always advocated an inclusive attitude towards these spreadsheets. They can and should be considered high fidelity prototypes filling in the gaps in the formal enterprise application portfolio. Of course, this comes at a price.
Spreadsheets should be considered prototypes; meaning, we need to seek them out and fold their use cases and data models into our formal application portfolio by modeling them in more sustainable and communal systems. When spreadsheets transition from prototype to becoming actual longer term parts of the organisation's operational capabilities, it leads to "ODBC Ghettoisation"; a parallel unintegrated black market of information.
And now we come to the reason I am writing this article: for the community of digital forward thinkers who have adopted an ultra-agile approach to information modeling by implementing Semantic MediaWiki, the power of spreadsheets is now no longer excluded from the broader and more formal enterprise data model.
In Semantic MediaWiki, we will soon be able to have our cake, and eat it too.
On Open Source
With generous financing from Ballerup Municipality, an extension to Semantic MediaWiki is being developed (by this brilliant gentleman) which provides in-wiki spreadsheets, with rows corresponding to wiki pages and columns corresponding to semantic properties (roughly analogous to rows and columns in the relational data model).
This development pleases me immensely because it is beautiful from many perspectives. The functional potential unlocked by an in-wiki spreadsheet is honestly transformative. Semantic MediaWiki is already a groundbreaking tool for decentralising constructive data modeling and maintenance; the availability of spreadsheet-style interfaces allows users to reuse the finely honed spreadsheet data modeling and tool creating skills in a system which understands how to absorb and rationalise unstructured as well as structured data.
The feature is being developed in the only correct open source way I know of; by going upstream. We are not weilding a seven digit budget to make this happen, we are not building a big behemoth of a system. The direction of the financing is laser guided at the exact right parties. The contract isn't a million pages long. The feature being financed isn't just useful to us, it's useful to everyone. In the global MediaWiki community, not just in Denmark.
You know you're doing open source right when, by giving back, you're also giving yourself something great.
We can have our cake and we can eat it too, but it's an post-scarcity open source cake so there's enough for you also.