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
Peruse Muse Infuse 