Michael zur Muehlen, Ph.D.Stevens Institute of TechnologyHowe School of Technology ManagementCenter for Business Process InnovationHoboken, New JerseyMichael.zurMuehlen@stevens.edu

Design is How We Change The World8th International Workshop on Business Process Design

1

2

Marco Polo describes a bridge, stone by stone.

“But which is the stone that supports the bridge?” Kublai Khan asks.

“The bridge is not supported by one stone or another,” Marco answers, “but by the line of the arch that they form.”

Kublai Khan adds “Why do you speak to me of the stones? It is only the arch that matters to me.”

Polo answers: “Without stones there is no arch.”

Italo Calvino: Invisible Cities, 1972

BPD 2011 Recap

Design is important: Design is how we change the worldValidation is important: How do we tell good design from bad?Trial & Error: Where are the experiments?

3

4

design |dəˈzīn|

purpose, planning, or intention that exists or is thought to exist behind an action, fact, or material object.

5

5

5

“Most businesses have just3 core processes:

1. selling stuff2. delivering stuff, and 3.making sure you have stuff to sell and deliver”

Geary Rummler

7

Fortune 500 Business 1962

De!ned capabilities

De!ned services

De!ned processes

De!ned endpoints

De!ned integration mechanisms

Fortune 500 business 2012

8

Evolving capabilities

Continual new service development

What process?

Device evolution drives endpoints

Integration across platforms, parties

Process DesignTesco, South Korea

Process Design vs. Process Engineering

Few engineers and composers [...] can carry on a mutually rewarding conversation about the content of each other’s professional work.

Herbert Simon, The Sciences of the Artificial (1996), p. 137.

10

Large-Scale Requirements Analysis Revisited: The need for

Understanding the Political Ecology of Requirements Engineering

Mark Bergmana

Mark Bergmana, John Leslie Kingb

, John Leslie Kingband Kalle Lyytinenc

and Kalle Lyytinenc

aDepartment of Information and Computer Science, University of California, Irvine, California, USA; bSchool of Information, University of Michigan, Ann

Arbor, Michigan, USA; cDepartment of Information Systems, Case Western Reserve University, Cleveland, Ohio, USA

This paper addresses the political nature of requirements

for large systems, and argues that requirements

engineering theory and practice must become more

engaged with these issues. It argues that large-scale

system requirements is constructed through a political

decision process, whereby requirements emerge as a set

of mappings between consecutive solution spaces

justified by a problem space of concern to a set of

principals. These solution spaces are complex socio-

technical ensembles that often exhibit non-linear

behaviour in expansion due to domain complexity and

political ambiguity. Stabilisation of solutions into

agreed-on specifications occurs only through the

exercise of organisational power. Effective requirements

engineering in such cases is most effectively seen as a

form of heterogeneous engineering in which technical,

social, economic and institutional factors are brought

together in a current solution space that provides the

baseline for construction of proposed new solution

spaces.

Keywords: Functional requirements; Heterogeneous

engineering; Political requirements; System failures;

System requirements

1. IntroductionLarge-scale software development has remained a high-

risk proposition despite huge advances in computing and

telecommunications technologies. Large projects in

particular continue to fail at an unacceptable rate [1–

6]. While some troubled projects are turned around,

many projects seem to be successful only at random.

Improved software tools, modelling methods and process

technologies for performing requirements engineering

(RE) have yet to provide sufficient progress in avoiding

failures in such initiatives. Advances in technologies and

modelling techniques alone are inadequate to save large

and complex projects. We must turn our attention to a

wider set of issues and try to understand how

technological, organisational and institutional changes

are inherently interwoven in such initiatives. Only then

can we expect to make progress in understanding how

system developers might successfully state and manage

requirements for such systems.

The following example by Drummond [7] provides a

helpful starting point. On 11March 1993, the financial

world was shocked by the sudden cancellation of the

London Stock Exchange Taurus project. Taurus had

been under development for more than six years,

following over 20 years of deliberations about how to

