The disciplines of Design Thinking and Enterprise Architecture come from different backgrounds, and at a first glance it might seem that there's not a whole lot that they have in common – but this is only because design thinking techniques have traditionally been used for individual products and services – at least, that's the context in which they are generally presented.
But if we think of an enterprise architecture program or a digital transformation initiative as delivering a product, if we think of them as delivering a service, it turns out that not only is there plenty of alignment, but that the techniques of design thinking align with traditional enterprise architecture activities and actually enhance them by offering new techniques to accomplish traditional goals.
So to conclude this series, let’s summarize our observations on the areas where the approaches and techniques associated with the different stages of design thinking can help with transformation initiatives. The high level summary is that, just as design thinking is about identifying products and services rather than implementing them, so where design thinking can help most is in the initial stages of defining what architectures, what top-level transformations, will help the organization.
The techniques of the empathize phase are where we can start to explore the immediate problems that the organization is facing and the goals that it has - since the goal of any enterprise architecture or transformation initiative should be to solve problems. An architect needs to have a rigorous mindset, but this very mindset can interfere with the ability to hold open discussions of the sort that can uncover unspoken problems.
Likewise, the techniques of the define stage of design thinking offer some extremely useful approaches to draw out the problems that stakeholders have and express them in a succinct form that enables validation and review – an audit trail of decisions.
The ideate stage of design thinking is the one that presents the most problems, but this is more because of the political environment that can exist. Specifically, the whole approach of ideation within design thinking is (deliberately) to generate the maximum number of ideas with no regard to practicability (feasibility is to be examined later). But this can often raise worries in the minds of technical stakeholders of being nailed to an impossible solution by business people who lack understanding of technology. So it’s important to set expectations that there is a filter stage at the end where suggestions, that for example violate the laws of physics, can be discarded.
In contrast, the prototype and test stages suggest a much better way to approach the presentation and proposal of the architecture vision itself. The key insight is that the point of prototyping as described by design thinking is not to produce a working version of the implementation, but to produce ‘something’ that lets consumers (stakeholders, in our terminology) imagine using the end product… and this enables us to test our understanding of the problem definition, and our solution.
It’s not always the case that two different disciplines have to complement one another – while an effort to look for synergies between different bodies of knowledge is never pointless, it’s not always the case that such synergies exist. Pleasingly however, it turns out that in this case the combination of design thinking techniques and enterprise architecture does have plenty to offer the latter – especially in defining the direction. In some ways, design thinking provides a superb complement to traditional enterprise architecture techniques, as it covers the initial part of the famous ‘squiggle’ created by Damien Newman while traditional techniques such as the TOGAF ADM are more focused on the output – the implementation.