On digitizing hydrogen and ‘agile’ software development

Shell plans to leverage a technology stack from OSDU, the Open Subsurface Data Universe to develop a digital backbone for its hydrogen filling stations. Oil IT Journal editor Neil McNaughton tries to figure out why.

In our lead this month you can read how Shell is tooling-up its IT to supply a growing network of hydrogen filling stations in the US and EU. Given that retailing hydrogen would not, on the face of it, be all that different from retailing gasoline, you might have imagined that Shell would have bags of IT ready to roll for the new fuel. This may be the case, but it was not quite how Shell’s Richard Zhang presented it at the online 2020 Energistics/Energy Conference Network Summer Digitalization Summit. For hydrogen, Shell is developing a ‘first of a kind’ digital backbone for its fueling stations.

I guess the new fuel represents a great opportunity for new, state-of-the-art IT. But what is state-of-the art IT today? The current issue of Oil IT Journal contains quite a bit of converging evidence on this which I am going to try and tie together here.

My first witness is Zang himself who provided some clear pointers as to what ‘first of a kind’ means. Shell’s Hydrogen Digital Platform will, ‘re-use the platform developed for Shell’s Open Subsurface Data Universe’s infrastructure, OSDU’. I was quite surprised to read this. OSDU, as it says on the can, concerns the subsurface. Moreover, it would appear that, at least in its current manifestation, to be principally a mechanism by which third parties can access Schlumberger’s geoscience data environment which has been graciously contributed to the initiative. What does any of that have to do with hydrogen and retail?

To understand why OSDU has achieved such prominence chez Shell’s developers, you might like to read another piece in this issue, our review of a recent IBM Redbook titled ‘Accelerating Modernization with Agile Integration’. AMAI is a 650-page treatise on current thinking in software development which echoes many of the concepts that lie behind OSDU: Cloud, microservices and open source, inter alia. Further evidence of the linkage between ‘agile’ and OSDU is evidenced in IBM’s ‘own-brand’ OSDU, ODUA, the Open Data Universe Anywhere – which we also cover in this issue.

In AMAI, IBM warns that ‘The [agile] approach is complex. In many cases, existing enterprise solutions can and should continue running with a more traditional architecture … for suitably selected new solutions or for pockets of modernization within existing systems, microservices can provide an order of magnitude increase in benefits that are hard to achieve any other way’.

This raises an interesting issue for the upstream. What ‘existing enterprise solutions’ should be running on a traditional architecture and what kind of developments are more amenable to an agile approach. To take a specific example, consider Schlumberger’s Petrel running on a local workstation with massive local memory and superfast disk space. Could this be ‘lifted and shifted’ to the cloud? What would the performance be like? Or could it be broken up into myriad microservices? How long would that take? How hard is all this stuff?

It would seem that the commonality between OSDU and hydrogen retailing has nothing to do with either the subsurface or retail. Which leaves us with the pure IT of what is loosely referred to as the digital transformation. All that Kubernetes, Docker, provisioning, microservices and communications stuff and some more. At one juncture, AMAI harks back to earlier SOA initiatives which failed, inter alia because of the ‘use of integration specialists with poor knowledge of the applications’. I’m not sure that the injection of the rather thick layer of competencies that the new agile implies is going to help application developers with good domain knowledge very much. I’m not saying that a geophysicist is not capable of writing code in the new vernacular of the cloud. But it does seem likely that the new IT will involve quite a few with less knowledge of the application domain and more knowledge of the arcane world of the cloud.

Speaking of arcane, an AWS blog on natural language processing (see our cheeky summary in this issue) reminded me of my 2017 visit to an AWS day when I came away with more random arcane knowledge than I really needed. The amount of arcana that seems to be required to do even a simple task in the cloud beggars belief. What happened to the old Unix ethos of designing a tool to do one thing and do it well? We have come a long way from a programming environment that puts domain-specific tools in domain specialists’ hands. OTOH, if you are a cloud provider looking to assure a degree of customer fidelity (i.e. lock-in), the more arcane the better!

Writing in the Financial Times Richard Waters reported on Nvidia’s anticipated rise to data center pre-eminence with a mooted acquisition of ARM. Waters cited the company’s founder and CEO Jensen Huang as saying, ‘Data centers are the new computing unit. Rather than write programs that run on a single processor or server, coders will write software to run on an entire data center: what happens behind the scenes, as data shifts between machines, and internet services are provided in the most efficient way, will be the concern of a company such as Nvidia, not the programmer’. For an industry that has thrived on complexity that is unlikely to come to pass. But the sentiment is good.

Click here to comment on this article

Click here to view this article in context on a desktop

© Oil IT Journal - all rights reserved.