Back Room Front Room 2

46
ENTERPRISE INFORMATION SYSTEMS VI
structures that are difficult to change, so they may
have more influence on both the architecture and on
the business structure itself than in the ideal case.
The fundamental principle is that the three structures
align.
As an aside, it is instructive to consider one
popular example of misalignment: that which results
from geographically distributed development or
outsourcing. Geographically distributed development
comes about from internal business concerns,
history, corporate acquisitions and partnerships, and
sometimes from simple politics. It suggests a set of
structures and patterns that can be arbitrarily
different from the core structures of the business.
Geographic boundaries are among the most difficult
ones to change: distance is a compelling force in
any joint endeavour. This is the great risk of
geographic distribution and outsourcing. (Several of
our organizational patterns address this problem by
insisting that the geographic structure follow the
business structure: e.g., ORGANIZATION FOLLOWS
LOCATION and ORGANIZATION FOLLOWS MARKET
are two such patterns.)
Software engineering—true to its name—usually
views these as technological issues. It is true that
technology opens new doors of opportunity in
design. However, technology more often serves as a
medium rather than as a form. While it extends the
range of design into more useful and beautiful
forms, it also extends the range of design in the other
direction. Alexander notes that modern building
technology has given us power to set our intuition
aside and to build horrid structures. These structures
lack the differentiation that owes to human design.
Just as modern technology allows us to build
buildings that appear to express art for its own sake,
rather than for the sake of function, so modern
software design technologies encourage us to use
methodologies or design fads which rarely can be
justified in terms of their contribution to quality of
human life. Such benefits as are promised by these
technologies are usually taken at face value. They
usually relate more to near-term business
considerations such as time to market and
development cost, rather than to the amount of time
it will take the user to learn to use the program, or
the cost that the user will incur from the program’s
human/machine interface inefficiencies. Just as
modern technology allows us to build ugly
buildings, modern methods, languages, and GUIbuilders
allow us to build astonishingly ugly
software.
4 ENTERPRISE-LEVEL HUMAN-
CENTERED DESIGN
Software development culture is entering a phase
where it is recognizing the importance of the human
element. Much of the realization comes with
widespread frustration with widely used software
platforms. It was this notion of human-centred
design that was at the heart of the Macintosh project
at Apple, which in retrospect proved to be a leader in
the way it gave stature to human concerns in the
human interface.
This is not uniquely a human interface concern.
Raskin (Raskin 2000) notes that computing is all
about supporting the users’ conceptual model of
their workflows. Most of that relates to artefacts and
information that travels between people; it is all
about the structure of the users’ organization. Beyer
and Holtzblatt’s great, common sense book (Beyer
Holtzblatt 1999) on software design tells us how to
build these conceptual models: Go and sit with your
users and, as Yogi Berra would say, you can observe
a lot just by watching.
The great folks of software have recognized for
years that understanding the structure and behaviours
of the organizations that use software and
the people they comprise can lead to great design
(e.g., Weinberg 1980). However, the human agenda
never seemed to take root. Through the 1970s and
1980s, any human revolution in software seemed
elusive.
This perspective took on new life in the early
1990s when eight leaders of the object-oriented
programming community came together in a
meeting in Colorado to ponder why object-oriented
development hadn’t delivered on its promises of
reuse and productivity. Their conclusion was that
object orientation had been ignoring the
relationships between objects, and that programming
had become a dehumanized industry. If you believe
Conway’s Law, and map the object-to-object
relationships onto the groups of people that program
those objects, the problem again reduces to
organizational structure. That meeting crystallized
the software pattern discipline.
Most early patterns from this discipline
continued in the computer science tradition of
software architecture: focusing on recurring
structures within the software itself. But a small
number of people took the next step to articulate
patterns in the organizations that create or use this
software, and suggested focusing on that structure to
cure software ills. Those works included Norm
Kerth’s Caterpillar’s Fate (Kerth 1995), Bruce
Whitenack’s RAPPeL (Whitenack 1995), and a
collection of so-called Development Process