Design Thinking and EA: I ‘Heart’ Managers

I studied Art History a long time ago. One of the ways they test you is to show you two works of art side by side and ask you to discuss the similarities and differences. I am not sure of the pedagogical theory behind that. But we did it and it was taken as a demonstration of knowledge.

In my first essay into this question of design thinking in IT generally, and enterprise architecture specifically, I set up design as a way of solving problems in contrast to management. Of course, in doing so I run the risk of implying that each excludes the characteristics of the other. Worse, it suggests there is a choice to be made between the two. Certainly I run the risk of alienating those who are making a genuine effort to examine the same issues from inside a manifestly managerial frame of reference. Which would be a shame.

So before I construct management thinking as a ‘straw man’ for Mr Designer to knock down, I thought it best to go on the record with some inclusive, it’s-a-big-world-and-there’s-room-for-all-of-us background comments that I can refer back to later. I hope they will assure any alarmed souls that I haven’t lost sight of reason or become hypnotised by the beauty of my own thought-bubbles.

First I will predict that I will (probably) come to the conclusion that enterprise architects are not, strictly speaking, in the design business. If you care enough about a topic as arcane as enterprise architecture to be reading this blog then I am sure you already know there is a big old planet wide discussion going on about what enterprise architecture is, why it is, and what the proper version of it looks like. In that conversation it is becoming common to distinguish between enterprise architecture and solution architecture – often referred to as enterprise IT architecture (EITA). I would have to say, if anyone is going to be applying design disciplines directly to production IT, it will be the EITA propellor-heads, not the EA suits.

I recall an engaging talk by a colleague I greatly respect, Damian Bramins, the EA at the University of Western Australia. Damian suggested that architecture is perhaps not the best metaphor for what we do as enterprise architects. We don’t generally engage in detailed conceptualisation and structural design of IT systems. That’s what solution architects or EITAs do. We might be better described as ‘enterprise town planners’. Our concern with portfolios, trends, standards and such like, is better compared to planners who make sure there are standard gauges for light-rail systems, that storm-water systems are built with long-term rainfall patterns in mind, and that toxic chemical processing factories are not built beside kindergartens or market gardens.

I agree with him. And before I start the whole management versus design investigation, I should like to observe that town planning is manifestly more management than design.

Secondly I should like to observe that nothing that actually gets done in production IT gets done without a sensible allocation of resources and some common-sense decision making about what needs to be done, who should do it, and what they are going to need to get it done. Those are management problems, and the thinking required to solve them is not simple, or unimportant. So I won’t be scoffing. We need good management. We always have, and we always will. In practice, wherever good design is translated into real products and services I think it is a pretty safe bet it was executed within a framework of resources provided and sustained by some talented mangers.

So there it is. I do not resile at all from my opening hypothesis:

Production IT in large organisations has been persistently difficult, under-performing and failure prone because we frequently attempt to solve design problems with management thinking.

But it is a hypothesis. It’s there to be tested in some way. Let’s not foul things up with a false corollary. My hypothesis does not at all imply there are only design problems in production IT. And, therefore, it should not be understood to imply the management thinking in unnecessary or harmful. That would be just dumb.

I plan to do some sustained comparing and contrasting. But that should not imply an eitheror choice.

2 thoughts on “Design Thinking and EA: I ‘Heart’ Managers

  1. Thanks for the comment Stuart. I guess I do think it matters. I have to come to that conclusion because I am taking some time I could be using playing the guitar or watching football to talk about what EA is and how I might become better at doing it.

    I have often observed that in the broadest sense – as a species that is – we are pretty crap at causality. But after that we are also rubbish at taxonomy. Our brains just don’t work that way natively. It’s because what we are absolutely brilliant at – apart from kicking and throwing balls – is pattern recognition. But being good at that imposes a kind of necessary slack that undermines the precision of our taxonomies and a kind of paranoia that sees relationships and intentions where there aren’t any – all the time. Which is why it took thousands of generations, many jail sentences and one or two burnings-at-the-stake to hammer out the scientific method that has given us this excellent platform for collaborating and a niggling disquiet about ‘saddle-shaped’ parallel universes.

    My response is to try and speak (or write) clearly, and to listen graciously for the intent of others. And I want to be able to think about things without being too prejudiced by the dictionary that is already in my head. Hence my tendency to bundle Solution Architecture and EITA into awkward compound sentences. On paper they tempt us to come up with a neat and tidy boundary between the two. Out there in fluorescent-lit cubicle farms the world over there are real people who on a day to day basis do a bit of this and a bit of that as they move from email to email. Some of them are called Enterprise Architects. Some aren’t.

    I think the same promiscuity of practice applies to the relationship between ‘design’ and ‘management’. Everything that we build at work has in some way been ‘designed’, and those same things have in some way been managed. To think ‘differently’ – to have some new ideas, and to test them in the world with others – requires me to draw distinctions and make comparisons. But in practice those distinctions are not so clear, and over-emphasising them could make the work harder.

    So this post is a prolegomenon to a discussion I plan to have. A ritual handshake with my imagined opponents prior to a spirited bout. It’s my way of saying up front the contest of ideas is important – but I am not playing a zero-sum game here. If the rubric of ‘design thinking’ does have the capacity to answer some problems that ‘management thinking’ hasn’t (in EA at a minimum) then I personally am looking at it as an addition to the practice of EA, not a subtraction. My goal is to extend my conceptual repertoire.

    So thanks. I do hope you stay with me on this (intermittent and rather halting) journey. I look forward to your contribution.

  2. This is a fascinating and enjoyable post Ric. I agree with a lot of it and a few months ago I’d have agreed with most of it but I seem to have suffered a conversion on the road to Damascus (not a nice place to be right now). Please note I wouldn’t write what follows, if I substantially disagreed. It’s intended as constructive and for debate.

    To the point. First, I’m not a fan of the EA is like town planning analogy. I think we (if we do it right) are architects, because we work with the “client” (the enterprise) to help define and visualize their requirements, that will help to deliver their vision. And then we continue to develop the models that the engineers and later the builders need to develop the physical solutions. And we remain involved throughout the entire lifecycle. I don’t think town planners do that. But maybe that’s just a lack of respect for the profession.
    Does that matter? Well a bit, if the purpose of the analogy is to help draw conclusions.

    I agree we need good managers (desperately). But with Deming and Beer I think a good manager is someone who enables other folk to do their work. I’ve had the privilege to work with a couple fo those and the misfortune to work with more, who think they know what everyone else’s job is.

    I definitely agree with the statement that “Production IT in large organisations has been persistently difficult, under-performing and failure prone because we frequently attempt to solve design problems with management thinking”. I’d go as far as to say that we should be solving management problems with design thinking. And I don’t think this needs only to apply to IT. But my reservation is that I don’t see how your argument leads to this conclusion.

    Last thing. I don’t think EITA is Solution Architecture. It’s just the IT part of EA. Of course the debate you refer to has a thousand different interpretations of EA (all of which are in the opinion of their authors 100% correct). If one accepts that TOGAF is an EITA framework, then TOGAF makes a very clear distinction with Enterprise and Solution Architecture but is primarily concerned with the former. Does it matter? You tell me.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s