I am not an architect!

In the September issue of "Inside O.R.", the president of the Operational Research Society (UK), Geoff Royston, wrote about the image of O.R.  Inside O.R. is the monthly newsletter of the O R Society
Many years ago I wrote a short piece for Inside O.R. (back when it was called the O.R. Newsletter) in which I discussed the problem that O.R., as seen by others, suffered from some misclassification problems.

In particular that others tended to assume ‘operational’ meant tactical, that ‘research’ implied impractical, and that they too often equated the tools of O.R. (especially mathematics and computing) with O.R. itself.

I suggested that one approach to overcome or at least mitigate this problem would be to present our work so it aligned more clearly with a ‘general problem cycle’ that would be familiar to managers, The idea was that presentation of our work on these lines might provide a more marketable agenda for O.R. than one based on the tools of the trade or on narrowly technical problems.

To accompany that generic approach, I suggested that we might usefully present ourselves as ‘general analysts’. This drew on some analogies with general practitioners of medicine (who, in examination, diagnosis and prescription, follow their own version of the above problem cycle).

The analogy with medicine, particularly with the work of a G.P., seemed - still seems - useful. Firstly it places the focus on a client and their problem rather than on tools and techniques. Medicine needs and uses disciplines like biochemistry or physiology, but as a means to the practical end of helping a patient, not for knowledge for its own sake. Similarly, O.R. needs and uses disciplines like mathematics or computer science, not as ends but as means to its primary goal of helping with a client’s (or at least a potential client’s) problems.

Secondly, it emphasizes the importance of taking a systemic view. G.P.s need to take a holistic approach when considering the problems of, and interventions for, their patients, who frequently present with multiple conditions with more than one cause. A systems perspective is also essential in public health medicine, to help understand and control the spread of disease in a community. Just as the G.P. or the public health medic, by taking a broad systemic view, offers something distinct to patients and the public from those who specialise in a narrower area such as orthopaedics or cardiology, the O.R. professional, seen as a general analyst, offers something different to the world of management and organisation from that provided by those working in a single more specialised area such as economics or psychology.

So, medicine provides one useful analogy for us. But there is another profession with which analogy might usefully be drawn: architecture.

Like the O.R. worker, the architect is concerned with helping in a structured way (literally so in the latter’s case!) with a client’s problem, and also like the O.R. worker, the architect uses diagrams and models as virtual worlds on which to experiment. Like clinicians, architects follow their own version of the general problem cycle, but with a particular emphasis on innovation and the problems of design.

Design is challenging because it requires conceiving and assessing what can be a vast range of alternatives, with much iteration to find feasible and desirable solutions, because many design problems cannot be neatly subdivided into independent sub-problems, and because the process of designing, especially when done together with clients, often brings about changes in the perception of what needs to be designed.

Sounds familiar? The O.R. professional is often faced with problems that have something in common with the challenges faced by an architect. Although we may sometimes be asked simply to help with the choice between pre-existing options, more often we are given - or discover - a much more open-ended problem: the conception and creation of something that will improve a situation. That is a broad question of design; yet O.R. is persistently characterised as being primarily concerned with the important but narrower task of assisting decisions. This sells O.R. short.

The importance of design for operational research and management science was recognised in the 1960s by early luminaries such as the Nobel laureate Herbert Simon. He considered design to be the ‘core of all professional training’, including in management, and in his seminal book ‘The Sciences of the Artificial’ called for ‘ a science of design’ which would concern itself with topics such as the representation of design problems and the search for alternatives. He included in this science many of the then new methods of operational research.

Simon warned that design skills were being squeezed out of management training, and the later well-known series of papers on O.R. by Russ Ackoff noted that such skills were also being sidelined in management science. Ackoff argued that traditional techniques of analysis – techniques he had done much to promulgate - were insufficient for tackling important managerial and societal problems. He argued that also needed were the skills of synthesis His stated view was that the paradigm of O.R. should involve ‘designing a desirable future’ and his explicit challenge to O.R. professionals was ‘not so much to improve our methods of evaluation, but to improve our methods of design and invention’. Such concerns were noted and acted on by a number of people in the O.R community, at least on this side of the Atlantic. The most obvious result was the development of what came to be called ‘soft O.R.’. This sought to widen the role of the O.R. professional from technical expert with an emphasis on solving precise and sometimes unrealistic problems to that of reflective inquirer with an emphasis on framing and structuring problems of the real world in helpful ways.