restructure and organise the exchange’s trade settle-

ments. Taurus was expected to enable a radical

restructuring of the securities trade by forming a

backbone system for a fully automated settlement

process involving digitalisation of bonds and certificates.

By then the project had cost the exchange $130 million,

while securities companies had invested and additional

$600 million [2]. The expected transformation of the

exchange, which was heralded as the Big Bang in

promotional literature, went out with a whimper. Taurus

was cancelled before a single module was implemented

when management discovered that the functionality and

performance required of the system could never be

delivered in an acceptable time frame.

Requirements Eng (2002) 7:152–171

Ownership and Copyright

! 2002 Springer-Verlag London Limited

RequirementsEngineering

Correspondence and offprint requests to:M. Bergman, Department of

Information and Computer Science, University of California, Irvine,

CA 92697-4650, USA. Email: mbergman@ics.uci.edu

11

Political EcologyProblems are existing solutions someone has issues with

Solutions lead to Problems lead to Solutions

Repeat

Bergman, King, Lyytinen (2002)

12

Functional Ecology

Bergman et al (2002), p. 158.

Clear Requirements, Clear Goals?

“Two key assumptions frame traditional [Requirements Engineering].

One is that requirements exist ‘out there’ in the minds of stakeholders (users, customers, clients), and they can be elicited through various mechanisms and refined into complete and consistent specifications.

The second is that the key stakeholders operate in a state of goal congruence, in which there is widespread and coherent agreement on the goals of the organisation.”

Bergman et al. (2002), p. 154

Neither of these assumptions is necessarily true.

13

Understanding the Problem Space

Describing a problem in general terms is hard

So: We often use examples

Most examples tend to prescribe solution fragments

Problem: Solution fragments constrain the design space

Good designers elicit the essence of the problem

Keep asking:

What is the underlying problem?

Why is it a problem?

14

Process DesignDriven by an Opportunity

16

Example: Military Recruiting

17

19

20

Process DesignYou are in charge for the process “Visiting tourists at the Empire State Building”

What is your objective?

What possible process designs can you come up with?

Circle

Circle

Oval

Oval

Fruit

Fruit Sport

Sport

22

23

1

Reprint from the magazine Design, London: Council of Industrial Design, N° 206, 1966]

A city is not a tree By Christopher Alexander The article that follows has won for itself, and its author - an architect and

mathematician - a special distinction among all that has been written about design during

the past few years. Together with a series of articles by Ada Louise Huxtable and two essays

by Lewis Mumford, it was selected as one of the 1965 Kaufmann International Design Awards.

The 1965 awards follow a series started in 1960, sponsored by the Edgar J. Kaufmann

Foundation and administered by the Institute of International Education. On previous

occasions they have gone to Charles and Ray Eames, Walter Gropius, and the Olivetti

Corporation, and subsequently have provided a series of research grants totalling $ 61,500.

The latest awards were given for "the most effective statements dealing with the field of

design, published in periodical or occasional form within the past five years", and represent

the first occasion on which the contribution of criticism to the development of design has

been overtly acknowledged. The international jury which selected the 1965 awards (Richard Latham, Peter

Muller-Munk and David Strout from the USA, Finn Juhl from Denmark, and John E. Blake,

chairman, from Britain) studied some 200 articles and essays that had been submitted to

them by consultants in seven countries. Commenting on the selection, the judges' report

stated, "Essentially, three aspects of the problem emerged, all of which we considered to be

of equal importance. The first involved those statements which contribute to new thinking in

the field of design.... The second involved statements which, though possibly not containing

new thought, contribute to a wider understanding of known problems.... The third

concerned the quality of writing, for the effectiveness of any statement will depend on

clarity of expression, on the logical and economical presentation of an argument, on the

mastery of words.... The first and second aspects often overlapped in the same item, and the

third we considered to be essential to any statement which was to be selected for an award".

The brief to the jury had defined design as "pIanning that results in any visually

expressive, practical implementation of human occupations, ceremonies or play". This broad

