In Microsoft’s latest whitepaper, ‘Microsoft Upstream Reference Architecture, looking back on 2011 and forward to 2012’ we are offered a refresher of what a reference architecture is as follows... ‘a reference architecture is an architecture that identifies elements generically in the context of a generic system […] used to develop specific architectures that conform to the reference architecture by constraining the reference architecture to the unique characteristics of specific systems, which are specializations of the original generic system.’
For those who are still scratching their heads, ‘Looking Back’ uses the analogy of a railroad system (a rather anachronistic choice for IT?), explaining at length ‘how interconnection between systems with different rail gauges used variable gauge rail cars, replacing rail car wheels and axles, using adapter flatcars, or simply transferred the passengers or freight.’
We have here a great example of a common trait in technical literature. You are reading along happily—say about black holes, quantum mechanics or indeed a ‘reference architecture.’ Things are getting interesting. Your curiosity is reaching a state of heightened arousal. You are about to understand something that was previously obscure. Maybe you will even be able to hold forth at the next dinner party on the curvature of space, particle duality or what have you.
But just as you get to the interesting bit, when all will revealed, the author changes tack with, da da! the completely useless analogy. Instead of telling you how the universe was created, the author begins a laborious explanation of something blindingly obvious.
Several explanations for this come to mind. We may have a savvy author who invokes an accurate analogy that the dumb reader fails to grasp. As this possibility is not very flattering, I will dismiss it out of hand. (Gee it’s good to be an editor!)
We can also envisage the case where the author has a good grasp of the subject at hand, but whose capacity to translate it into a suitable analogy is poor.
Alternatively, it could be that the analogy is as hard to grasp as the original subject. This is a particularly pernicious turn of events for the reader as he or she now has two hard-to-grasp concepts to puzzle over instead of one.
Other possibilities are a) that the author does not really understand the subject matter and explains instead an analogy that he or she is more comfortable with or b) that the subject itself does not really make any sense. Hence the need to explain an analogy that does.
I submit that MURA falls into the latest category—that it does not make any sense beyond the statement that involvement in MURA equates to the use of any Microsoft product—especially SharePoint. In fact this is made a lot clearer on the Microsoft oil and gas website where the products in the MURA ‘solution’ are enumerated as follows ... Microsoft SQL Server, SharePoint, Project, Office, Silverlight, Visual Studio, Windows 7, ASP.NET, BizTalk and .NET. That is pretty well the whole shebang and most IT departments likely spend a good part of their waking hours trying to get these components to interact already, without even thinking of oil and gas specifics.
But there is another side to this. How can it be that Microsoft thinks it can get away with publishing such a lot of drivel masquerading as ‘technical’ information?
IT has done a great job over the years of carving out a space for itself apart from the real world of either science or business. It wasn’t meant to be like this. Early computer languages like Fortan and Cobol were (and actually still are) close to their domains and use terminology that their user/developers understood. There was no need to ‘explain’ a program with an analogy—it was all in the code.
Some 30 years ago or so, there was a feeling that such a move would continue with the arrival of ‘fourth generation languages’ which would enable programs to be written in even more general natural language. But what actually happened was the opposite. IT got the abstraction religion and saw no need to have code that was tied in any way to a silly old ‘domain.’ This has led to the big divide between users and coders and has led to a vast amount of pretty impenetrable computer literature.
I am always surprised to hear from folks in the ‘digital oilfield/intelligent energy’ space talk of the ‘IT department’ as something different from their own activity. You want to hook up some real time production data with pricing information from the ERP system? The digital oilfield folks do the design and specs, but the donkey work, which involves black arts of database wizardry, objet relation mapping, reformatting—all that is up to ‘IT.’
The irony in all this is that probably the closest thing we have got today to a fourth generation language is the facility that a generic tool—like Microsoft’s SharePoint—offers to the end user. This exposes a whole host of information in the form of drop down lists and ‘web parts’ that users can customize into an application without writing code. OK—you may have to roll up your sleeves and delve into some Visual Basic to do the extra smarts. And OK again—the end result may or may not actually work ‘at scale’ as folks like to say.
What to make of all this? On the one hand, listing your software line up does not make a framework. This would involve quite a lot of plumbing that MURA has as yet failed to publish. In our 2009 interview with Microsoft’s Paul Nguyen and Ali Ferling, one stated aim was ‘freely available documentation and working code samples’ as in the Microsoft Manufacturing Toolkit.
I guess that the proof of the pudding will be whether the GEF eventually becomes the MURA User Group or, and this is my bet, the SharePoint Oil and Gas User Group. Time will tell.
© Oil IT Journal - all rights reserved.