In my previous post I outlined some background on design thinking and in particular described the five steps of the most familiar design thinking process that exists, that being the empathize-define-ideate-prototype-test approach that has come out of the Stanford University design school, or “d-school”. In this post I’ll consider the empathize step in the process, and how it might help the discipline of enterprise architecture.
What is empathy? Well, let’s do the obvious - start with Wikipedia. “Empathy is the capacity to understand or feel what another person is experiencing from within the other being's frame of reference, i.e., the capacity to place oneself in another's position.” Now, this might sound vaguely familiar to people with experience of enterprise architecture frameworks. And this is no accident. Because at the heart of the empathize step in design thinking is the recognition that other communities will have different drivers, different needs and different ways of perceiving a situation than the design thinking practitioner.
The analogous concept in Enterprise Architecture is viewpoints – the acceptance that different groups may see a situation from different perspectives. However, there is a key difference between the two – the communities that empathy and viewpoints address. A viewpoint is a perspective on a formal model, designed to be consumed by people who can work with formal models
So – empathy, and the empathize step, is about different perspectives just like the concept of viewpoints, but in a much more freeform way than viewpoints are. To reference the famous squiggle diagram from Damien Newman, empathy belongs in the messy area all the way on the left. Does this mean that it’s out of scope for Enterprise Architecture? For formal modeling, yes, but not for Enterprise Architecture.
Squiggle Diagram, Damien Newman
The value that design thinking adds is precisely that it comes from the left side of the ‘squiggle’, meaning that while EA (and, let’s accept the presence of the elephant in the room, TOGAF), tends to take the goal as given and focuses on delivery, defining the problem to be solved is more than half the battle. So the empathize step in design thinking provides value in the initial talks with business people to define what exactly the transformation that EA achieves, should be.
And here is where the work that has been done in design thinking, and in particular for the empathize step, really comes to the fore in assisting an Enterprise Architecture initiative – in drawing out from the left side of the squiggle, in defining the problem to be addressed. In other words, what would we even feed into this marvelous sausage machine that TOGAF calls the ADM? This is where design thinking can start to help us.
There are several techniques offered in order to accomplish the empathize stage by design thinking methodologies, and they all apply well to a business situation. The empathize step is really about trying to gain insight into the other party and what they need, so the focus is on questioning techniques in an unstructured environment. A common technique is the ‘why’ interview, as explaining in this publicly available handout from the Stanford d-school. But there are others. Empathy maps are a familiar tool for design thinking practitioners, as are others such as journey maps.
Whichever technique from the suite of empathize techniques that are proposed by the design thinking literature that exists, all have value in identifying the problems that the organization’s executives face.
So the conclusion is that design thinking has a natural synergy with enterprise architecture, at least in the initial stages, because while most enterprise architecture frameworks concentrate on implementation, they take the decisions on the high-level strategy for granted. Design Thinking is invaluable in kick starting that part of the process, and using design thinking to engage, via ‘empathizing’ with the C-suite and other key stakeholders is the first step in the overall process.