The fourth step in the traditional Stanford d-school process is 'prototype' – which is to say, create a prototype of the product or service being considered so that you can test it with potential consumers. Now, just as the rest of the steps in this design thinking process, it can seem incongruous to consider prototyping in the context of enterprise architecture and especially in enterprise transformation.
After all, a prototype might be completely trashed, and will almost certainly be reworked significantly. That's the whole idea of a prototype, to find out what doesn't work and make changes accordingly. Whereas enterprise transformation often requires enough commitment to make prototyping seem infeasible. For example, surely you can't prototype a new organizational structure; people tend not to like it when their jobs change multiple times in a short period. And while it's possible to pilot an Enterprise Service Bus, wouldn’t the investment involved in implementing one seem to conflict with the 'try it and get feedback' approach of prototyping?
It all comes down to the definition of what a prototype is. If you search for definitions of what a prototype is, then you get a large number of answers such as “an initial version of a product”, “a pre-production model of a product”, and “a replica of the product as it will be manufactured”. When aircraft manufacturers create prototypes, they are working, flying aircraft. So it's natural to think that a prototype has to be an operational implementation that closely matches the finished product. But this is not so, especially not with design thinking.
The word prototype comes from a Greek word meaning 'primitive form', which at first glance agrees with the implied definition given above. But to pose a question that I've often found useful – what's the point? Why are we even bothering to create a prototype? The answer is to test ideas. A 'primitive form' of an aircraft could be an artist's drawing of the aircraft – it's just that in terms of testing important questions like how it copes with trying to fly through the air, an artist's drawing is of limited use. It's a question of picking the right tool for the job, so a prototype only needs to have enough detail to test assumptions and gather data.
A great illustration of this comes from the story of the PalmPilot, one of the first ever handheld devices. In 2016, handheld computing is a given, with a range of best practices established, but back in the mid-nineties the concept of such a device was still new, and manifested in several high-profile failures, like the Apple Newton and Go – so designing such an untested concept without sinking large amounts of money into manufacturing was a problem. The solution was a block of wood. Specifically, the lead designer carved a block of wood to fit in his pocket, drew some buttons on it and pretended to use it as if it was a PDA/phone for a week.
The point being that this block-of-wood prototype was sufficient to answer important questions about how the device would perform, by allowing the typical user to imagine using the end product. More generally, UX designers use wireframes and service designers use storyboards with accompanying narratives as prototypes – the goal is simply to get feedback from potential users of the product or service. The key attribute of these wireframes or narrated storyboards being that they enable potential users to imagine themselves using the product or service, and then give useful feedback. I personally have been on a team ambushing random shoppers with a mounted storyboard to look for feedback on a product idea.
So, prototyping is not necessarily creating a working implementation – but what lessons does this offer for enterprise architecture? Well, first of all, you can prototype your enterprise architecture – you just have to produce something that communicates enough of it to test your assumptions. Now, if I were to play devil’s advocate, this idea means that you could count your stack of PowerPoint slides that are outlining your draft architecture as a prototype. Well done on creating a design thinking prototype with no extra effort!
Umm, no. Therein lies the second critical lesson that design thinking practices can teach enterprise architecture – the slides won’t elicit feedback, at least by themselves. Whatever is presented needs to enable the audience to imagine what their experience would be, while using whatever end result you are proposing. Now, the reality of corporate IT departments means that in practice this will often be a presentation. But it still doesn’t have to be yet another monotonous stack of PowerPoint slides.
Now, in theory a possible second lesson is that you could create a decent prototype by creating a stripped-down implementation in a test environment… but in practice I’m going to argue that an animated, narrated, even workshopped session is of far greater value. This is simply because, at the level that decisions are taken, the fact of whether or not a product ‘works’ can be taken for granted. The stakeholders will have their own experts to check this.
So, bowing to reality, it’ll be a presentation, and whatever presentation is given needs to involve the audience to the extent that they are emotionally involved in the journey enough that they will give feedback. The point is that the presentation needs to tell a story. It doesn’t have to be a set of PowerPoint slides – a skit is harder work, but might be more effective. More conventionally, even if a stack of PowerPoint slides is all that is allowed, these slides should at least convey a journey. There’s several ways to accomplish this – in this specific blog I’ve suggested Dan Roam’s ‘Show and Tell’ and Pixar’s story format as resources that can be drawn on.
So it turns out that there is a middle ground for architecture initiatives in prototyping, between the highly controlled arena of aerospace-style prototypes that cost tens of millions and the buccaneering design thinking world of approaching random consumers with storyboards in the street. A prototype tells a story to stakeholders. Just about the best sales rep I ever saw, once they turned CEO, was infamous for demanding a bottom line by asking “What’s the story?” In the same way, design thinking tells enterprise architects that when they come to propose their draft proposals that they need to know “What’s the story?”