It’s Monday evening in Copenhagen, and the challenge starts here: at Wind Europe 2023 we’ll be deploying a live data service. This article is for the first of our “Six Steps” — you can read the overview here.
This article is aimed at engineers, researchers and execs in the Wind Industry, to help understand the process of digitalisation. If you’re qualified in Systems Architecture or Data/Software Engineering, you’re way ahead of this; just get stuck in already!!
About the ‘Define’ step
Thinking of digitalisation as a wide-ranging and nebulous exercise is a trap: the sheer breadth of work, technologies and processes involved is overwhelming. The golden rule is to start small, with clear boundaries.
That doesn’t mean that a whole organisation can’t be working toward digitalisation at once; it’s just that each effort is extremely prone to failure (especially if it’s a large and complex one) —rather than risk it all, you sow many small seeds and see which ones take root.
Remember, the objective is to improve how effective you (or your team) are. It almost doesn’t matter where you start. Find a little problem that takes up some time…
Frustration is your best friend
If you’re frustrated with something during the work day, chances are that’s a good candidate. Especially if it’s something that keeps coming up (even if they doesn’t take much time, routine handle-turning tasks are a distraction). Here’s some examples:
- Logging onto a web portal and downloading data. You might prepare geospatial data for site assessment, but for each site you end up logging into the ESA web portal, downloading and stitching images together. Whenever a customer asks about a new site, you breathe a heavy sigh…
- Distributing data to more than one place in your organisation. You might get power curves in PDF form then enter values into your internal file format. Great, until colleagues start repeatedly asking for it; and each time you have a back-and forth about exactly which one they mean…
Leave the gnarliest problem for later
It’s best not to start with that one issue that’s super complex, requires dozens of stakeholders and is bugging the whole team. Chances are, if you work around the fringe of it you’ll start coming up with partial solutions that ease the way. You’ll also have more experience of what works and what doesn’t.
Once you’ve got a few simpler solutions under your belt, that’ll help draw a clear boundary around the really difficult one.
Check it’s valuable
Do not [repeat: DO NOT] get caught up with writing a business case, analysing accessible market sizes, competitor analyses and cost of services. All of these things are critical before launching a digital product, but that’s not what you’re doing. You’re planting a small seed.
By the time you’ve done all that stuff you could have built the thing already! The trick is to do the first couple of cycles around the “Six Steps” and then figure out, with your colleagues and industry partners, whether this deserves to be a full-blown product or service.
But, you should sanity-check up-front that what you’re thinking about is basically not a bad idea. Have a few conversations — phone relevant people up and ask “What if?”. Ask them how much time they spend doing a job, and how frequently they do it. Informal estimates aren’t super reliable, but they should be enough to give you a sense that something is worthwhile.
If you can save a team member half an hour every two weeks, you save about 1% of their time. If it’s a frustrating or boring job, that feels like much more!
Tiny time savings seem ridiculous, but add up a few of them and suddenly your team is much happier, quicker and more reliable.
Defining our problem for 72 hours at WindEurope
Our best friend: Frustration
At Octue, we’ve long been looking to help our customers improve their workflows around fetching geospatial data. We’ve done a bit ourselves to help out at times. The example above mentioned the sheer grind of fetching geospatial data by logging into a web portal, downloading images, stitching them together then re-cropping…
…and that’s before you even try to maintain correct metadata (like data sources/provenance). Don’t get us started.
Avoiding gnarly problems
Part of our vision is to help ‘data providers’ (organisations that generate measured or simulated geospatial data) give their users (like resource assessment engineers or operations planners) a really easy, intuitive and reliable way to fetch it. Handling aspects like authentication, permissions, metadata and integration of multiple private/public data stores is integral to that.
But that’s far too gnarly. It involves lots of stakeholders, lots of effort, lots of edge cases and a really broad problem statement. And frankly, more funding than we have.
Narrowing it down
Let’s follow our own advice: “Small and well-scoped”. What if we chose just one data source, from just one provider? If that were public data then we could do away with authentication and permissions.
Of course we want to maximise impact for the industry; so what’s the one data source, that’s public, that just about everyone in the industry uses at some stage?
Elevations data. Of course!
Surface elevations of the planet (and many other amazing data sets) are provided both by NASA’s Earthdata archive and by the European Space Agency (ESA), to the public, totally for free (requiring attribution, quite reasonably)! You can browse ESA’s entire catalogue here, but we’re all about the Copernicus Elevations Dataset:
Checking it’s valuable
We asked around a few Wind Engineers. Most were quite laid-back about the issue. As something that takes only a small fraction of your time, that’s quite understandable. We asked them to put a time on it, and got answers ranging between 15 and 45 minutes per site (that they prepared for very early stage assessment, so quite a few candidate sites). And they were preparing between 1 and 2 sites per fortnight.
So about 1% of their time. Not the biggest, most challenging part of the job, but not nothing — and quite impactful across the thousands of engineers globally.
That’s perfect. It seems really tiny, but in a few weeks of work, we can make every Wind Engineer in the world 1% more effective. Done alongside many other such exercises with similar impact, we can easily double the effectiveness of our workforce over the next couple of years.
Wrapping up
So we have our use case definition:
We’re going to provide a solution that makes it easy and quick for anyone to access elevations data.
Let’s be a bit more specific:
- In the Wind Industry there’s a drive for better visualisation, mapping and planning/optimisation tools. Being able to integrate directly into those would get us an A+ on the report card, although doing those integrations is out of scope here.
- Being able to clearly demonstrate that we’d massively sped up the process is a clear metric for success.
- Part of the pain is ensuring that there’s data available in a particular location, or stitching data when the desired location is near a boundary. So this should work anywhere in the world straightforwardly.
- A point elevation is useful to some extent, but generally if we’re doing resource assessment or planning a wind farm installation, we need to get data for an area, not just a point.
- To be useful in design tools (eg when panning a map in a web application or investigating site potential globally), fetching data must be quick (“quasi real time” — fast enough not to really notice it).
- With 10s lag, user interfaces start to feel very slow, but sub-second performance is likely unnecessary. Ballparking a requirement, we should fetch data with <3s round trip time.
And that’s our ‘Define’ step finished! I’ll drop back and add a link when the next step is published, but in the meantime you can follow along on LinkedIn — it’ll be great to see you!