definition created certain difficulties for the judges, but their report continues that the final

selection was ". . . a recognition that the detailed considerations of architecture and industrial

design paled into comparative insignificance when seen against the massive problems of

social planning and its expression in the structure and forms of the modern city. The three

awards, each in its own way, had tackled this problem. Each recognised that the evolution of

the modern city was reaching a point of crisis and that its solution was possibly the greatest

challenge facing the second half of the twentieth century. Each recognised that the city is a

system of vast complexity and in turn is part of a bigger system of social organisation whose

values and goals are being questioned."

In deciding to reprint A City is not a Tree, DESIGN is aware that it will seem to be

outside the range of subjects normally covered by the magazine. The judges' report

emphasised, however, that "The principles he [Dr Alexander] describes, and the analytical

methods he adopts, are applicable at all levels of design". It was felt that Dr Alexander's

thesis is as relevant to industrial designers, architects and engineers as it is to city planners,

for the city provides the context into which most buildings, products and services must fit.

And it is important that those of us who are primarily concerned with such things should

stand back, once in a while, to take in the broader view.

A City is not a Tree is reproduced here by kind permission of the American journal

Architectural Forum, where it originally appeared in two parts in April and May last year.

Since the article was first published some slight amendments have been made at the request

of the author.

What just happened?

24

1 2 3 4 5

1,2 3,4

3,4,5

1,2,3,4,5

12 3

4 51,2 3,4

3,4,5

1,2,3,4,5

What just happened?

25

1 2 3 4 5

1,2 2,3,4

2,3,4,5

1,2,3,4,5

1 2 34 5

1,2 2,3,4

2,3,4,5

1,2,3,4,5

26

Sporting Good FruitOval Circle

Shape

Melon OrangeSoccer BallFootball

Design and Categorization

We tend to break content into non-overlapping boxes

Reality consists of many overlapping parts

Traditional requirements analysis techniques are top-down

Mining reality might help, but yields complexity

27

Design as a Search Process

The are a large (virtually in!nite) number of possible designs for a given problem scenario.

A designer "eshes out design ideas from this design space.

The design ideas can be evaluated using criteria that a given design has to satisfy.

Design is seen as a formal, structured process.

28

29

Types of Solutions

Local solution space – all solutions that can be reached from the current solution with available skills and resources

Global solution space – all possible solutions, for which resource might need to be mobilized.

Problems are used to mobilize resources

Question

What is the next conceivable design that we have not thought of yet?

30

Process Execution Space

31

Design Space and Evaluation Space

Jeff Nickerson (2012)

32

Design Evaluation

Design Space: Example

33

# of steps in the process

# of human operators

involved in the process

AB

C

Cf. Jeff Nickerson (2012)

Evaluation Space: Example

34

$ executioncost

$ implementationcost

A

B

C

Cf. Jeff Nickerson (2012)

Design Dimensions for Processes

Structural Complexity

Activity Design

Behavioral Complexity

Discrete Paths

Decisions

Data Integration

Inputs

Outputs

Resource Integration

...

35

Evaluation Dimensions for Processes

Simplicity

Adaptability

Usability

Modularity

Security

Maintainability

...

36

Imitate, Adapt, or Innovate?

Given a particular business problem, a designer’s choices are

Imitate: To imitate existing designs, possibly by transferring them from other domains or implementation platforms.

Adapt: To provide detail for a high-level design sketch that is deemed applicable to more than one problem scenario (i.e. reference models).

Innovate: To develop an entirely new design

37

3816

3917

4018

Process DesignDriven by a Constraint

42

Systematic Doubt (Horst Rittel)

Describe a situation and frame a problem

Then negate each statement - one at a time - to generate a solution.

Make the last statement “Problem:”

43

Systematic Doubt (cont’d)

“The principle of systematic doubt relies on a simple principle of logic - if statements in a set make the set true, then the negation of any one of the statements makes the set false. So if a certain number of conditions contribute to the problem, the negation of any one of them negates the whole problem. First, we express the problem in a story form as a number of statements.”

