Design Thinking Entrée, with Blair Loveday, et al (#ITEA 2017)

Coming out of the ITEA conference, I referred to three magical signs that (IT) architecture is going through a positive transformation; #3 was around design thinking, a topic that a number of speakers covered in varying depth.  Amongst those was the heretic Blair Loveday; I mean sheesh, the guy’s a BA Chief Culture Officer, what blasphemy is this, him presenting at an architect conference?

Blair and the others spoke enough about design thinking to wet our appetites, but not nearly enough to constitute a meal; so, based on what I got from the conference and after some digging of my own, here’s my quick overview of design thinking – a sort of entrée to get you started.

In a Nutshell

I’m conscious that I’m partially trying to appeal to IT architects, let me do so by using the term ‘scientific method’, because it’s going to get a bit touchy-feely later on.

According to wikipedia, Design Thinking is comparable to the scientific method (feedback is obtained by collecting observational evidence and measurable facts) but with the addition of also considering the human aspect, or emotional state.  The inclusion of the human dimension is a key theme that you’ll find throughout design thinking literature.  For example, use of empathy is one of the specific techniques suggested for during the ‘learn from people’ phase.

The Three Lenses

One of the concepts Blair used to describe design thinking was a “the three “lenses” that you’ll see repeated in design thinking literature: desirability, feasibility and viability.

Blair respectively described these people, business and technology lenses, and then talked about then in the context of innovation – by type, depending on which lenses overlapped.  The central overlap of all three was “Experience Innovation”, which sounds fine but with all due respect is just a smidge too touchy-feely, even for me, on Monday – but that doesn’t matter.

Design thinking, according to Blair, is centered on the people / desirability lense – which is in keeping with Wikipedia’s view vis-à-vis the scientific method.  You’ll notice that this puts emphasis on emotional and functional innovation.

The thing I really like about this model is that it’s simple yet useful, calls out the human part (which is pretty essential) and provides one of several good anchors to understanding design thinking: making stuff that “is cool” or “just works”, for people.

Getting to Grips: Four Into One

Trying to understand design thinking by reading about it online is a little like talking to people who witnessed a traffic collision: everyone’s got a slightly different view.  Given how long design thinking has been around that’s probably not surprising.  I found a number of approaches.  What I’ve done below is to try and distil the main phases from the 4 interpretations that I studied:

The colour groupings are my own, looking for commonality across the different approaches, and are only indicative.  The four approaches are based on (from top to bottom): Design thinking example video (wikipedia), IDEO, Stanford University’s ‘Taking design thinking to schools initiative’ (wikipedia), and ‘A Framework for Design Thinking’ (Creativity at work).  Links to these references are below.

The third process, from Stanford, is the one Nick Malik referred to in his talk at ITEA 2017.

Chris Tuohy’s talk on experience’s at Westpac also touched on design thinking.  The Westpac approach has seven phases (not including an 8th step which seems to be a decision point at which the prototyped ideas are passed into a delivery-focused design and build lifecycle.  Unsurprisingly, these seven phases are all in common with those suggested by the 4 approaches above.

Distilled Comprehension: One from Four

Here’s my general take on what things a reasonable design thinking process should include:

1. Learn from people: 
   1. IDEO seem to refer to this as “Insights”, observation, learning from extremes, interviews, immersion and empathy, and doing this all through the three lenses.
   2. Getting an idea of people’s motivations, habits and delights is a good place to start.
   3. A concept I came across more than once was the idea that people on the extremes (think bell curve) are good at helping to explain ideas that the mainstream are less able to articulate.
2. Find patterns:
   1. Look at what you’re learned, try and make sense of it.
   2. Look for themes, apply intuition.
   3. Put yourself in the shoes of the users, leverage empathy.
   4. Distil design principles.  For example ask the “how might we” question: if a design principle or theme says “x” ask how you might turn that into a specific idea or prototype (and remember the three lenses).
3. Generate ideas: 
   1. Don’t prequalify ideas out, just generate them.
   2. As IDEO say, “Push past the obvious”.
   3. The emphasis is on creativity.  Basically this is the divergent thinking (creating choices) phase.
4. Make tangible, prototype and test: 
   1. This is the complementary convergent thinking phase (making choices).
   2. Make things tangible and real through prototyping.  Use any method you like, but make sure it’s using something that will resonate with your audience.
   3. Refine and improve.

Some of the descriptions include steps that come after what I would consider to be the core of design thinking (e.g. delivery).  I don’t think that’s necessarily bad.

You could say these were “steps”, implying a formal process; obviously you want to take time to understand before you race off and prototype stuff, but to put constraints that are too formal on the approach would do it a disservice.  For example, the phase of generating ideas and prototyping them could (and even should) be an iterative process.  After all: how many iterations = how long is a piece of string.

Finally, I got hold of Peter G. Rowe’s book “Design Thinking” from the Wellington public library; I haven’t made serious in-roads yet, but it looks interesting.  One of the things about it I am keen to explore the author’s views it given he’s coming from the perspective of a “real” architect (i.e. buildings, not IT).

Further online reading and viewing:

• Wikipedia – check out the example video, it’s a really nice little summary.
• IDEO – some useful content for sure, but not a lot of it (unless I did a “man-look”).
• Creativity at Work

Advertisement

WSAF Micro-Unconference on the “brand” of architects + Digital + design-thinking, etc

Okay, so over at the WSAF’s regular coffee meet-up we (again) blundered into the “What the hell do we do again, and doesn’t everyone love us?” topic.  Rather than have a good short chat about it over coffee, some bright spark suggested we have a slightly longer great conversation about it with alcohol.

I posted notice of this impending unconference both on the WSAF’s linkedIn group – which you’re all most welcome to join (here) and on our meet-up group (here).

The date and time of the unconference is TBC, but it will almost certainly be on a Friday, very probably starting at 3pm, and go until 5-6pm-ish.  The venue will be the offices of Middleware New Zealand.  Date – likely to be one of the following (we’ll confirm soon): Sept 1st, 8th or 15th.

To start framing up the conversation I put this together (see diagram below).

Goal of the unconference

Apart from the usual highly desireable secondary benefits (i.e. drinking responsibly with like minded peers) the goal is to start identifying some specific things we can do to start actively transforming architecture so that we can keep doing rewarding work, and our stakeholders get consistent value of our involvement.

#ArchitectureInTransformation

3 Ideas from Nick Malik on Design Thinking (#ITEA 2017)

Following the 2017 ITEA conference, I recently reiterated what many of us have known for a while: that traditional architecture and architects are endangered.  I also promised to share some of the great ideas from that conference – practical concepts that you can use right now, and which started to demonstrate how architects can still be relevant and add value.

I’d like to start with ideas from a really valuable talk given by Nick Malik, a 37 year industry veteran who describes himself as a “Vanguard Enterprise Architect, Digital Transformation Strategist, Author, Blogger, and General Troublemaker”, currently Senior “Principal Consultant – Enterprise Architecture” with Infosys.

The subject of Nick’s talk was “Using Design Thinking to Develop your Enterprise Architecture Core Diagram“.  In this post I’ll briefly introduce this key concept as well as some of the other ideas that I wrote down during Nicks talk.

#1 – Actually Understand the problem

The first thing I wrote down was incredibly obvious and shouldn’t need reiteration: taking sufficient time to actually understand the problem.  Nick emphasised bringing people into this process – actually talking to people to really understand what they need, so that we “build solutions that people want to use”.

The quote that came to mind during this bit of the presentation was Eisenhower’s “Plans are nothing, planning is everything.”  Why did I think that?  Well, some people will equate “understanding the problem” with analysis and documentation, where the scale of the analysis and documentation corresponds to the perceived scale and complexity of the problem.

But that’s not what was meant – it’s more around the quality of the discussion, and ensuring that there is real understanding of what the problem is, and what is needed.

In my view, the challenge here for some people (and architects) is that doing this well requires quality interpersonal engagement.  I wonder how often we end-up with solutions that are system-centric rather than people-centric?  I suspect it’s partly due to that fact that some of this stuff is hard – it’s easy to let the technology control you.  But I also think there’s another aspect to it – that some people who are good with systems & tech aren’t always as confident with people, and so the people-centric part loses out.

Interestingly, the design thinking page on wikipedia contrasts design thinking with the scientific method; whilst both approaches use iteration, design thinking consciously “considers the consumer’s emotional state”.  Having quality discussions with people doesn’t necessarily equate to discussing emotional state, but even so, I think that the organic relationship between these concepts is apparent, as is their relevance to arriving at better and more holistic solutions.

So, focus more on having quality engagement with people and taking the time to understand.

#2 – The Core Diagram and Design Thinking

The heart of Nick’s talk was the Core Diagram, and using Design Thinking as a way to developing it.  The crucial idea I took from this was connecting the existing and accepted (although possibly under-utilized) architectural concept (the core diagram) with the “modern” technique (design thinking) which has become somewhat hijacked by a market that is “going digital”.

I say “modern” with the slightly sarcastic quote marks because the roots of design thinking actually go back a long way before it became vogue in the current “digital” era. That said, “digital” is relevant to architects because it’s the current language of business, and those not conversant in it risk being marginalised, regardless of what people think digital means.

Before I go too much further I just want to point out that I am new to the concept of the core diagram – at least regarding the specifics of the concept as Nick describes it.  My goal here is simply to help spread the word on this as a idea, because I think it has value.

Nick has been writing about core diagrams for some time (circa 2012), and I wonder how much the approach to developing them have changed?  I haven’t yet properly read and digested the original approach, but it’s now 2017 and Nick is connecting the development of core diagrams with design thinking – I’m not sure whether this represents a fundamental shift in the approach, or a natural evolution that recognizes shared principles that were always inherently there.

The reason I mention this is that if you go searching online you’re going to find articles from a few years ago (c’mon, 2012 isn’t that long ago) , and you might (incorrectly) feel compelled to dismiss them out-of-hand as not being contemporary and not solidly connected to “design thinking” as is currently vogue.

So, what’s a core diagram?

As with a lot of good ideas the key concept is relatively simple, according to Jeanne Ross (Director, MIT CISR):

“For most companies, I think some kind of picture is essential for understanding the expectations for a business transformation.”

The bold is mine.  Nick included this quote in his deck – having taken it from an email Jeanne sent him in 2011.  Nick described it as “the best advice we all ignored”.

Actually Nick, I think I might have a tongue-in-cheek explanation for that – there’s currently no wikipedia page for Core Diagram 😛

Jeanne describes it as:

“a simple one-page view of the processes, data, and technologies constituting the desired foundation for execution.”

One-page is key.  What you’re after is something that everyone wants to put up on the wall, in their office or the teams shared space.  You want it to support a wide range of discussions and thinking across all your stakeholders – especially those who are responsible for, or have a lot of influence over, the end result.

Here’s some links for you:

• “Enterprise Architecture As Strategy” by Jeanne W. Ross, Peter Weill and David Robertson, on Amazon.
• “What is a core diagram?” MSDN blog post by Nick Malik, 2012.
• (Slides from) Open Group Presentation on MSBI method of creating Enterprise Architecture Core Diagrams on slideShare, 2012.

A Brief aside info Marketecture

As Nick was describing the core diagram I couldn’t help but mentally connect it with Marketecture and effective marketecture diagrams.  In Nick’s view they aren’t the same thing, and I can see why he says that – but it’s subtle, multi-dimensional, and I’m still thinking about it.

I’ve previously found a number of useful definitions that help capture what I think marketecture is (which I sketch out in “Appendix: The Mysteries of Marketecture” in this post).  In summary it’s:

a business perspective, including concepts such as licensing, the business model and technical details relevant to the customer; it can also serve as an informal depiction of the systems structure, interactions and relationships that espouse the philosophy behind the architecture.

We had a very brief discussion whilst walking out at the break, Nick’s view was (and assuming my recall is accurate) that marketecture is designed to assist the “sale” of the solution, with the underlying implication that relates to the “transactional” nature of the sale; where as “you can take a core diagram to governance meetings”.

I guess it depends on what is meant by “sale” – there’s the commercial sense i.e. trying to sell faster processors to end users, but there’s also the idea of “selling” a solution as being viable to executives and governance bodies.  From a philosophical stand-point I think good marketecture and core diagrams have that in common.  There’s no doubt a lot more to explore here.

 

#3 – Ideation Techniques

Design thinking, and the concept of rapidly coming up with ideas deserves more time and space than I can give it here, so to get you started, let me just give you a couple of the ideas Nick shared:

• Reverse Brainstorming – Instead of asking, “How do I prevent this problem?” ask, “How could I cause the problem?”  The idea is that by initially focusing more on the problem you’re then better equipped to start considering solutions.  It reminds me of the 37 Signals piece called “Have an Enemy”: “Sometimes the best way to know what your app should be is to know what it shouldn’t be. Figure out your app’s enemy and you’ll shine a light on where you need to go.“
• SCAMPER – an acronym of activity based thinking process which help you think out of the box: Substitute, Combine, and so on.  It’s been around since 1953.

 

#ArchitectureInTransformation

Is the Tide Turning? #ArchitectureInTransformation

Good news, I think, from the 2017 IT & Enterprise Architecture Conference, which I attended earlier this week.  As is well known, “Traditional” architecture, and Enterprise Architecture in general, has been on the endangered list for a while now – but I’m starting to see really positive signs that (some) architects are bouncing back and starting to successfully adapt.

In due course, I’ll share some of the many notes and great ideas I captured during the event, but before I do I just wanted to quickly preface the whole thing with this overarching theme (that architects are starting to adapt) – because it was a theme that permeated much of the conferences content – and from what I could see these ideas were generally being embraced by the attendees – but it’s still very early days…

So what are these magical signs?

#1 – Attitudes

It was clear from the architects I spoke with that they recognised the need to adapt, have a positive attitude about doing so, and are on that journey.

#2 – Platform as a Product

One of the clearest signals was from Mike Nooney, who shared with us how Air New Zealand are developing their platform strategy.  A key takeaway here was “platform as product”, in other words, start thinking about your organisations platform and systems as a product (and everything that mental-model entails).

Of course it’s a non-trivial exercise – there’s lots of deep and subtle implications in the statement.  I’ll be looking into this more (a lot more, I’m sure), but for now I suggest you start by thinking about what good products are and how they come into being – i.e. “it’s not just about technology”; thinking about the entire ecosystem: end-users, API-users, support, marketing (and so on); and how you’d actually work with the other human beings across that entire ecosystem to make it happen.

It’s worth noting that there’s a spectrum here; in some circumstances you might simply get away with (or start with) a simply terminology change: “(Digital) Platform” instead of “EA”, although obviously a deeper change is likely to be needed at some point.

#3 – Embracing ‘new’ techniques, such as Design Thinking

Design thinking is one of several approaches that have been gaining serious traction in recent years.  Sure, some of the core concepts inside some of these approaches are not necessarily new, but they’ve reached a level of maturity and market presence that means ignoring them isn’t wise.

There’s this fuzzy nexus of concepts – Digital is one, taking a (platform as) product centric view is another – think of it as the new/emerging paradigm for how the mainstream now conceptualises systems.  Design thinking, and related approaches, are a part of that paradigm.

The good news for architects is that, as mentioned above, the core stuff inside these approaches isn’t necessarily new – it’s stuff that as architects we kinda mentally do already, so the leap isn’t as big as it looks.

Positive evidence of architects taking this sort of approach on was visible in several presentations beyond Mike’s:

1. Nick Malik emphasised the importance of gaining a deep understanding of the problem, and whilst he didn’t refer to design thinking directly I found it to be a pretty easy mental leap from his advice to leveraging design thinking as one of the ways of getting there.  Update – as per Nick’s comment below, design thinking was a focus of his talk – my memory here isn’t quite as accurate as I’d like it to be (thanks for correcting me).  I’ll share more on this in due course, including links to where you can get Nick’s thoughts first hand.
2. Nick also made reference to several books including “Stories that Move Mountains: Storytelling and Visual Design for Persuasive Presentations” – and whilst this isn’t billed as “design thinking”, (as a newbie) I can see some parallels.
3. Blair Loveday did a whole session on design thinking – the fact that this even happened is itself an indication of how things are moving in architecture circles.
4. Chris Tuohy spoke about his experiences with Agile and culture change at Westpac – design thinking was explicitly called out as being part of their approach.

So whilst “traditional” architecture may be dying, I’d think the good bits from that legacy will continue – with some new additions and perhaps adapted a little in terms of tactics and approach.  When you realise that such a major transformation is slowly happening right before your very eyes, and that you’re part of it – that’s pretty cool.

#ITEA – https://www.conferenz.co.nz/events/it-enterprise-architecture