bpd keynote: design is how we change the world
DESCRIPTION
Keynote at the 8th International Workshop on Business Process Design, Tallinn, Estonia, September 3, 2012. Discusses design thinking, coming up with new ideas, and how design thinking is taught at Stevens Institute of Technology. Thanks to Michael Rosemann and Jeff Nickerson for ideas and discussion.TRANSCRIPT
Michael zur Muehlen, Ph.D.Stevens Institute of TechnologyHowe School of Technology ManagementCenter for Business Process InnovationHoboken, New [email protected]
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: [email protected]
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: [email protected]
Web: http://www.stevens.edu/bpm
slides: www.slideshare.net/mzurmuehlen
54