by Jane McConnell
OSDU Management Committee Member / O&G Data Architect, Teradata
Or: How’s our communication going – in a community that has grown very quickly and now has over 1600 active OSDU Forum Members? (according to Slack)
Hello again. I hope you are well, in these weird times that we are living through. For me the days are beginning to blur a bit now – work, eat, work, walk, eat, sleep, repeat. I can vaguely remember what I said in my last blog. It was about this idea of 1% improvement ideas that could bring gains to your business, marginal or otherwise. I asked you to think about how you could use the OSDU™ Data Platform to make these sorts of improvements, and I promised I’d share some information on what is “on the backlog”, as we like to say, for further developments for the OSDU Data Platform after the Mercury Release (the thing that was previously referred to as R3) is out the door.
Before I do that though, I had a bit of a revelation the other day. There’s a teeny little chance that it might not be obvious to everyone exactly what it is we are building. And it might not be obvious why we are building it the way we are. Which might make it hard for people to think about how they can use what we will be shipping. Which in turn might make it hard for them to think about what else we might want to do next.
I had a friend whose brother was a really good artist, but with a weird approach to how he drew pictures. If he was making a drawing of a person, say, he would start in one corner and immediately put in the detail. He might start by drawing the shoelaces. Then he might add the shoe, and then a trouser leg. Or maybe he’d stop on that section and move over to drawing the detail of a building in the background. It left any observers a bit in the dark as to what the picture was going to turn out to be. ‘Can you see what it is yet?’, we would ask each other.
He could do that because he had the full picture mapped out in his (rather special) brain and his muscles knew how to translate that to paper, keeping everything in place and in scale. That’s a rare skill. I certainly can’t do that. Most of us need to start with a rough sketch of the “big picture” and then incrementally add detail.
So – the OSDU Data Platform – can you see what it is yet?
We all know where the Forum wants to go with the OSDU Data Platform in the broad-brush strokes sense. This is the vision and roadmap, which is now easily accessible on our website under OSDU MISSION/VISION. This is the frame for our picture, but mission and vision are by definition high-level.
In any software development project, the detail level is the code and the tests. At the end of the day, the code and tests represent the reality of how the system works, but the code is a little bit like the detailed drawing of shoelaces. You’d need to go through all of the code to understand the different jigsaw pieces of detail and then work out how they all fit together before you could determine what happens for any significant flow through the system. Who has that sort of time, even if they’re living under lockdown?
Which means there’s a gap between a broad-brush picture and a set of super-detailed pictures of things like shoelaces. How do you find out what the Mercury Release of the OSDU Data Platform will do for you, and how do you find out what the current thinking is for the next big release called Jupiter?
In the Enterprise Architecture (EA) subcommittee, we recently had a working session on the structure of the reference architecture document for the OSDU Data Platform Mercury Release. It turns out that when you are building a platform rather than an application, and when that platform has many extensibility points, a lot of what we traditionally think about as key functionality turns out to not belong in a formal reference architecture document at all. This additional functionality is implemented through configuration and components, which in documentation terms puts it in the implementation space. Which means the reference architecture alone won’t answer the question of what the system will do for you. Even if it did, it’s difficult to convince business types to read a document titled Reference Architecture…
The current document also had sections that are bigger than the reference architecture and bigger than the code, such as the data and system principles (which are really important as I mentioned in a previous blog), and sections on the context that the OSDU Data Platform will be used within. We decided to pull these out to form a new document which can have a wider audience than the reference architecture.
The new document (working title OSDU System Concept – we’ll try to do better) has a dual purpose:
- to provide Forum Members with an understanding of what the system will do for them, and
- to provide developers with the context and big picture about how the user expectations and how the data platform will be used
We have high hopes that this will be the place to go to learn what the OSDU Data Platform will do for you.
A happy by-product of creating this new document is that the technical standard will be able to refer to it, and therefore get to the meat of their subject earlier than chapter nine!
Stay tuned, as it will take us a few weeks to get this written, but I have a feeling this will help a little. I’m not saying we won’t still have gaps. Please do volunteer for the OSDU Documentation track if you want to help fill any other gaps.
With that out the way, it’s time to go back to what I said I would talk about, which is what other OSDU Forum Members are prioritising for post-Mercury Release functionality. Allow me to get on my hobby horse[1] and introduce you all to the Forum Shared Backlog.
This is the living documentation for things we want to do next, after we have shipped the Mercury Release.
The shared backlog is visible to all Members of the Forum. Any Member can add ideas for new developments or enhancements. We meet every two weeks on Tuesdays to discuss the items on the backlog with representatives from the PMC and the OSDU Forum subcommittees to determine how best to take these ideas forward. The meeting is open to the entire OSDU Forum, so anyone who is a Member can join, and if Members join our Slack channel 0_0_shared_backlog you will see what new ideas we plan to discuss at each meeting.
Currently on the backlog are some big-ticket items, which will be no surprise to anyone familiar with the OSDU Vision. These include adding production data capabilities, real-time data capabilities, and new energy solutions. These are currently in a scoping phase. There is an item around including completions data for unconventional wells, which may encompass both data definitions work and also architectural/code development around a consumption zone, an architectural component providing read access to a set of data to match a specific usage pattern to support analytics. And the new kid on the shared backlog block, called Consumption Zone – GIS canvas, is – you’ve guessed it – a proposal to build a consumption zone to provide improved support for a GIS canvas in applications.
Then the ‘What’s in it for me?’ question that I know you want to ask is ‘How can I get my ideas into the future development and priorities of OSDU Data Platform?’. Well, this will hopefully become clearer with the new document. There are many options. The OSDU Data Platform has many extension points for pluggable components that extend the platform capabilities, so application developers should be thinking of how they can hook in as pluggable components. Non-developers can work through the OSDU Forum with peers to detail out needed capabilities and then convince some developers to build your components. When it comes to developing the core services of the OSDU Data Platform further, well it is Open Source and we all know what that means.
Or do we?
Let’s discuss more about what that means next time. Until then, stay safe and stay sane!
[1] Hobby Horse: I don’t know how many languages this phrase works in – but I do know that it works in Norwegian. I had a conversation with a colleague the other day and they said “it’s one of those things of his, you know, when in a meeting he pulls out a horse’s head on a stick and goes round the room pretending to ride it”. In Norwegian they call it “kjepphest” – literally “stick horse”. Also, it turns out this phrase is actually the origins of the English word “hobby” as a favourite pursuit that you do in your spare time. Interesting, huh?
Coming from an IT background, Jane fell into Upstream Oil & Gas with its specific data management needs back in 2000, and has been consulting, developing product, and implementing solutions in this area since. She has done time at both Landmark and Schlumberger – in R&D, product management, consulting, and pre-sales – and in one role or another, she has influenced subsurface data management projects for most major oil companies across Europe. She chaired the Education Committee for the European oil industry data management group ECIM, and regularly presents at Oil Industry data management events. Along the way she’s learned enough about geophysics, geology, and the world of hydrocarbon exploration and production to be dangerous.
For the last 8 years has been working in Teradata, a big data and analytics company, in their Oil and Gas Practice. She is also serving on the OSDU Management Committee.
Jane is Scottish and has a stereotypical love of whisky (especially Islay malts). She knits and reads almost to obsession.
You can contact her at jane.mcconnell@teradata.com, on the OSDU Slack channels, or connect on LinkedIn.