Horst Rittel, class notes 1978

44

Systematic Doubt - ExampleA1  At the Stadium in Southern Oakland

A2  Sporting and concert events are held.

A3  After an event everyone leaves

A4  For many, Bart is the only means of transportation

A5  Access to Bart exists solely by pedestrian bridge

A6  The bridge is narrow

A7  People are funneled in from two sides

A8  They walk slowly because of the density of people

A9  People don't like being in a herd for half an hour

A10 Problem - Reduce the time spent getting from the stadium to Bart.

45

Negating the Issues

N1  Not at the stadium in Southern Oakland - Move the stadium to a different location

46

Negating the IssuesN1  Not at the stadium in Southern Oakland - Move the stadium to a different

location

N2  Sporting and concert events are not held - With no events, there would be no crowds

N3  After an event everyone doesn't leave - Stagger the exiting

N4  For many Bart is not the only means of transportation - Provide other means

N5  Access to Bart doesn't exist solely by a pedestrian bridge - Build a tunnel

N6  The bridge isn't narrow - Widen the bridge

N7  People aren't funneled in from two sides - Allow approach from only one side

N8  They don't walk slowly - Teach people how to move more quickly in a crowd

N 9  People like being in a herd for half an hour - Play music, provide entertainment

N 10  No problem - Let them wait on the bridge; consider the wait as part of the event.

Teaching Design - Learning Goals

47

Each student can develop an integrated IT architecture that satis!es technical and organizational constraints

Students develop viable designs

Starting from a broad problem, students develop a speci!c problem scenario

Evaluation: Starting from a broad problem, students develop a speci!c problem scenario

48

Poor Acceptable Good

The scenario is consistent with the broad

problem de"nitionNo link Apparent link Strong link

The scenario is speci"c, detailing actors, systems,

and the messages between them

Restatement of the problem

Additional Detail Strong, speci"c example

The scenario represents the core of the broadly

de"ned problemTrivial Worthy of solution

Gets to the heart of the matter

Evaluation: Students develop a viable design

49

Poor Acceptable Good

The design is communicated well

Diagram conventions are ignored

The idea can be understood

The idea is very clear

The design ful"lls the problem constraints

The constraints are ignored

The design is arguably within the constraints

The design is clearly within the constraints

Alternative designs are generated, and

compared against each other

No alternativesSeveral similar

alternativesSeveral quite different

alternatives

The design demonstrates a holistic

grasp of both the technical and social

aspects of the proposed system

People or technology are ignored

Both are consideredTheir interaction is

clear

The design is strongThe design is trivial or

confusedThe design is solid

The design is innovative or thought-provoking

Students develop viable designs

50

Trading Transaction Protocolsell (Price, Quantity, Spread, Time Limit, MM (Seller) ID)Returns Ask_ID if successful placing the ask Returns failure if ask unsuccessful

buy (Price, Quantity, Spread, Time Limit, MM (Buyer) ID)Returns Bid_ID if successful placing the bid Returns failure if bid unsuccessful

revoke (Ask_ID/Bid_ID, MM (Buyer) ID) Returns success if stock has not yet been traded Returns alreadytraded if it has been traded and cannot be revokedReturns cancelled if subdomain controller cancelled transaction

status (Ask/Bid ID, MM (Buyer/Seller) ID)Returns pending if not already traded Returns sale details if traded (trade time, price, quantity) Returns cancelled if subdomain controller cancelled transaction

open_trading (Subdomain Controller ID, Authorization Codes)halt_trading (Subdomain Controller ID, Authorization Codes)

Examples of Transaction Requests:ttp://t.stock.nyse/sell (Body of request contains encrypted structure containing variables price, quantity, spread, time limit, MM ID)ttp://t.stock.nyse/buy (Body similar to sell)ttp://t.stock.nyse/status

nyse subdomain

Market

Maker

(Buyer)

Problem DefinitionRedesign stock exchanges and the they

