It's a great video which makes many good points, but it can lead one to thinking, "hang on, everything we do is basically case management - so why don't we just have one system to do that and simplify everything?".
Of course, "case management", like "booking" in Duncan's example, really covers a multitude of things, and it is often better for both the user and the deliverer of a service if the digital components that make it up are broken down to take account of context, rather than just abstracted up into neat architectural boxes.
I do believe though that there is value in this kind of thinking, but we just need to get our sense of perspective right at each stage. For the last year or so I have been noodling away at some thinking around the idea of service patterns, which FutureGov (sob) and Essex County Council
did some great work on back in the day.
Broadly speaking, I think it helps to have replicable chunks of both service design and technology to bring consistency to services, and reducing waste. However I think those chunks operate at different scales. In my (as always, half-baked at best)thinking, the nomenclature goes something like:
A need is the outcome that the user/citizen/customer/resident has - it might be very wide in scope
A step is a service design level pattern that can be used with others to build up to meeting that need. This might be 'booking' but also includes 'request', 'check', 'update', 'notify' and so on
A component is one of the bits of technology needed to achieve one of those steps. So for booking, you'd need a form of some sort, a resource database to track the bookable things and their availability, some means of contact management to track conversations about the booking, and so on.
So there's a piece of work I have unfinished in a Google Doc where I am describing the steps and the components and how they relate to one another, as a means of putting together a shared language between service design and digital delivery.
The next step would be to flesh out a new set of things - probably called 'patterns' where the way in which a step is completed can be - as much as possible - templated. So if we need to ask for an address, let's have a beautifully designed means of doing so we can just drop in when needed. Likewise for picking a date, or providing a date of birth, or uploading a file of some sort.
In other words, I don't think there's anything wrong at all with the idea of taking a component-based way of thinking about digital service delivery - but you do have to get your perspective right, and operate at the right levels of abstraction for things to make sense. Otherwise you might just end up claiming "it's all just text in boxes, isn't it?" and then walking into the sea.
