Design versus Engineering

Stephen Few recently wrote a post after having attended an SAP BI presentation here in Melbourne a couple of weeks ago (unfortunately I missed it, and the chance to meet him, although a couple of colleagues from the DSS Lab did manage to catch up with him). The central thrust of his post centred on the issue of an engineering versus a design perspective on the problem of providing decision support.

I reckon he's spot on and his argument echoes a line of thought that I've been toying with for quite some time.

For myself, I've been grappling with this concept of design versus engineering as I've practised and taught IT-based design techniques like conceptual data modelling. What's fundamentally different between the two perspectives? Both engineering and design express themselves through the properties of a technical artefact. They also have a symbiotic relationship with each other - one can't do design without engineering, or vice versa. However, intuitively there is a fundamental difference of perspective, and it's taken me a couple of years of reading and thinking to put my finger on it.

The 'aha!' moment came a couple of weeks ago as I was working on a paper trying to more rigorously define the notion of Web 2.0. One of the problems with that idea is that every IT industry niche has jumped on the bandwagon so that now we have BI 2.0, ERP 2.0, even Library 2.0, without really identifying what it's fundamentally about.

My thesis is that Web 2.0 is not about the technology itself - AJAX, RoR etc. etc - because you can achieve the same Web 2.0-style outcomes using different technologies like HTML5 etc. Instead, Web 2.0 is a design concept, perhaps even a design movement. This led me, in a circuitous way, to read a paper by Lynne Markus and Mark Silver called A Foundation for the Study of IT Effects: A New Look at DeSanctis and Poole's Concepts of Structural Features and Spirit.¹ In this paper, they critique an earlier theory of studying IT artefacts based on the idea that what's really important is not so much the features of a given piece of technology, but rather the relationship between that technology and its users.

For example, they draw on the concept of affordance. This relates to the things that an object or environment offers an actor, but it's specific to each actor. While a chair might be something that offers me the affordance of sitting, to a child it is an object that can be climbed on, crawled under, and so on. In other words, to understand a technological artefact, we have to look, not so much at the artefact itself, but how the properties of the artefact and the properties of the user interact.

And this was that aha! insight: the difference between design and engineering is that design is concerned with the space between the user and the artefact; engineers, on the other hand, are primarily concerned with the artefact itself. Both express themselves through the properties of the artefact itself, but design treats that as secondary to what the artefact does for the user, what it means, and how it impacts on the environment.

The problem with vendors in BI, and really most of the IT industry in general, is that we're all focussed on the technical artefact. As a result, the design of how that artefact is used, what it allows users to do, and the impact that it has on the decision support environment is largely ignored. As Stephen Few points out, old-school, large-scale BI vendors are so focussed on their software's bells and whistles that they almost completely ignore the fundamentals of helping people make more effective, better quality decisions.

Following from Markus and Silver's paper, I'd argue that design of IT artefacts, including BI software, needs to consider two key concepts: affordance, as described above, and what they call 'symbollic expressions.' The latter refers to the implicit values, principles and ideas communicated by the technology to the user. Too often in BI, the values and principles that are communicated by tools like Crystal Xcelsius, and lots of dashboard implementations, is form over substance. Dazzling your audience with 3D exploding pie charts and speed-dials is given more importance than imparting a proper understanding of the relevant information.

It's time that we had a design company in Business Intelligence, rather than the plethora of engineering companies we now have. Think Apple versus IBM. Love or hate them, there is no denying that Apple's focus is on the experience of using their products within an ecosystem of iTunes, App Store and iDevice, rather than on the technical attributes of the devices themselves. From a technical standpoint, Apple's devices are not significantly better (and they're often worse) than their competitor's products. But it's the design that goes into the experience of using the device that makes the fundamental difference. IBM, on the other hand, is the classic engineering company focussed primarily on the technical artefact itself.

We need a vendor to do for BI what Apple did for music players, mobile phones and tablet computing. We need a vendor that understands tactical and strategic decision making in organisations and who is willing to have a go at changing and improving that process rather than bolting on yet another suite of 'smoke and mirrors' to their already bloated software.

--
¹ Markus, M. L. and M. S. Silver (2008) "A Foundation for the Study of IT Effects: A New Look at DeSanctis and Poole's Concepts of Structural Features and Spirit," Journal of the Association for Information Systems (9) 10/11, pp. 609-632.