notebook checklist

Photo by Yleidis Maldonado on Unsplash

Why the digital twins project is publishing weeknotes

Thu Nov 7, 2019
$download_content = get_field('download_content');

Weeknotes: personal reflections from the ODI research team. Keeping you informed about our projects, research and decision-making processes. This week: our intentions for the weeknote format.

Weeknotes: personal reflections from the ODI research team. Keeping you informed about our projects, research and decision-making processes.

By Rachel Wilson, Senior Software Developer

Why a prototype and why the weeknote format?

The R&D team is researching ‘digital twins’ and how they might be connected together to create a ‘national digital twin’.

The usual ODI project method is to undertake a discovery phase of research; usually desk research and user interviews, followed by an ‘alpha phase’ in which we combine expert experience with our own theory of change to create outputs of practical benefit. Often this takes the form of a report with recommendations. Although not always: we’ve experimented with videos, speculative design and artwork, guidebooks and catalogues of design patterns.

We want to understand digital twins and how they might be connected to share data. So we considered two approaches. (1) Interview experts, combine their experience with our own to produce a report with recommendations for creators and users of connected digital twins (2) Build our own digital twins and experiment with ways to connect them. Capturing the reality and learnings of an iterative process seems well suited to a format like weeknotes.

There are a few reasons why we wanted to try something different in this case

  • Several members of the project team have a background in technical disciplines such as software engineering
  • Creating digital twins and integrating them is a technical process
  • The R&D team likes to research and experiment with formats and techniques as well as topics
  • The ODI wants to work in the open
  • It keeps things fresh for both our audience and the ODI team

Demonstrating an incremental and iterative approach

Most importantly (for me anyway, and I’ll be your host during this experiment) we want to demonstrate the value of prototyping as an approach that we hope digital twin integrators will consider: build a little, learn by doing, test ideas to learn more, and take those learnings into the next build phase.

We recognise a common tension in the approaches to building an national digital twin which is mirrored in the evolution of software engineering practices. One approach is to try and understand the entire landscape, to anticipate all needs and to attempt to produce something that works for everyone. Another approach is to let everyone start building and connecting twins, hoping that what emerges from the complexity is the best solution.

I have faith in the prototyping approach to reveal uncertainty and design tradeoffs that surface when we need to make decisions: about technology, about software architecture and approaches to sharing data. I hope weeknotes will be a good way to be open about the realities of the prototyping process which might serve as a reassuring guide to others of the benefits. I hope that showing our workings will be illuminating, authentic and useful to technical audiences.

On a more personal note

But, I also have worries.

What if we could gain the same insights by interviewing experts?
I suspect that building a prototype will surface the same insight we would gather by interviewing creators of digital twins. Building something however will give us some practical skills, and a much deeper understanding of the decisions and tradeoffs that are always made in engineering projects. We do plan to carry out such interviews in parallel, so I hope that we’ll be able to ask more directed questions having been through the experience of building something ourselves.

What if grappling with hardware / library dependencies is a time sink?
Anyone who has experimented with open source libraries or hardware will know what I mean. Things sometimes fail silently resulting in hours spent on StackOverflow. My approach will be to start small, keep the target in mind and think very carefully about what I’m really trying to demonstrate without getting too hung up on, say, a particular sensor. I only need to understand what each new component or interface contributes, it doesn’t have to be working perfectly (although that would be nice).

I am easily distracted by an interesting topic
The world of hardware and electronics is full of acronyms and interesting science, which appeals to my inner geek. I must try to stay in the shallows of the science if it doesn’t directly relate to my purpose.

How to bring people along with me?
I think this one will become clearer once I’ve started capturing my progress in weeknotes

So, welcome to my first ever weeknote…