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 either–or choice.