This undoubtedly helped widen the vision of O.R. and did much to meet the criticisms of Ackoff and others, but the development of ‘soft O.R.’ appears more a response to the general criticism on the limitations of ‘hard’ technical approaches than to the specific call to accord a central role to design. There has been the occasional acknowledgement of the relevance of aspects of design thinking to O.R. – for example the strong but hidden similarities between engineering design and O.R. has been discussed by Albert Holzman, the implications for MS/OR of the shift in managerial interest from analysis for marginal improvements to design of complete systems has been noted by Robert O’Keefe and the relationships between operations management and design have been considered by Jan Holmstrom. Generally however such recognition has been sparse. A passable case for the defence, or at least a plea in mitigation, could be made that O.R. is deeply involved with design, but just does not make this sufficiently explicit. We should not forget that O.R. in the modern era was founded in a challenge of design - creating the British air defence information system that played such a crucial role in WW2. Design clearly continues to feature in O.R. work to this day - a look at, say, the winners over the years of the OR Society President’s Medal, or of the INFORMS Edelman award, shows that many of the projects have involved sizeable amounts of system design work. So maybe the main challenge is to recognise, publicise and develop this hidden expertise.

How might we market our design skills more explicitly and effectively? (The slogan developed to help publicise O.R., ‘the science of better’, hints at something that goes beyond decision making but the associated publicity materials have not highlighted design thinking). More importantly perhaps, how can we improve our design skills - how do we educate and train O.R. people better for these more creative aspects of our work? Developing our capability to embed technical problem solving and decision analysis in a wider activity of reflective inquiry and innovative design must surely increase our range, relevance and impact.

In operational research we need the diagnostic expertise of a physician. We need the architect’s skills of design. We are – or should be - both medics and architects.

In the following issue, my letter to the editor was printed, with the heading "I am not an architect"

In September's issue, the president suggested two analogies for O.R., medicine and architecture, to which you added the third of engineering.   

While I am happy with the first and the third, I have some reservations about the second.  

The analogy that an O.R. scientist acts as a doctor is a helpful one; the doctor's aim is to solve the problem - in this case, the problem of sickness or pain, and therefore enters a cycle of collecting information, intervening and participating in a feedback loop with the client (patient).  It is especially helpful because the natural association of the work of a doctor is to solve a problem.  There are limits to the analogy, particularly when one thinks of hospital specialists whose expertise is concerned with particular problems. 

Again, engineers solve problems, and they too enter a feedback loop of collecting information and data, modifying their design or product, making tests and evaluations with the aim of making something work successfully.  The downside of this analogy is that the first association one may make with the profession of "engineer" is not as a problem-solver, but as the motor mechanic or building site worker.  

There are many positive aspects to thinking about O.R. scientists and architects as coming from similar moulds.  Architects use models to think with and their models or diagrams may go through several iterations as they engage with other people; just like O.R. people.  Architects are concerned with a large system, and see the place of their work in an overall system; just like  O.R. people.  Architects are concerned with multiple academic disciplines and using different kinds of resources well; just like O.R. people.  Architecture combines art and science, a reminder for all of us that operational research involves creativity.  But, for many people, these are not the associations that will spring to mind when the job-title "architect" is mentioned.  That's where I have my problems with the analogy.   They are two, interlinked problems.  One is concerned about the definition of the client; the other is concerned with the timescale of the feedback to the architect.  An architect may have many "clients" for a project; the builder, the owner of the building, the people who occupy the building, visitors to the building, those who maintain the building.  A good architect will think of each of these, but will not be able to interact directly or indirectly with them all.  And there is no easy mechanism to alter the architect's work with feedback once the construction is complete.  Part of the best O.R. is that iterative loop of feedback and change once the clients (seen and unseen) have started to implement the results of the  O.R. work.  The second problem is timescale.  Generally an architect's work is there for many years.  Feedback is not possible for the users, owners, occupiers, etc, after many years.  (For example, my house is almost 80 years old.  I am unable to feed comments and suggestions to the architect about aspects of poor design of the house.)  There may be some O.R. results which last for years, but they are very few.  Perhaps a better analogy would be the designer of a fitted kitchen, something which is semi-permanent within the building. 

Hence, I am happy to be thought of as a doctor, engineer - but I am not an architect!