interconnect and work together, taking trading,

settling, and resiliency into

account.Distributed Node TopologyThe core

backbone for trading will consist of an Internet-style network

of distributed nodes. Each stock/bond/security will have

between 3 and 16 trading nodes depending upon transaction

volume demands for the stock. Stock transaction details are

synchronized in real-time amongst the nodes which are

established for each stock. The trading nodes are distributed

geographically throughout the world and are connected via a

secure high-speed fully distributed backbone with multiple

connectivity paths between nodes.

Trading Transaction ProtocolBuyers and sellers

connect to the trading network through a market maker. The

market maker is authorized to connect to the network nodes

to conduct transactions. When a trade is requested, the

market maker uses the TNNS to locate and connect to a node

which is responsible for coordinating trading of the stock.

Public Key transactions will be done first if the market maker

and the node are not aware of each other's public keys. Once

this is done, any number of trades can be executed, each

transaction packet will be encrypted using the exchanged

public keys.

Trading Node Naming System (TNNS)Nodes are located using a DNS-style naming network called

Trading Node Naming System (TNNS). This system will

incorporate caching and redundancy just like DNS does.

Unlike DNS, each name will contain a complete list of

redundant trading nodes for the particular stock rather than

one individual server location. Each subdomain controller has

control over the addition of new names and the nodes that the

names are used on. In addition, the subdomain controller can

halt trading and open trading on a particular stock by issuing a

command to the nodes. If a stock is halted, they have the

option of canceling active buyer and seller requests.

Stock Name Examples

msft.stock.nasdaq

Microsoft on the NASDAQ Exch.

t.stock.nyse

AT&T / New York Stock Exch.

vbinx.fund.nasdaq

Vanguard Index Fund / Nasdaq

gold.commodity.tse

Value of Gold Ounce / Tokyo

yen.currency.ftse

Value of Yen / London Exchange

Chris BoraskiMGT 784ST

Assignment 52/14/2004

Root

Node

nyse nasdaq tse ftse

stockbond stock fund commodity currency

yengoldvbinxmsftt

Distributed Node Topology

Trading Node Naming System (TNNS)

New York node

msft.stock.nasdaq

t.stock.nyse

gold.commodity.tse

yen.currency.ftse

Chicago node

msft.stock.nasdaq

gold.commodity.tse

yen.currency.ftse

San Francisco node

msft.stock.nasdaq

gold.commodity.tse

vbinx.fund.nasdaq

Houston node

t.stock.nyse

yen.currency.ftse

vbinx.fund.nasdaq

London node

t.stock.nyse

yen.currency.ftse

vbinx.fund.nasdaq

Tokyo node

t.stock.nyse

yen.currency.ftse

gold.commodity.tse

Market

Maker

(Seller)

Seller

Buyer

nyc

The Bottom Line

Design requires consideration of two distinct spaces: design space and evaluation space

Our cognitive facilities are limited when dealing with multi-dimensional problems

Process engineers should learn design thinking, and process designers need to appreciate an engineer’s viewpoint

We can teach this

51

RecommendedReading

Frederick P. Brooks:The Design of DesignAddison Wesley, 2010.

Herbert Simon:The Sciences of the Arti!cial.MIT Press, 1996.

52

53

In every age someone, looking at Fedora as it was, imagined a way of making it the ideal city, but while he constructed his miniature model, Fedora was already no longer the same as before, and what had been until yesterday a possible future became only a toy in a glass globe.

Italo Calvino: Invisible Cities, 1972

Thank You - Questions?

Michael zur Muehlen, Ph.D.

Center for Business Process Innovation

Howe School of Technology Management

Stevens Institute of Technology

Castle Point on the Hudson

Hoboken, NJ 07030

Phone: +1 (201) 216-8293

Fax: +1 (201) 216-5385

E-mail: mzurmuehlen@stevens.edu

Web: http://www.stevens.edu/bpm

slides: www.slideshare.net/mzurmuehlen

54