So, in the second post in this series I talked about how the empathy stage of design thinking meshed acceptably but disappointingly with traditional enterprise architecture methodologies. Both approaches really focus on bringing out frustrations and unfulfilled needs, but at the same time they aren’t really in conflict because at this stage in the process they are both looking to accomplish the same goal – some kind of improvement in the organization that they are working with.
But disappointingly, at the same time, there’s not’s not a whole lot of synergy that can be found in this first intersection between the two disciplines. And while I can accept that this assertion is debatable, I will repeat that this disconnect is unavoidable because they aim at different targets.
More productively, in this week’s post, I’ll aim to consider what more actionable prescriptions might exist once we move on in the process and consider the possible crossovers between the define stage of enterprise architecture and design thinking.
So what is the key point around the design stage of the process: it’s to design a villain, a target – a focus for our thoughts and by extension our irritation and anger. Now, granted, this might seem surprising, but in practice this is one of the steps in the design thinking process that turns out to be the most useful.
To quote a definition of the define stage from the Stanford design school website:
“The goal of this mode is to come up with at least one actionable problem statement. This actionable problem statement (often referred to as Point of View (POV)) is the guiding statement that focuses on the insights that you uncovered from real users.”
Ah yes- the key word here. Actionable. It’s such an overlooked word, despite its existing importance in such widespread concepts such as the SMART approach (Specific, ACTIONABLE, Measureable, Reasonable, Time). But, ultimately, actionable is what executives look for. Because that’s really the only thing that they are there for. To put it more bluntly, one memorable executive that I worked with used to show his disappointment with any underperforming presentation with “So what? So why, if I’m a customer, would I continue to listen to this?”
So the value that the ‘define’ stage of design thinking brings to enterprise architecture is to provide ways to identify a specific problem that enterprise architecture is to solve. In other words, what is the itch that needs scratching for the executive suite – or, more often, what is the sore that needs a salve put on it?
A perfect example comes from an Open Group talk that I attended in 2012. There, the Chief Enterprise Architect of State Farm (a first tier insurer in the United States) described his problems in selling the idea of an Enterprise Architecture initiative to the board.
He referenced problems that had occurred in implementing payment holidays in the Louisiana region after the onset of Hurricane Katrina, back in 2006. To perhaps paraphrase his words, he said “Remember all those problems we had changing around systems after Katrina? The whole idea is to avoid having to do that next time!”
In other words, stakeholder support for any aspect of enterprise architecture requires support from those very stakeholders, which requires that they see solution to their concerns. So where the value from the define stage in the design thinking methodology comes from, is that it offers a perfect approach to specifically define the problems, or the concerns that the stakeholders have.