Using Activity Domain Theory for Managing Complex Systems Premier Reference Source 1st Edition Lars Taxen - Own the complete ebook with all chapters in PDF format
Using Activity Domain Theory for Managing Complex Systems Premier Reference Source 1st Edition Lars Taxen - Own the complete ebook with all chapters in PDF format
com
https://ebookgate.com/product/using-activity-domain-theory-
for-managing-complex-systems-premier-reference-source-1st-
edition-lars-taxen/
OR CLICK BUTTON
DOWLOAD EBOOK
https://ebookgate.com/product/machine-learning-for-human-motion-
analysis-theory-and-practice-premier-reference-source-1st-edition-
liang-wang/
ebookgate.com
https://ebookgate.com/product/agile-technologies-in-open-source-
development-premier-reference-source-1st-edition-barbara-russo/
ebookgate.com
Symmetrical Analysis Techniques for Genetic Systems and
Bioinformatics Advanced Patterns and Applications Premier
Reference Source 1st Edition Sergey Petoukhov
https://ebookgate.com/product/symmetrical-analysis-techniques-for-
genetic-systems-and-bioinformatics-advanced-patterns-and-applications-
premier-reference-source-1st-edition-sergey-petoukhov/
ebookgate.com
https://ebookgate.com/product/interactive-multimedia-music-
technologies-premier-reference-source-1st-edition-kia-ng/
ebookgate.com
Lars Taxén
Linköping University, Sweden
Copyright © 2010 by IGI Global. All rights reserved. No part of this publication may be reproduced, stored or distributed in
any form or by any means, electronic or mechanical, including photocopying, without written permission from the publisher.
Product or company names used in this set are for identification purposes only. Inclusion of the names of the products or
companies does not indicate a claim of ownership by IGI Global of the trademark or registered trademark.
T57.6.T39 2010
384.01'15--dc22
2009038606
All work contributed to this book is new, previously-unpublished material. The views expressed in this book are those of the
authors, but not necessarily of the publisher.
Table of Contents
Foreword ............................................................................................................................................viii
Preface ................................................................................................................................................... x
Section 1
The Practical Trail
Chapter 1
The Dawn of the Activity Domain Theory .......................................................................................... 1
A Pattern Emerges (1990-1995) ........................................................................................................ 2
Coordinating Incremental Development (1996-1997) ....................................................................... 8
Termination and Despair (1998)...................................................................................................... 14
Renewal in Conflicts: The Pioneering S-Domain (late 1998-1999) ................................................ 16
Other Practices Catch On (2000) .................................................................................................... 22
A Central Concern: The C-Domain (late 2000-2001) ..................................................................... 24
From Federalism to Monarchy (2002)............................................................................................. 26
References ........................................................................................................................................ 27
Endnotes........................................................................................................................................... 28
Chapter 2
Reflections ............................................................................................................................................ 30
Analysis of the Framework Trajectory ............................................................................................. 30
The Broader Scope ........................................................................................................................... 35
Insights and Needs ........................................................................................................................... 41
The Practical Trail: Summary ......................................................................................................... 49
References ........................................................................................................................................ 50
Endnotes........................................................................................................................................... 50
Section 2
The Theoretical Trail
Chapter 3
The Philosophical Roots ..................................................................................................................... 53
Praxis ............................................................................................................................................... 54
The Dialectical Relation .................................................................................................................. 55
The Epistemology of Praxis ............................................................................................................. 57
The Dialectical Method.................................................................................................................... 59
References ........................................................................................................................................ 62
Endnotes........................................................................................................................................... 64
Chapter 4
Activity Theory.................................................................................................................................... 65
The Concept of Activity .................................................................................................................... 65
Mediation ......................................................................................................................................... 67
Meaning ........................................................................................................................................... 71
The Theoretical Trail: Summary ...................................................................................................... 73
References ........................................................................................................................................ 73
Section 3
The Activity Domain Theory
Chapter 5
The Constitution of the Activity Domain .......................................................................................... 78
Aspects of the Activity Domain ........................................................................................................ 80
The Congruence of Mind and Activity ............................................................................................. 87
The Activity Modalities .................................................................................................................... 89
Mediational Means and Activity Modalities .................................................................................... 98
References ...................................................................................................................................... 102
Endnotes......................................................................................................................................... 107
Chapter 6
Cognitive Grounding ........................................................................................................................ 108
The Gärdenfors Model of Cognition .............................................................................................. 108
The Linguistic Stratum ................................................................................................................... 113
The Conceptual Stratum ................................................................................................................ 118
The Neuropsychological Stratum ................................................................................................... 119
References ...................................................................................................................................... 122
Endnotes......................................................................................................................................... 124
Chapter 7
Operationalizing the Theory ............................................................................................................ 125
The Information Model .................................................................................................................. 126
The Process Model ......................................................................................................................... 128
The Stabilizing Core....................................................................................................................... 129
The Transition Model ..................................................................................................................... 129
The Coordination Information System ........................................................................................... 130
The Domain Construction Strategy ............................................................................................... 131
References ...................................................................................................................................... 133
Endnote .......................................................................................................................................... 134
Chapter 8
Positioning Against Other Theories................................................................................................. 135
Complex Systems Theory and ADT ................................................................................................ 135
Practice-Based Theories and ADT ................................................................................................ 142
Evaluation of Each Approach ........................................................................................................ 144
Evaluation Against the Activity Domain Theory............................................................................ 152
References ...................................................................................................................................... 156
Endnotes......................................................................................................................................... 161
Chapter 9
The Practical and Theoretical Trails in Hindsight......................................................................... 162
Recapitulation of the Practical Trail ............................................................................................. 162
Recapitulation of the Theoretical Trail .......................................................................................... 163
The Activity Domain Theory: Summary ......................................................................................... 163
Tracing the Activity Domain Theory to its Empirical and Theoretical Roots................................ 165
References ...................................................................................................................................... 167
Endnote .......................................................................................................................................... 167
Section 4
Implications
Chapter 10
The Anatomy-Centric Approach Towards Managing Complex Projects .................................... 169
From Waterfall to Increments ........................................................................................................ 170
The Anatomy .................................................................................................................................. 172
On Architectures ............................................................................................................................ 175
The Anatomy-Centric Approach..................................................................................................... 178
Implications.................................................................................................................................... 182
Anatomy-Centric Agile Development of Software ......................................................................... 192
The Gist of the Anatomy-Centric Approach ................................................................................... 199
The Anatomy-Centric Approach: Summary ................................................................................... 205
In Conclusion ................................................................................................................................. 207
References ...................................................................................................................................... 207
Endnotes......................................................................................................................................... 211
Chapter 11
Enterprise Architectures: An Alternative View.............................................................................. 213
Why Enterprise Architectures? ...................................................................................................... 214
Analysis of the Zachman Framework from the Activity Domain Theory Perspective ................... 216
Implications: Enterprise Architectures .......................................................................................... 221
Operationalization ......................................................................................................................... 235
Enterprise Architectures: Summary ............................................................................................... 238
References ...................................................................................................................................... 238
Endnotes......................................................................................................................................... 241
Chapter 12
Product Lifecycle Management Revisited ...................................................................................... 242
A Definition of PLM ....................................................................................................................... 244
Operationalizing PLM: The Activity Domain Theory Perspective ................................................ 249
Implications.................................................................................................................................... 255
Product Lifecycle Management: Summary .................................................................................... 260
References ...................................................................................................................................... 261
Endnote .......................................................................................................................................... 262
Chapter 13
Alignment: The Activity Domain in the Centre ............................................................................. 263
Definitions ...................................................................................................................................... 265
Reconstruction of Strategy Alignment............................................................................................ 266
Alignment from the Activity Domain Theory Perspective .............................................................. 267
Operationalization ......................................................................................................................... 270
Empirical Grounding ..................................................................................................................... 270
Implications.................................................................................................................................... 274
Alignment: Summary ...................................................................................................................... 283
References ...................................................................................................................................... 283
Endnotes......................................................................................................................................... 286
Chapter 14
In Search of an Integrating Construct ............................................................................................ 287
Business Process Reconstruction ................................................................................................... 289
From Information System Development to Domain Construction................................................. 295
Conclusions: The Activity Domain as an Integrating Construct ................................................... 300
References ...................................................................................................................................... 301
Endnote .......................................................................................................................................... 303
Chapter 15
In Conclusion..................................................................................................................................... 304
The Activity Domain as an Integrating Construct ......................................................................... 306
Communal Meaning to the Forefront............................................................................................. 306
The Activity Modalities: Bridging Individual Cognition and Social Reality ................................. 306
Pay Heed to the Unity of Opposites ............................................................................................... 307
Concluding Words .......................................................................................................................... 308
References ...................................................................................................................................... 309
Foreword
“Why make it simple when you can do it so beautifully complicated?” This answer to a student is at-
tributed to one of the classical German philosophers of the 19th century. Some readers may think that
the author of this book would reply in a similar way. The theoretical discourse of this book, which is
partly inspired by some of these philosophers, is indeed a tough piece of cerebral aerobics. However, it
results in the wonderful simplicity of understanding complex issues, which makes the reader feel amply
rewarded.
Mastering the mindboggling complexity of creations such as modern telecom systems can not rely
on shortcuts and silver bullets. On the basis of extensive professional experience and reflection the
author convincingly demonstrates that coordinating the development of such systems needs to build
on well-grounded theories and thoughtful application. The successful development and diffusion of the
“anatomic-centric” approach to project coordination within the Ericsson telecommunications company,
where the author was so deeply involved, testifies to the importance of this contribution.
In the area of complex systems development, thoughtful project management is a key factor for
innovation, for bringing together system capabilities to actually working systems and for taking them
to the customer. The critical question then is: How can managers and practitioners conceptualize and
understand the central ingredients of successful project management in this and similar fields? In the
extant literature there is a plethora of tools for advanced planning and scheduling, for system decomposi-
tion and modularization, for reducing interdependencies and avoiding errors. But there is also a growing
criticism of these approaches. A number of these studies have criticized mainstream models of project
management for an over-emphasis on the role of planning and scheduling and highlighted the need for
developing models that take into account the need for flexibility and adaptability. These studies have
singled out the importance of fitting project management to the situation and working out contingency
formulae as critical for firm-level competitive advantage. This critique, however, tends to be overly
general in character and lack grounded suggestions for effective managerial practices and coordination
mechanisms which are needed to make complex system development at all possible.
This work pursues a different route, different both from the traditional planning road, and the alter-
native “flexibility” route, where everything is open for negotiation. By applying rigorous theoretical
analysis it brings a new depth to the art and science of complex system development in general and to
project management practices in particular. As the author forcefully argues, nothing is as practical as a
good theory. The theories discussed and analyzed here do indeed lead to very practical results such as
new forms of representing and expressing interdependencies, new means of creating shared understand-
ing, new ways of communicating system characteristics and integrating complicated project activities
into systems which function as predicted and can be delivered as promised.
ix
The reader is invited to a rewarding ride through research and experimentation, ending up in highly
useful new insights.
May 2009
Christian Berggren
Professor in Industrial Management & Program Director for KITE – Knowledge Integration & Innova-
tion in Transnational Enterprises
Linköping University, Sweden
Christian Berggren is Professor in Industrial management at the University of Linköping, Sweden and director for the
KITE research program, Knowledge Integration and Innovation in Transnational Enterprise (http://www.liu.se/kite). Chris-
tian Berggren has published extensively on innovation and project management within the automotive, electro-technical and
telecommunications industries. His recent papers include ”The integrator´s new advantage - reassessing outsourcing and
production competence in the global telecom industry”, European Management Journal, 2008, 26, 5, 314-324; “Technological
capabilities and late shakeouts: Industrial dynamics in the advanced gas turbine industry”, Industrial and Corporate Change,
2008, 17, 335-392; ”Lagomizing, Organic Integration, and Systems Emergency Wards: Innovative Practices in Managing
Complex Systems Development Projects, Project Management Journal, 2008, 39, S111-S122 and “Rethinking Project Man-
agement Education: Socials twists and Knowledge Co-production”, International Journal of Project Management, 2008, 26,
3, 286-296. Berggren´s current research focuses on the role of knowledge integration capabilities for realizing innovative
solutions by combining complex technologies.
x
Preface
The sociologist Kurt Lewin once said that “there is nothing so practical as a good theory”. As a general
motto, this view is no doubt acknowledged among practitioners and academics. Industrial accomplish-
ments should be informed by insightful theories that in turn may be further elaborated from practical
experience.
However, when taking a closer look at how this motto is practiced in industry and academia, things
become more intricate. My experience, as someone who has spent many years in both camps, is that
theories are still by and large the concern of academia, and practice the concern of industry. When
academia approaches practice, it is usually after something interesting has taken place in industry. For
example, the emergence of Enterprise Resource Planning (ERP) systems took place several years before
academia began researching this major upheaval in organizations. Moreover, the main knowledge interest
is to explain the ERP phenomenon using various informing theories. Accounts for the use of theories to
influence the trajectory of ERP systems are rare in academia.
From the other vantage point, industry shows limited interest in theories unless they give immedi-
ate pay-back in ongoing development tasks. As early as 1995, David Parnas expressed concerns about
software engineering conferences:
The sad fact is that most Engineers actually writing code do not come to these conferences. They also
do not read IEEE Transactions on Software Engineering. However, if we want to influence the way that
software is written, we have to admit that we are doing something wrong. (Parnas, 1995, p. 30)
Unfortunately, we still seem to be doing something wrong. Industry feels that academic research is
irrelevant since – so it is believed – academia has no real understanding of the magnitude and complex-
ity of the practical challenges industry is facing. Practical applications emanating from theories used
in academia are mostly seen as vehicles for advancing theory development and thus of little relevance
to practitioners.
In contrast, the message of this book is that theories can indeed make a difference in demanding
practical settings. The book communicates a story where theory and practice mutually have influenced
each other. The theory is what I have coined the Activity Domain Theory (ADT), and the practice is the
development of telecommunication systems at Ericsson, a major supplier of telecommunication equip-
ments all over the world.
The subject area of the book is, as the title indicates, the interplay between coordination, complex
projects and ADT. The motivation for focusing on this arena is as follows. Our technological capabilities
to develop products have increased dramatically. This enables us to produce ever more complex systems
like telecom networks, airframes, cars, weapons systems, and so on. The complexity is augmented by the
many different types of technologies used; in particular the increasing utilization of embedded control
software.
xi
However, our ability to cope with the complexities that these technological developments raise has
not increased at the same pace. There is a gap between the possibilities that technology offers us and
our capability to take advantage of this development. This is perhaps most evident in, for example, the
poor track record of developing large software systems. The Standish Group classifies such projects
as successful, challenged and failed. Although there has been some increase in the rate of successful
projects, still in 2001 about half of the projects were considered challenged, i.e. completed with overrun
budget, over the time estimated, and with fewer functions than specified (Standish Group, 2001). 23%
of the projects were outright failures and only 28% were considered successful. Thus, there is an urgent
need to improve the track record of complex projects.
Coordination is at the heart of complex system development since such endeavors are possible only
by the purposeful coordination of socially organized work. There is a pressing need to understand the
nature of coordination in order to improve the way coordination is carried out. However, theoretical efforts
to define coordination (e.g. Kraut & Streeter, 1995; Malone & Crowston, 1994) seldom reach into the
unruly domains of industrial practice. When things become concrete and detailed, esoteric and abstract
theories will come off badly. Thus, the focus on coordination is motivated by the need to operationalize
this concept, i.e., to make it useful in practice.
Why do we need to theorize about coordination? After all, well-working and efficient products appear
on the market at an ever increasing pace. It seems that industry is doing pretty well without dwelling
into intricate theories. However, the story of failed and target overrun projects shows that things are not
all that well. Either we take the position that such failures are inevitable, considering the magnitude and
complexity of these projects, or we seek to improve the way we run our projects guided by, hopefully,
well-informed theories.
As many other scholars, I am convinced that the root cause of failed projects are to be found, not
primarily in the complexity of the technology, but in our social and cognitive capabilities to manage the
complexity of such projects. Social and cognitive aspects are inherent features of ADT, which implies
that this theory should be well armed to guide the coordination of complex development tasks. The rea-
son why I dare to state this rather bold claim is that I worked for more than 30 years in different roles
at Ericsson. This provided me with a down-to-earth appreciation of the concrete problems the develop-
ment of a telecom system poses. Rather late in my professional life I spent ten years at the university,
first as a Ph.D. student and later as an associate professor. This enabled me to reflect and theorize about
my experiences from Ericsson. In this sense, the book is a synthesis of a personal meandering between
practical and theoretical camps, something that should provide a good basis for practical theory devel-
opment. It is up to the reader to judge whether I have succeeded.
The telecommunication industry in general and Ericsson in particular can be seen as a paradigmatic
example of the complexity many product development organizations face today. The ensemble of tele-
communication systems has been called the world’s largest machine; an immense network of interacting
nodes, each performing some kind of utility like setting up calls, keeping track of the position of a mobile,
providing charging functions, etc. The network is constantly evolving. New types of services such as live
TV directly in the mobile are implemented as the capacity of the network increases. In addition, there
is a legacy of existing equipments and networks that must be considered when making changes in the
network. Another source of complexity is the many different technologies used such as radio, software,
hardware, mechanical, and optical ones.
xii
Figure 1. An integration plan of one node in the 3rd generation of mobile systems (Taxén & Svensson,
2005. Used with permission)
In the telecommunications market there is a fierce competition among systems providers like Erics-
son, Nokia™ and others. This competition has been heightened by the deregulation, leading to volatile
requirement specifications of systems and pressure to shorten lead-times and costs. In addition, frequent re-
organizations are carried out such as outsourcing, acquisitions, and the establishment of partnerships.
As an example of the complexity underlying a mobile phone call we may take a look at the image in
Figure 1. The image, which should be read from top to bottom, is called an “integration plan”. It is used
as an instrument for coordinating development tasks (square white boxes) in one of the nodes in the
network. Each task, which is called a “work package”, provides a specific functionality to the node. The
thin lines mark dependencies between the packages, indicating which packages must be ready in order
for other packages to function properly. Thick arrows show the datum for integration and verification
of the packages. Small dots indicate the status of a package such as “in design”, “in test”, “delayed”,
“ready”, etc. The ovals signify basic services like registering the location of the mobile, calling the
mobile, answering a mobile call, etc. In most cases the functionality is provided by software, where the
total number of source code lines may be in the order of millions. In other cases, complex integrated
hardware chips are used. The project may take more than a year to execute and can involve several
thousand persons at development sites all over the world.
It is beyond doubt that the coordination of projects like the one in Figure 1 is a challenging task that
needs to be supported by information systems (ISs). In order to implement such systems, there must be
a sufficient consensus of how coordination should be conceived. At a general level, it is fairly easy to
agree about what coordination items like, for example, a requirement is. However, as the level of detail
increases, disagreements begin to surface. How should a requirement be identified? What kind of status
values does a requirement have? What attributes characterize a requirement? How should requirements be
related to other things such as customers, products, test cases, etc? In fact, the experience from Ericsson
testifies that attaining common understanding about coordination is an overwhelming endeavor that takes
precedence over other tasks. How to accomplish this endeavor is the recurrent theme of this book.
xiii
The emergence of ADT can be seen as a result of two “trails” that met around 1998: a practical and a
theoretical one. The practical trail provided me with a thorough understanding of the immense problems
of coordinating huge, globally distributed development projects. The theoretical trail rendered me with
theoretical instruments by which the practical experiences could be understood and subsequently be
reflected back into guidelines for improving practice.
The molding of the practical trail occurred roughly between the late 1990s and 2003 when Ericsson was
involved in the transition from the 2nd to the 3rd generation of mobile systems. This was a major challenge
for Ericsson. In order to meet these challenges, Ericsson worked out a development method, which I
will refer to as the anatomy-centric approach throughout this book. The origin of this approach dates
back to the early 1990s, when Ericsson was involved in delivering the 2nd generation mobile systems to
the Japanese market. The method wandered back and forth over many years in the company, sometimes
heavily used, and sometimes more or less forgotten until it became compulsory for it to be used in all
subprojects in the 3G development.
The anatomy-centric approach put quite new demands on the management and coordination of the
3G projects. One of the most critical tasks was to make sure that work packages implementing vari-
ous functionalities were designed, tested and delivered to system integration according to the project
plan. Typically, between 5,000 to 10,000 items needed to be managed with respect to revision, status,
dependencies, etc.
In 1996 I was taking part in a work aiming at supporting the coordination of anatomy-centric projects.
Early on, it was clear that specific IS support had to be developed for such projects. I became respon-
sible for the pre-studies and subsequent implementation of such a system at a site in Stockholm. In early
1996 I happened to meet a lonely looking salesman at a construction fair. It turned out that the salesman
was the retailer for Matrix, a Product Data Management system that was then fairly new on the market
(MatrixOne, 2008). He showed in a couple of minutes the ease by which a particularly demanding data
model construct could be implemented in Matrix. I became impressed with this demonstration, and
managed to persuade Ericsson to take a closer look at this system. The system turned out to have the
qualities we wanted, above all ease of changing the implementation.
During 1997, Matrix was prototyped in some pilot projects and 1 May 1999, the first usage of Matrix
in the 3G projects was a fact. This was the start of an astonishing development. Between 1999 and 2003
other projects followed, both at Stockholm and other Ericsson sites. At its peak, around 140 projects and
subprojects were using similar, albeit distinct, applications built on the same Matrix IS platform.
A striking feature of the coordination support developed was the establishment of separate applications
built on Matrix at different sites. Although each application turned out to provide highly efficient coordi-
nation support, they were completely differently constructed, both in terms of information managed and
functionality offered. There was no apparent reason why they should differ, since all sites were engaged
in the same 3G development enterprise. However, any attempts to consolidate the applications more or
less failed. This and other equally perplexing experiences make up the substance of the practical trail.
xiv
The origin of the theoretical trail can be traced back to a long personal interest in philosophy in general
and in dialectical thinking, the Marxian concept of praxis, semiotics, and meaning in particular. With
such a backpack it was near at hand to reflect on the daily practice where I spend most of my working
hours. The philosophical “spectacles” enabled me to see taken-for-granted values and conceptions from
other perspectives. For example, an outspoken value at Ericsson was to “develop what the customer
requires”, or – expressed differently – “The customer is always right”. The problem, however, was that
the customer seldom knew precisely what he wanted and often changed his mind in the midst of the
development of a particular system. It appeared to me that the real process was much more interactive
and dynamic than expressed by prevailing tenets. Customer and supplier together worked out a common
view of the system, sometimes in conflict but more often in cooperation.
So, the theoretical trail had to some extent been cleared alongside with my practical, daily work.
However, this trail would have remained dormant if it hadn’t been for a company controversy over the
choice of the Matrix system. The Corporate IT organization at Ericsson stipulated the use of another
system, which however did not have the necessary capabilities – above all flexibility to change the
implementation in an easy and straightforward way.
The controversy over the platform intensified during 1998, and at a certain point in time, Matrix
was on the brink of being thrown out in favor of the corporate system. Along with that my ideas and
the promising results we had achieved so far would disappear. In order to save this work I turned, more
or less in despair, to Linköping University with a research proposal. After some initial hesitation, the
proposal was accepted, and so my academic career started, rather late in life – I was 54 years old then.
At that point I was quite convinced that a promising initiative to improve coordination support was for
ever gone. However, in May 1998, the project manager for one 3G project got interested in our prototype
and decided to use this in his project. From that moment on, the tide changed and Matrix became a key
component in the 3G development endeavor.
Thus, I could elaborate the theoretical trail alongside my work at Ericsson until 2003 when I was
required to leave the company together with many others as a result of the telecom crisis. So, from that
moment the practical trail faded away while I could continue to refine the theoretical trail in my research.
In retrospect, the constellation of idiosyncratic circumstances that gravitated around 1998 seems almost
inconceivable. The transition from 2G to 3G at Ericsson, my position as responsible for the IS support
in one project, the encounter with the Matrix platform, the conviction and support of a single project
manager, my interest in philosophy – all these elements coincided in time and space to form the backbone
of the ADT-approach and consequently the material for this book.
There is no lack of theories that address social and technological issues. This is perhaps most evident
in researching ISs. For example, the Association for Information Systems provides a list of more than
50 theories used in IS research (IS theories, 2008). So, why bother about yet another theory? The main
reason, I believe, is that ADT differs in some crucial aspects from most other theories proposed.
• ADT originated and evolved within the telecom industry. Thus, it has been sculptured from and
scrutinized by concrete industrial needs. Most other theories originate from outside the industry,
and are appropriated or adjusted to fit the particular circumstances of that industry. For example,
xv
the Actor Network Theory (e.g. Latour, 1992) originated in social sciences and has been used by
a number of researchers to analyze the impact of ERP-systems.
• ADT is operational in industrial settings. By operationalization, I mean that the theory can be
expressed in elements that can be manipulated, measured or observed in a particular situation in
order to influence this situation. This means that the theory is indeed “practical” in the sense that
Kurt Lewin meant.
• A common thread in ADT is the concept of meaning. Meaning is considered intrinsically related
human action, and only meaningful sensory impressions can be informative and acted upon. Con-
sequently, a key issue in coordinating human actions is the construction of common understanding
about how coordination should be conceived.
• The focus on meaning implies that human cognition plays an important role in ADT. A key tenet
in ADT is that the properties of human cognition constitute the way we apprehend our socially
constructed reality.
• ADT states that common understanding is constructed in the social practices (e.g. Schatzki, Knorr
Cetina, & von Savigny, 2001). A practice has been defined as a coherent set of human actions
characterized by a commonly understood object towards which coordinated actions are directed
(Wartofsky, 1987).
• The inclusion of both human cognition and social practices means that ADT integrates individual
cognition, social organization and technological-material aspects of human action into a coherent
whole.
These features are reflected in the structure of ADT. Its key construct is the activity domain, which
can be seen as a particular form of social practice where coordinating aspects are at the fore. The mo-
tivation for the existence of the activity domain is that it supplies products or services that meet some
social need. In order to do so, the actors in the domain work on some work object, the outcome of which
fulfills the need.
The work object molds the inner structure of the activity domain, including the meaning actors as-
sociate with the object and other related items needed in order to produce the outcome. For example, the
activity domain of flying an airplane will differ quite radically from that of building a house in terms of
what the work object is, what things are important, what methods work or don’t work, what rules and
norms are valid, what tools or instruments are used, etc.
In spite of the different realities constructed in activity domains, ADT claims that certain deep
structures coined activity modalities, can be found in every domain. These modalities denote cardinal
dimensions along which meaning is constructed, and they can ultimately be traced back to the way our
cognitive system works. Stated differently, ADT claims that the social reality constructed in activity
domains reflects the way we as humans apprehend the world. For example, since our minds discern a
temporal dimension, we create “temporal” artifacts like calendars and clocks that help us to coordinate
our actions.
From the background sketched in the previous sections, it is relatively straightforward to organize the
book in four parts, each consisting of a number of chapters (see Figure 2). The practical and theoretical
trails leading up to the ADT are described in Section 1 and Section 2 respectively. These parts should be
xvi
read as paving the way for the ADT, which is presented in Section 3. Section 4 discusses implications
of the theory in a number of areas, with a focus on the coordination of complex systems. With that a full
circle is closed and we may approach practice and theory with, hopefully, some new insights.
Stakeholders
Since the book aims at a balanced approach between theory and practice, the following main stakeholder
groups can be identified:
• The P-type: “Just do it.” This group consists of action oriented practitioners, people that consider
theories as irrelevant for achieving results. Research carried out at universities is regarded with great
suspicion by the P-type person: nothing practical ever comes out of the ivory towers in academia.
• The Pt-type: “What’s happening here?” This group includes practitioners that reflect on what they
are doing and try to find ways to improve practice. Innovative new products and methods often
emerge from this group. Still, these innovations occur outside academia; there is no or little interac-
tion with research.
• The Tp-type: “Can my theory make an impact in practice?” Here we find theoreticians with a prac-
tical inclination; persons in academia active in applied sciences such as IS development, computer
science, software engineering, etc. These persons want theories to be relevant for practice. However,
practical applications developed are mostly used as means for theory development, and these ap-
plications are in general less complex compared to ones found in product-developing industries.
• The T-type: “I think, therefore I am.” In this group we find theoreticians without any practical ap-
plication in mind. Practice is regarded as dirty business that should not ever be let inside the academic
fortress. This group corresponds to the P-type group in industry; no interaction whatsoever between
academia and industry is the basic attitude.
• The PT-type: “Practice and theory are two sides of the same coin.” Persons in this group are, I
dare say, quite rare today. They combine the interests of the Pt and Tp person types.
xvii
I foresee that people from these, admittedly caricatured, groups will be interested in different parts
of the book as follows.
Relates the empirical background of the ADT. The stakeholder focus for Section 1 is on the P and Tp
type of stakeholders (see Figure 3). Practitioners may be interested in how the coordination of the 3rd
generation of telecom systems occurred at Ericsson; what kinds of obstacles had to be overcome and
what results were obtained. This part should also be of interest to theoreticians who are interested in
how a theoretical understanding might grow out of practical experiences rather than from appropriation
of other theories for practical purposes1.
The chapters in Section 1 are as follows.
Reflections
Attempts to make sense of the events reported in the previous chapter. Reports on other observations
collected over many years at Ericsson that contributed to the formation of ADT. These observations
concern the dilution of the business process concept; the difficulties of establishing common vocabulary
in information modeling projects; the chaotic IS/IT architecture in the organization; and the fragmented
responsibilities of processes, information architectures, IS/IT and business rules, resulting in glitches
between these areas. Summarizes the insights and needs from the practical trail:
xviii
• Common understanding: The 3G development experience made it painstakingly clear that achiev-
ing common understanding is a difficult task that is easily overlooked. Thus, a methodical way of
addressing this issue should be up front on the agenda.
• Integrating construct: Many observations pointed to the need of some organizational construct
that could integrate elements like IS/IT, business processes, information structures, and corporate
business rules. Taking one of these elements, for example, business processes, as the basis for organi-
zational analysis and change initiatives appeared to be insufficient since all elements obviously were
interdependent and, consequently, could not be sensibly treated one at a time. Gradually, an insight
grew that some kind of practice construct (e.g. Schatzki, Knorr Cetina, & von Savigny, 2001) was
a viable candidate for this purpose. The practice idea was later elaborated into the activity domain,
which subsequently became the integrating construct in ADT.
• Contextualization: Other observations indicated that situational and contextual aspects must be
given more attention in the organizational discourse. This was most conspicuous during the 3G
development, where different sites developed site-specific coordination support applications; each
of which provided previously unmatched IS support. Thus, by delimiting the scope of commonality,
it seemed that the efficiency of IS application development tasks increased dramatically.
• Recurrent patterns: A closer look at the most frequent organizational artifacts indicated that these
were manifestations of more basic, underlying patterns that appeared over and over again. These
patterns came across as being of separate kinds but nevertheless interdependent and mutually
constituting each other. Subsequently, these patterns were elaborated into the activity modalities in
ADT.
• Enactment: Organizational artifacts must be what Orlikowski (2000) calls enacted in order to
become useful in a particular organization. The enactment view “starts with human action and
xix
examines how it enacts emergent structures through recurrent interaction with the technology at
hand” (Orlikowski, 2000, p. 407). Some experiences made me aware of the fact that the histori-
cal development of organizational artifacts like information models, process models, etc., must be
taken into account. Not until these artifacts are regarded in a historical perspective, is it possible to
appreciate the enactment efforts behind their particular appearance at a certain moment in time.
Describes the theoretical roots of the ADT. The focus of Section 2 is on the Pt and T type of stakeholders
with a focus on the T-type (see Figure 4). Obviously, theoreticians will have an interest in the theoreti-
cal background of ADT. However, I also want to address practitioners with a reflective mind, primarily
through examples from everyday life and industrial settings.
The chapters in Section 2 are as follows.
Activity Theory
Reviews three additional cornerstones for ADT from the Russian theory of Activity (AT) (e.g. Kaptelinin
& Nardi, 2006): the concept of activity (frames the context in which individual actions are meaningful),
the concept of mediation (humans always put something between themselves and their object of action),
and the AT view on meaning (how we make sense of reality).
Provides an account of the ADT as a synthesis of the empirical and theoretical trails, and conceptualizes
ADT as an elaboration of AT where coordination is in focus. Describes the activity domain as a work
setting (team, group, business unit, etc.) whose existence is motivated by its capability to produce some
outcome. The outcome is achieved through the actions of socially organized actors, who transform a
work object into the outcome. The outcome of one domain may be the prerequisite for another domain,
which means that the activity domain construct is recursive and scalable.
In order to transform the work object, actors enact resources consisting of means and skills. Enact-
ment in the context of ADT refers to the fact that the potential capabilities of means become resources
only when actors have drawn these into the social fabric of the activity domain, and collectively learnt
how to use them. Thus, capabilities of means and actors must always be related to the work object and
motive in order to become useful resources in the domain.
A key tenet in ADT is that society as constructed in human activity reflects or is congruent with the
structure of the human cognitive system. A corollary of this tenet is that humans have innate capabilities
to coordinate their actions. These capabilities are characterized by the activity modalities contextual-
xx
ization, spatialization, temporalization, stabilization, and transition. Modalities are manifested both as
societal imprints in the form of artifacts, institutions, norms, etc., and as individual, cognitive imprints
in the human mind and body. For example, a coordinative means like a calendar is a manifestation of
the temporalization modality. In order to become a coordinative resource, however, actors must learn to
use it and interpret it in a common way.
An important consequence of the ADT perspective is that sense making is inherently related to the
activity domain. In other words, different activity domains enact by necessity different communal mean-
ings2 or taken-for-granted ideologies about what is meaningful.
The stakeholder focus of Section 3 is similar as for Section 2; however with more emphasis on the
Pt type since an important part of ADT is the operationalization of the theory (Figure 5).
The chapters in Section 3 are as follows.
Cognitive Grounding
Reviews indications from cognitive neuropsychology and linguistic sciences that support the claim of
activity modalities as basic features of the human cognitive system.
Section 4: Implications
Reflects on implications of the ADT in various areas. Since Section 4 represents a synthesis of practical
and theoretical insights, stakeholders of the Pt and Tp types would be interested in this part. Moreover,
it is my intention that Section 4 will provide arguments for the need of true border spanners; PT actors
that combine deep practical and theoretical knowledge.
The chapters in Section 4 are as follows.
each manifests a dominant modality: spatialization (the anatomy), transition (the increment plan) and
temporalization (the integration plan). Discusses implications of this observation for the coordination
of complex projects.
In Conclusion
The concluding chapter. Describes the book as a parable from practice over theory development and back
to practice with the theory as a new guiding lens. Summarizes the main messages of the book: the activity
domain as an integrating construct, communal meaning to the forefront, the activity modalities – bridging
individual cognition and social reality, paying heed to the unity of opposites. Concluding words.
references
Giddens, A. (1984). The Constitution of Society: Outline of the Theory of Structuration. Los Angeles:
University of California Press.
IS theories (2008). Theories Used in IS Research. Wiki, Retrieved Sept 21, 2008, from http://www.fsc.
yorku.ca/york/istheory/wiki/index.php/Main_Page
Jones, M., & Karsten, H. (2008). Giddens’s Structuration Theory and Information Systems Research.
MIS Quarterly, 32(1), 127–157.
xxiii
Kaptelinin, V., & Nardi, B. (2006). Acting with Technology - Activity Theory and Interaction Design.
Cambridge, MA: The MIT Press.
Kraut, R., Streeter, L. (1995). Coordination in Software Development. Communications of the ACM,
38(3), 69–81.
Latour, B. (1992). Technology is society made durable. In J. Law (Ed.), A Sociology of Monsters. Essays
on Power, Technology and Domination (pp. 103–130). London: Routledge.
Malone, T., Crowston, K. (1994). The Interdisciplinary Study of Coordination. ACM Computing Ser-
vices, 26(1), 87–119.
MatrixOne. (2008). Retrieved Feb 2, 2005, from http://www.matrixone.com/index.html§
Orlikowski, W. (2000). Using Technology and Constituting Structures: A Practice Lens for Studying
Technology in Organizations. Organization Science, 11(4), 404–428.
Parnas, D. L. (1995). On ICSE’s ‘most influential’ papers. ACM SIGSOFT, 20(3), 29–33.
Schatzki, T. R., Knorr Cetina, K., & von Savigny, E. (Eds., 2001). The practice turn in contemporary
theory. London: Routledge.
Standish Group, Inc. (2001). Extreme Chaos. February 2001, The Standish Group. Retrieved from http://
www.standishgroup.com/
Taxén, L., Svensson, D. (2005). Towards an Alternative Foundation for Managing Product Life-Cycles
in Turbulent Environments. International Journal of Product Development (IJPD), 2(1-2), 24-46.
Wartofsky, M. (1987). Epistemology Historicized. In A. Shimony & D. Nails (Eds.), Naturalistic Epis-
temology (pp. 357–374). Dordrecht: Reidel.
Zachman, J. A. (1987). A framework for information systems architecture. IBM Systems Journal 26(3),
276–292.
endnoTes
1
This is a common procedure in the IS discipline. For example, Structuration Theory (Giddens,
1984) has been used extensively in IS research (e.g. Jones & Karsten, 2008).
2
I will use two expressions to denote meanings that in some sense denote common stock in a soci-
ety: “common understanding” as a practice oriented term and “communal meaning” as oriented
towards theory.
xxiv
Acknowledgment
This book is the result of an enduring educational journey, which has been swaying between the attrac-
tion points of a deep interest in philosophy, my work at the Ericsson™ telecommunication company and
my research at Linköping University. In a sense, I summarize my experience from a life-long career in
industry and academia. Accordingly, I have allowed myself to be generous with what material I have
included in the book. On the surface, issues like the philosophical question of what knowledge is, or
how the cognitive system of humans conceives signs may seem rather loosely related to, say, require-
ment management. However, it is my firm conviction that it is not until we reach an integrated view on
these seemingly non-related issues that we can truly address the extraordinary intricacies in managing
complex systems in which humans are parts.
As is evident from the outline of the book, my figurative journey proceeded along several trails.
The practical trail originates from 1968 when I started to work at Ericsson in Stockholm, Sweden. The
experiences gained there form the empirical foundation of the book. I am deeply grateful to Ericsson
for their overwhelming generosity in allowing me to use the detailed empirical material. Special thanks
go to my contact person, colleague, and friend at Ericsson, Sören Ohlsson, whose continual interest in
my results and life-long experience at Ericsson has been invaluable to me.
The theoretical trail originates from my personal interest in the praxis philosophy as interpreted by
the young Marx and Engels in the nineteenth century. This perspective formed a kind of background
fabric by which I reflected on what happened at Ericsson. This trail, no doubt, would have remained
dormant if I had not met professor Sture Hägglund at Linköping University in 1997. He looked at my
ideas over a cup of coffee, rubbed his chin and said: “Well, this might be something...”. Sture put me in
contact with my thesis supervisor Bengt Lennartson who has been my guide throughout my academic
career. His patient and thorough criticism and encouragement have kept me on track whenever I was
about to get lost at some interesting waterhole. Hail to you, Bengt!
The same goes for my other supervisors, Roland Ekinge at Whirlpool and professor Christian Berg-
gren. Roland, who always asked those provocative questions, which (hopefully) taught me to challenge
xxv
my own preconceptions and think instead of becoming defensive; Christian, with whom I often discussed
shaky thoughts on shaky trains between Linköping and Stockholm.
Perhaps the trickiest part of the theoretical trail was to stay clear of philosophical pitfalls. Oh, how
easy it is to get lost in a complete confusion here! “Philosophy is like trying to open a safe with a com-
bination lock: each little adjustment of the dials seems to achieve nothing, only when everything is in
place the door does open.” (Ludwig Wittgenstein). For their help in break open this safe I am deeply
indebted to two people: professor Göran Goldkuhl and Johan Schubert. Göran, whose graduate courses
and seminars together with his students provided me with countless occasions for discussion and reflec-
tion. Johan, with his long experience as an opponent and supervisor, was always there to inspire, read
and gently point out the flaws in my thinking. My special thanks also go to Joakim Lilliesköld for long,
interesting, and truly rewarding research collaboration over many years.
As all authors know, it is impossible to write a book in solitude. I would like to honor the publishing
team at IGI Global whose assistance throughout the writing process has been invaluable. Last, but not
least, I am deeply grateful to Stefan Torneld for scrutinizing my English with his Argus eyes, always
prepared to suggest corrections, alternatives, and improvements.
The practical and theoretical trails were eventually joined in the Activity Domain Theory, and from
this perspective, possible, unbeaten trails have been outlined for the management of complex systems.
With that, my final thoughts go to you who have been with me all the time: Tina for your ceaseless love
and endurance, my beloved children Kerstin and Gustav for your everlasting encouragement and read-
ings of the manuscript. And of course to Eva, my daughter-in-law and Anna and Erik, my grandchildren.
Perhaps the essence of the book is best expressed by Anna. When three years old, looking at a colored
version of the anatomy of the mobile switching center node in Figure 1, p. 13, she thought that the work
packages looked like “square clouds over an island in the sea.” Perhaps we should think about work
packages as square clouds. Or as my favorite philosopher, Karel Kosík, expressed it: “Familiarity is an
obstacle to knowledge.”
Lars Taxén
Tullinge, April 2009
Copyright Acknowledgments
I am truly grateful to the following copyright holders for permission to reproduce their material in the
book:
• Inderscience Enterprises Limited (www.inderscience.com): Figure 1, Figure 93, Figure 98, Fig-
ure 99, Figure 100, Figure 109, and Figure 110, which originally appeared in Taxén, L., Svensson,
D. (2005). Towards an Alternative Foundation for Managing Product Life-Cycles in Turbulent
Environments. International Journal of Product Development (IJPD), 2(1-2), 24-46.
• PICMET (http://www.picmet.org/main/): Figure 7, which originally appeared in Lilliesköld, J.,
Taxén, L., Karlsson, M., & Klasson, M. (2005). Managing complex development projects – using
the system anatomy. In Proceedings Portland International Conference on Management of Tech-
nology and Engineering, PICMET ’05. July 31st – Aug 4th, 2005, Portland, Oregon - USA.
xxvi
The dawn of the Activity Domain Theory: A pattern emerges (1990-1995). Coordinating incremental
development (1996-1997). Termination and despair (1998). Renewal in conflicts – the pioneering S-
domain (late 1998-1999). Other practices catch on – the C-domain (late 2000-2001). From federalism to
monarchy (2002). Analysis of the Framework trajectory. The broader scope: Business processes. Over-
loading the process concept. Glitches between processes. Interdependencies. Information management
projects. IS/IT architectures. Fragmented responsibility. Insights and needs: Common understanding.
Integrating construct. Contextualization. Historical awareness. Recurrent patterns. Enactment.
inTroducTion
Section 1 is an historical account of experiences, observations and incidents from the Ericsson develop-
ment practice that somehow have influenced the Activity Domain Theory (ADT). There are two main
paths that contributed to this. The first one is the introduction in the early 1990s of the anatomy as a
main instrument for managing the complexity of mobile telephone development projects at Ericsson.
The second path is the evolution of coordination support based on a particular information system (IS),
Matrix, in which I was personally involved. This path is called the domain construction strategy (DCS)
in the book.
Section 1: The Practical Trail
Figure 1. An example of an anatomy of a processor (Lilliesköld, Taxén, Karlsson, & Klasson, 2005.
©PICMET. Used with permission)
The evolution of the mobile systems has been described as a sequence of generations (Lindmark, Ander-
sson, Johansson, & Bohlin, 2004). The first generation, 1G, was developed in the 1980s until replaced
by 2G generation in the 1990s. The main difference between 1G and 2G is that 1G radio signals are
analogue, while 2G signals are digital and handed over between “cells” in the network as the mobile
moves along. The architecture for the 2G systems is based on the GSM standard (Global System for
Mobile communications; originally from Groupe Spécial Mobile).
By the early 1990s, the wireless industry was ready to go for digital cellular systems. On Jan 16th,
1992, Ericsson was awarded a contract with Tokyo Digital Phone for a mobile telephone system to be
delivered on April 1st, 1994. At that time, the cellular mobile technology was in its infancy, the telecom
market had been deregulated, and several new operators began to take advantage of the new technology.
The project turned out to be a success, and by 1996, Ericsson passed the 1 million subscriber milestone
for its CMS 30 system, making Japan one of the fastest growing markets for cellular telephony.
It was in the Japan project that Ericsson introduced the concept of the “anatomy” of a system for the
first time. The anatomy is an architectural view, illustrating the dependencies between capabilities, from
the most basic one to the complete capability of the system. An example is given in Figure 1. Each box
represents a capability, and each line a dependency. The details are not essential here; however, note
Section 1: The Practical Trail
the “Power on” capability at the bottom of the anatomy! If the power cannot be switched on, all other
capabilities will fail.
The anatomy differs from most other architectures in the sense that its purpose is to provide common
understanding about the most critical dependencies in the system. The simple motivation for concentrat-
ing on this view is that if these dependencies are not clear to all project members, there is a great risk
that the project will fail.
The anatomy was one of the reasons behind the successful outcome of the Japan project. This way of
working represented a complete break with the previously dominant “waterfall” method. Due to various
reasons, however, the lessons learnt were not transferred systematically to other projects. Rather, the
experiences were, so to say, sedimented way back in “organizational memory” as a faint insight that
complexity could be successfully managed by something called the anatomy.
In the late 1990s, the telecom industry was ready for the next, technical “quantum leap” – the transi-
tion to the 3rd generation of mobile systems. These systems were to be based on a new standard called
UMTS (Universal Mobile Telecommunications System) that enabled substantially higher transmission
rates needed to access the Internet, transfer video streams, data, etc. The challenges that Ericsson faced
were expressed by the total project manager:
The total technical changes being implemented in this project are enormous. Such changes are needed
in order for Ericsson to get a world-leading product first to market. Using traditional methods then the
scope of change implemented in single steps will be too large and cannot be managed (Total project
manager, Ericsson, Dec 1999).
The method chosen to implement the 3G systems was an elaborated anatomy-centric variant that
had been worked out at the Ericsson development unit in Aachen, Germany. It was quite clear, how-
ever, that the coordination support used in the 2G projects was insufficient for the 3G development. It
so happened that a new kind of support, the domain construction strategy, had been developed along a
quite different path.
The second path can be traced back to another “quantum leap” that Ericsson tried to achieve during the
1990s. At about the same time as the 2nd generation of cellular systems was launched, Ericsson set out
on a major endeavor to replace its AXE switching system. This system, which turned out to become a
tremendous success for Ericsson, had been in development since 1958 and was formally launched in
1978 (Vedin, 1992).
By the late 1980s it was clear that the need to transfer data, video and other information over the
telecom net was increasing. This need was to be met by a broadband successor of AXE – the AXE-N
system where N stands for “network”. This project ran between 1987 and 1995 without much interac-
tion with the mobile systems that were developed simultaneously. However, the AXE-N project was
terminated without having delivered a commercial product. The cost for the project, which was a major
failure in the Ericsson history, has been estimated to a stunning 10 billion SEK, roughly about 1.1 bil-
lion Euros (Lindmark, Andersson, Johansson, & Bohlin, 2004). Even so, this money was not entirely
wasted since many experiences made during this period could be reused in subsequent system develop-
ment projects.
Section 1: The Practical Trail
In 1990 I started to work in the AXE-N project in the Hardware Support System group. The purpose
of this group was to provide support systems and processes for developing the hardware in the AXE-N
system. For the evolution of the ADT, this period can be seen as the instigator and inspirer of many
fragmented ideas that later were brought together.
When the AXE-N project was terminated in 1995, I was assigned to a group whose purpose was to
consolidate various initiatives to develop systems in an incremental, or stepwise, way. This resulted in
a method package, that is, a collection of instructions, templates and descriptions of how to perform
incremental development. In order to support this kind of development, some kind of tool support was
needed. In 1996, I came in contact with a system called Matrix (MatrixOne, 2008), which became the
backbone of the coordination support for the 3G development projects.
During 1997, Matrix was tried out in a number of pilot projects that I was responsible for. Late 1997
these projects were finished, and the results achieved so far were encouraging. Nonetheless, due to
internal conflicts about what IS to base the support on, the continued work based on Matrix was ques-
tioned by several influential persons. The entire initiative was about to be terminated early 1998, which
coincided with the start of my Ph.D. studies. However, in May 1998 the project manager for a new 3G
switching project was convinced by the good results achieved, and decided to use Matrix in his project.
An extensive period of development took place. On May the 10th, 1999 the traditional way of managing
engineering change orders and requirements was shut down, and the corresponding support based on
Matrix “went alive” in a sharp production environment for the first time at Ericsson. The coordination
environment that gradually evolved at the Stockholm site will be referred to as the S-domain in the
book, where “S” stands for Stockholm.
Later in 1999, three more projects started to use the Matrix-based support in the S-domain. At the same
time, project managers at other Ericsson sites were ramping up their 3G activities. Early 2000 it was
decided to use the same support strategy also at these sites. This was a crucial point in the evolution of
the coordination support in the sense that the anatomy and the DCS met for the first time. The result,
i.e., a close combination of a method and a support strategy make up what I call the anatomy-centric
approach in the book.
The overall coordination responsibility for the 3G projects was situated in Aachen, Germany (referred
to as the A-domain in the book). Still another domain, the L-domain, was constructed at Linköping,
Sweden during 2000. In April 2001, Ericsson signed a corporate agreement with MatrixOne for Ma-
trix licenses. By this, the Matrix tool was accepted for the first time as a corporate matter of concern.
Altogether, the coordination support achieved at the different domains was previously unmatched in
the Ericsson history. Between approximately 1999 and 2003 around 140 main projects and subprojects
were successfully coordinated using the anatomy-centric approach.
During the year 2000, the telecom crisis hit Ericsson (Lindmark, Andersson, Bohlin, & Johansson,
2006). In order to save money, investigations were conducted to consolidate the S-, A- and L domains
into a single domain: the C-domain. This eventually resulted in the termination of the S- and L domains.
The consolidation was, however, far from straightforward, and in the end the A-domain remained as
an independent area. Finally, the responsibility for the C-domain was outsourced to another company,
an event that efficiently shut the window to the innovative way of constructing coordination support at
Ericsson.
Section 1: The Practical Trail
In Figure 2 the time line of this story is illustrated. In a way, this story can be seen as a cut through
a large organization at a particular place and time as seen from my personal perspective. Others would
most likely interpret the events that took place in a different way.
references
Lilliesköld, J., Taxén, L., Karlsson, M., & Klasson, M. (2005). Managing complex development proj-
ects – using the system anatomy. In Proceedings Portland International Conference on Management of
Technology and Engineering, PICMET ’05, July 31st – Aug 4th, 2005, Portland, Oregon, USA.
Lindmark, S., Andersson, E., Johansson, M., & Bohlin, E. (2004). Telecom Dynamics, History and State
of the Swedish Telecom Sector and its Innovation System 1970–2003. VINNOVA Analysis VA 2004:04.
Stockholm: VINNOVA.
Lindmark, S., Andersson, E.J., Bohlin, E., & Johansson, M. (2006). Innovation system dynamics in the
Swedish telecom sector. Info: The journal of policy, regulation and strategy for telecommunications,
8(4), 49–66.
MatrixOne (2008). Retrieved Feb 2, 2005, from http://www.matrixone.com/index.html
Vedin, B. (1992). Teknisk revolt - Det svenska AXE-systemets brokiga framgångshistoria. [Technical
revolt – The diversified success story of the Swedish AXE system (in Swedish)]. Värnamo, Sweden:
Atlantis.
1
Chapter 1
The Dawn of the Activity
Domain Theory
In this chapter, the evolution of the domain construction strategy is recapitulated. This story is divided
into a number of phases that can be seen as “life ages” of the strategy at Ericsson. It was born during
particular circumstances in the late 1990s, it had its peak during the millennium shift and it died with the
collapse of the telecom market around 2002-2003. Its remains still linger on at Ericsson, but in a com-
pletely transformed way where the essential elements of the strategy have evaporated into thin air.
However, the experiences gathered during this period became the fertile soil for the ADT and its op-
erationalization. The story I will recapture in this chapter is not an account day by day. Rather I highlight
such events that in hindsight come through as key insights but, when they happened, might not have
been particularly noticed. As in many cases where theory and practice mutually influence each other, it
is not possible to say that theory came before practice or the other way around. It was not until I could
frame my practical experience in the theoretical perspective given in Section 2 (The Theoretical Trail)
that the ADT began to materialize as a full-fledged theory.
In the midst of the maelstrom of events, the signs of the ADT came forth as certain elements that
later was conceived as the operationalized form of the ADT, that is, the expression of ADT in elements
that can be manipulated, measured or observed in a particular situation in order to influence this situa-
tion. The main elements that appear in the story – the Matrix tool, the information model, the process
model and the transition model – gradually emerged as vital for supporting coordination. Rather early
in the life of the domain construction strategy, around 1996, I began to gather these under the banner
of a “Framework”, a construct I will refer to occasionally in this chapter. Thus, a peculiar observation
is that the ADT first appeared in the guise of its operationalization. So, let’s go back to the dawn of the
ADT in the early 1990s!
DOI: 10.4018/978-1-60566-192-6.ch001
Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
The Dawn of the Activity Domain Theory
Many of the ideas that subsequently were included in the ADT came from my participation in the AXE-
N project. I do not claim to be the first to come up with these ideas. On the contrary, taken one by one
these are well known. My contribution, I believe, is to have selected and organized these ideas into a
coherent theory.
concept elaboration
In the AXE-N project many new concepts were invented, and these concepts had to be relevant, unam-
biguous and understandable to the actors. To this end an ambitious subproject was launched to collect
and define concepts. The project had special teams whose purpose it was to collect candidates for new
concepts. Pending concepts were taken to a reference group where it was decided if a particular concept
would be included in the AXE-N project encyclopedia.
In spite of this work, it was very difficult to get an overall picture of the project where concepts could
be seen in their context (LTX-1994-08-15, ERI-1995-03-15)1. For example, in the new system develop-
ment process to be used in the project, more than 120 new concepts were defined in a list without any
conceptual map that could explain how they were related to each other (ERI-1993-09-23).
To make matters worse, directives were issued towards the end of the project to use the AXE-N
system development process for all kinds of developments, for example, of educational material. This
meant that concepts in the AXE-N system like “node”, “logical reference model”, “system entity”, etc.,
had to be appropriated into the educational area. This created even more confusion: “Is a manual a node
or system entity?” “Can a chapter be regarded as a logical reference node?” And so on.
Thus, in a few years (1990-1995) a completely new organizational language was to emerge, often in
conflict with the traditional one. This turned out to be an overwhelming task. In parallel to this, a separate
unrelated initiative was started outside the AXE-N project to define one hundred core concepts within
Ericsson (ERI-1992-09-30). These experiences indicated that the effort to create common understanding
in a work setting is in general underestimated, if paid attention to at all.
In the AXE-N project my main task was to contribute to the development of a Hardware Design Environ-
ment. The principles for this environment were laid down in a system description in 1991 (LTX-1991-
10-09). The guiding principle was expressed in the following way:
The Hardware Design Environment shall combine a long-lived architecture with a flexible functionality
based on purchase (LTX-1991-10-09, p. 4).
In this document a modular process architecture is described in which a process core, process com-
ponents and applied processes are the main elements. The idea was to treat a process like any other
product and configure tailor-cut processes from the process components. The purpose of the process
core was to collect basic principles and guidelines that would apply to both process components and
applied processes. This architecture was further refined in the following years (LTX-1994-07-06, LTX-
1994-08-15).
2
The Dawn of the Activity Domain Theory
A process component was a package of process descriptions, status checks, rules, tools, templates, etc.,
with the purpose of providing a designer with a complete set of utilities for a particular design task. The
hardware development process was more heterogeneous than the software development process since dif-
ferent types of hardware were being developed such as printed circuit boards, ASIC’s (Application Specific
Integrated Circuits), multi-chip modules, etc. Thus, the contextual aspect was more salient in hardware design
than in software design.
Early on it was recognized that the data used in the process components needed to be translated
between the interior and exterior of the component. One purpose was to archive data in a format which
was independent of the particular tools that might be used in a process component. To this end a mecha-
nism to translate data between process components was developed. This mechanism, called the design
information interchange model (DIM), was defined in the following way:
DIM is a kind of framework for how to handle interfaces between data. DIM sets up rules for which
formats may be used for different views for hardware information, for example behavior descriptions,
logical circuit descriptions, net lists, test data, layout. Moreover, DIM provides tools to simplify transla-
tions between formats. (ERI-1991-08-08, p. 2)
The work with DIM was one of the original indications of the transition modality in ADT. Another
source of transition was the specification-based data model (SBDM) suggested by Gandhi & Robert-
son (1992; 1995). This model directly appealed to me as a potential model for handling the borderline
between different contexts:
The specification-based data model (SBDM) is a unifying framework to model configurations of systems
that contain components from differing engineering disciplines. (Gandhi & Robertson, 1995, p. 338)
My interest in modeling the separation of contexts originated in experiences from hardware design
methods. For example, during 1990 I became a project manager for a study with the purpose of inves-
tigating the suitability for VHDL (Very high speed integrated circuit Hardware Description Language)
as a design language. One of the key issues was studying translators (LTX-1990-06-18). The purpose
of a translator is to make it possible to move between abstraction levels, for example, where a transition
took place between “integer” and “byte” levels running at different clock speeds. The translators were
early examples of the importance of attending the transition between contexts.
The basic construct of SBDM is a recursive structure of specifications, which are implemented by
implementations and in turn need other specifications. This was utilized in an attempt to combine the
process modules with an SBDM model of the system to be developed (LTX-1994-03-29b). In Figure
1 an example of this is shown where a certain specification can be implemented in either software or
hardware using different process components for the design of the implementations.
Early in the AXE-N project, a project member suggested something called Information Interaction
Models (IIM) as a comprehensive way of representing processes. A striking example is the IIM used
for developing a multi-chip module (a complex integrated circuit) (Figure 2):
The horizontal lines represent information entities, and the vertical ones input and output to various
activities lines up horizontally at the bottom of Figure 2. At the top, diamond shaped icons indicate pro-
gression control points. The detailed structure of IIMs is explained in detail in the Section The process
model, p. 128; here it suffices to grasp the overall composition of the IIMs.
3
The Dawn of the Activity Domain Theory
4
The Dawn of the Activity Domain Theory
In the internal document LTX-1994-07-06 it is stated that IIMs have a number of advantages. For
example, they have a core structure which can be applied to any process module and any layer in a process
hierarchy. Another observation is that it is necessary to separate between common aspects of the process
and those which are unique to a particular group. These two aspects are called the “administrator” and
“entrepreneur” side of the process respectively. Methodology and support systems are considered com-
modities and, as such belonging to the entrepreneur side, while rules for identification, quality systems,
etc., are more long-lived and belong to the administrator side. Thus, maintaining a balance between more
stable and more agile areas seemed important.
The IIMs were later adopted as the standard way of representing processes for hardware design
in the AXE-N project (LTX-1994-08-15, ERI-1995-03-18). One observation from the work with the
multi-chip module was that an enlarged paper copy of this process model was hanging on the wall in
the project room. The progress of the design was marked on the paper for everybody to see. Thus, the
model served as a communication instrument in the project. During the AXE-N project the issue of
automating process support was discussed a lot, but it occurred to me that the most important issue was
the common view of the process. The automated support did not seem nearly as important, it was quite
sufficient to see the paper on the wall.
During 1992, discussions started to coordinate the software and hardware development processes.
The AXE-N system consisted of a large amount of hardware, yet the software process was constantly
prioritized over the hardware process. In order to achieve a more even balance a strategy was defined
as follows:
Starting from a common process architecture we first focus on each process area by itself and then we
integrate them. (ERI-1992-12-21, p. 2)
The progress in a number of consolidated areas was summarized in a report (LTX-1994-04-01). Only
in 7 out of 18 areas did some alignments exist. Most remarkable was that the foundation, the process
architecture, was not aligned after more than a year’s discussion. My recollection from participating in
the consolidation team is that persons from the software and hardware communities could not agree on
the basic perspective. The modular process architecture in the hardware process was never accepted in
the software community. There were constant discussions about basic concepts and how to organize the
alignment work. The effort to align the software and hardware processes was finally terminated when
the hardware development was moved out of the AXE-N project in early 1995.
The experiences from this undertaking triggered many reflections which were later manifested in
the ADT. One observation is that we tried to align too much. A common understanding cannot encom-
pass everything. There must be a balance between what should be coordinated and what shouldn’t. The
separate practices of software and hardware design should be regarded as cooperating practices, not as
one uniform, single practice. Again, this experience indicated that the effort to agree on the meaning of
concepts is vastly underestimated.
information management
In the report ERI-1989-04-03 general principles for handling of the AXE-N system were defined. In
this report fundamental characteristics regarding “surviving systems” are discussed, such as stability,
5
The Dawn of the Activity Domain Theory
flexibility, integration of new components, and autonomy of different system parts. The importance of
stability is expressed in the following way:
A stable foundation is necessary. For humans this is provided by the stable structure of the DNA, which
is then found at all levels in the human body. In an organization the business processes are adaptable
while the type of information managed in general is indifferent... [the type of information] is structured
in information models [...] which make up the stable structure. (ERI-1989-04-03, p. 3)
In another report, ERI-1991-04-03, principles for information management in the AXE-N project
were defined. The report proposes a way of managing information which is a radical break with the
traditional AXE world. For example, “documents” are to be replaced with “information elements” as
management items. The report also includes a suggestion for an information model for the management.
However, there is no discussion about how to arrive at a common understanding about this model. This
was simply not an issue.
Outside the AXE-N project there was an uneven feeling that the importance of maintaining strict
handling rules was downplayed. It was pointed out that the product handling rules in the traditional AXE
system must be upheld also in the AXE-N system. This task was aggravated by the fact that functions
in the system are realized by both hardware and software. These areas are more or less two different
worlds alien to each other. The report ends with a strong statement regarding the importance of com-
mon understanding:
[The bottom line is that] we must in all of our operations have a common interpretation and understand-
ing of what kind of product we are dealing with and what terms and prerequisites are valid for this.
(ERI-1991-04-04, p. 17)
In the report ERI-1991-04-04 important principles concerning product handling in the traditional AXE
world were treated. The report points out that these rules must be upheld vigorously also in the AXE-N
system. There simply had to be some stable part of the system. These observations pointed towards the
stabilization modality in ADT.
information systems
The IS in the AXE-N project had very ambitious goals from the start. The perspective was to develop
a first class system which was superior to any commercial system available on the market. The main
principle was that all information was to be managed in one IS only (ERI-1991-04-03).
A forerunner to the IS was being developed during the early years of the project. This development
was however terminated in December 1992 on the very same day it was supposed to be released. The
reason was that it did not match the requirements for sharp usage in connection with the development
of early test nets of the AXE-N system. An interim IS solution was launched with the main purpose of
securing the storage and retrieval of files. Gradually the ambition level was lowered and in December
1993, the internal development of the main IS was terminated. The strategy from that point on was to
use a commercial system for software configuration management. This “devolution” was summarized
in 1994 by one of the participants as follows:
6
The Dawn of the Activity Domain Theory
The interim IS was and remains a quick and dirty solution. It cannot possibly evolve into an informa-
tion management system worth the name. The interim IS was a conscious sub-optimization when it was
introduced. It brought the information management ten years back in time. The interim IS is becoming
a part of the problem instead of the solution [...]. Now a commercial system for configuration manage-
ment is introduced. The intention is good. But I see an imminent risk that this will be a continued bottom
up development which makes the “temporary” conceptual world of the interim solution permanent.
(ERI-1994-04-26)
The current state of affairs concerning information management in AXE-N is a great scandal; the new
clothes of the Emperor multiplied by two. In particular, I mean that the introduction of the interim IS as
an information system borders to fraud.
During this period it gradually became evident that the original idea of managing every piece of
information in one system was altogether unrealistic. The configuration needs for developing software
were quite different from that of managing, for example, product structures. This observation indicated
that there was a need to distinguish between different contexts. Different activities simply need different
tools. This may sound very sensible and straight-forward, but during this period the opposite “truth”
was common stock.
In 1993 I became responsible for the technical area called Hardware Support System in the AXE-N
project. The need for various information systems tailored to specific tasks was obvious in the hardware
community. Also, there were a number of commercial support systems available. This sparked off an
investigation of commercial Product Data Management (PDM) systems as backbones tying all specific
ISs together. The investigation led eventually to the establishment of a corporate standard PDM system
in December 1994. I will refer to this system as C-PDM2 in the following. Later on this decision became
a source of conflicts, since the IS used in supporting incremental development in the AXE-N project –
Matrix – was considered a violation of the Corporate policy concerning PDM systems.
The final step in the saga of the ISs in the AXE-N project was taken in July 1995 (about half a year
before the project was terminated) when the basic principle concerning the IS was redefined as “The
information will always be managed in several systems” (ERI-1995-07-06, p. 5). Thus, the original
principle was completely reversed. No strict analysis was ever made of this calamity. However, a number
of issues were brought up:
• The conceptual world of the main IS was never demonstrated and tested. Neither were the theories
behind the system (ERI-1994-04-26).
• It was not possible to understand the system without confirmation in practice. Therefore, the de-
velopment must be made in steps. (ERI-1994-04-26). Prototyping should have been included in
the project from the beginning (ERI-1994-04-26) (this experience points towards the importance
of enactment of the technology at hand).
• The long term solution was too long term and the short term solution too short. The world of the
interim IS become more or less permanent (ERI-1994-04-26).
• One IS cannot be used for wildly different activities (ERI-1994-06-02). The intention to create
one support environment that everybody could use was futile (ERI-1995-12-12). Each activity
should have ISs which suit the tasks of that activity.
7
The Dawn of the Activity Domain Theory
• The management of structures is different from the management of files during software develop-
ment (ERI-1994-06-02).
• The management issues were largely neglected by the project management (ERI-1994-08-15b)
• Lack of a common language (ERI-1994-08-15b).
• Difficult to see the whole picture, nobody had control of this, deep isolated islands of knowledge
without communication in between (ERI-1994-08-15b).
• Requirements were unclear and a dedicated customer did not exist (ERI-1994-08-15b).
• There was a lack of governing directives. Standards were not followed. We invented our own
standards (ERI-1995-12-12).
• The bureaucracy in the project was terrible. The development should have been headed by expe-
rienced senior designers rather than line managers (ERI-1994-04-26).
In 1995, about half a year before the AXE-N project was terminated, I wrote a report which summarized
the experiences from working with the design environment for hardware in the AXE-N project (LTX-
1995-04-26). This report contains several examples and suggestions which later became vital elements
in the ADT. The first attempts to theoretically ground ADT in praxis and dialectics were reported at
a conference in Austin in December 1995 (Taxén, 1995). It so happened that the AXE-N project was
terminated while I was there. Much of the continued work towards the ADT and its operationalization is
grounded in these two documents and in an internal report: “A Coherent Framework for Development”
(LTX-1996-02-23). The latter may be seen as the first sketch of the ADT.
The experiences I got from working in the AXE-N project provided a kind of mind-setting for the next
phase towards the formation of ADT. As described earlier, Ericsson had for some years started to change
their way of working towards an incremental model for developing large software systems. The evolu-
tion of ADT between the years 1996-1997 was mainly related to my work with providing support for
the coordination of incremental development projects.
It turned out that many projects at Ericsson were using different variants of incremental development in
the early 1990s. Such variants concerned the definition of “increment” (“feature increments”; “design
increments”; “integration increments”), whether increments should be considered as tasks or products,
what types of increments should be testable or not, and a number of other aspects3. Discussions had
been going on for quite some time about what incremental development was all about, and it was dif-
ficult to agree on a common understanding of this concept. There was a need to consolidate the different
experiences learnt.
Early 1996 I joined a project which should compile best practices into an incremental development
method package (IDMP). In February 1996, I suggested to use a conceptual model in order to make our
discussions more efficient. The intention was merely to have a picture to which you could point and say
8
The Dawn of the Activity Domain Theory
something like: “I want this relation to go from here to here instead” or “This object is not important to
incremental development”, and so on.
With the help of the model the discussions slowly did begin to converge. In March 1996 the first
version of the model was ready. This was further refined into the one illustrated in Figure 3. The boxes
signify things that were considered important to incremental development and the lines signify relations
between them. Some parts of the model were already existing in the traditional way of working (the wa-
terfall oriented model), but some parts were new. Since the coordination items at this time were mainly
documents, most boxes represent different document types. The focal item, the “Increment” is indicated
by the oval. It can also be noted that the SBDM is included (the “Specification” – “Implementation”
part in the lower right hand corner).
The IDMP was refined into an Ericsson product containing guidelines, method descriptions, document
templates, etc. Several Ericsson internal seminaries were held in Sweden and Holland during 1996 and
1997. In January 1997 the first product release of the IDMP was made (ERI-1996-12-02).
All throughout this period, discussions continued about the meaning and interpretation of the differ-
ent revisions of the conceptual model. One of these discussions concerned how to modify the standard
Ericsson project management method PROPS4 for incremental development. Here is an excerpt from a
discussion in November 1996:
During our work with incremental development and PROPS, the generic version, we have come across
ambiguities in the definitions in the UAB5 method package. The basic inconsequence lies in the fact the
activity and the result of an activity are confused by giving them a common name. (PROPS developer,
ERI-1996-11-05)
9
The Dawn of the Activity Domain Theory
To me it is obvious that “project” stands for both result and activity. How we separate between these
things can best be clarified in a conceptual model. All in all, the model shows how we thought when we
integrated incremental development into existing methods. We can’t describe the world any better than
anyone else can. But we are pretty good at describing how we think about it. (IDMP project manager,
ERI-1996-11-05)
The method package was used in a project called CMS-30 phase 7, which had a Japanese operator
as a customer. Some conclusions from the evaluation of this project were (ERI-1997-10-23):
It so happened that a candidate for a tool to support incremental development was making its way
into Ericsson.
Already in January 1996 the tool issue was discussed and a requirement specification was written in
March 1996. It was clear that none of the existing tools did fulfill the specification. In May 1996 I was
visiting a construction fair in Gothenburg when, by coincidence, I came across a lonely looking sales-
man at a terminal. Roughly the following conversation took place:
This unlikely event led to further contacts which eventually established Matrix as the IS in the Frame-
work. Matrix was originally a PDM system aimed at industrial management of globally distributed,
large quantities of product data and with many thousands of users (MatrixOne, 2008). In September
1996 Matrix was suggested as the tool for supporting incremental development and in October 1996 a
demonstration license was bought by Ericsson. The first installation of Matrix was done in April 1997.
The next step was to start up some pilot projects.
In May 1997 a consultancy company was engaged to contact potential pilot projects within Ericsson. A
tool prototype called the construction planning tool (CPLtool) based on Matrix was developed. The first
demonstration was held on June the 9th, 1997. Later that month contracts were written with pilots in the
10
The Dawn of the Activity Domain Theory
Netherlands, Germany and Karlskrona. I became the technical project manager for the development of
the CPLtool. During this period the information model7 evolved into the one shown in Figure 4.
Each box in the model was directly implemented as a type in Matrix and each line as a relation. In
addition to this, state chains, attributes, cardinalities and revision stepping rules were implemented. The
implementation was tried out in practice and modified whenever needed. In comparison with the model
in Figure 3, the tool supported model shows less document oriented types. For example, the so called
master configuration index (MCI) visible in the first model is now replaced by relations. The boxes at
the bottom (ANT, CNT, etc.,) denote Ericsson specific product and document types.
The model also contains types that are related to project management, for example Resources, Incre-
ment Task Specification, etc. The box “Impact” is in fact an attribute on the relation between “Resource”
and “Feature Increment” which holds estimates for the effort to develop a certain increment. In Figure 5,
an example of a Matrix view is shown, where instances of the types defined in the models can be seen
along with their relations. Basically, the figure shows the tracing from customer needs all the way down
to various Ericsson-specific products and document implementing these needs.
Thus, it can be seen that the introduction of the tool opens up new possibilities to construct the coordi-
nation practice. Furthermore, the information model and the implementation in Matrix were continuously
changed as the construction of the domain evolved. The models and the implementation were however
different in all pilot projects, indicating the need to adapt these to local circumstances.
Figure 4. The information model after the introduction of the Matrix tool (1997) (Taxén, 2006. ©Elsevier.
Used with permission)
11
The Dawn of the Activity Domain Theory
Figure 5. A screen dump of the Matrix tool (Taxén, 2006. ©Elsevier. Used with permission)
The results of the pilot project were in general positive. Below is a statement from the pilot in the
Netherlands:
To summarize the reactions: very positive! General comments were: “It is very flexible”, “That tool
would be very helpful”, “I am really impressed and had not expected such an advanced tool”. (ERI-
1997-10-20)
The pilot team anticipated that the procedure for checking statuses at milestones in projects could
be made more efficient. The traditional procedure was as follows: a configuration manager accessed a
separate document library where the documents to be checked in a milestone survey were stored. From
the status of each document he/she made a list containing all impacted documents and their status; a list
that was subsequently used at project meetings.
With the tool at hand, this procedure could be made fully automatic and even run in real-time at project
meetings. This feature was later realized in the Matrix application in the S-domain. This anticipation of
future enhancements during the actual work with the tool is a nice example of enactment, that is, how
emergent structures are realized by recurrent interaction with the technology at hand.
Positive reactions also came from the pilot in Karlskrona from one of the consultants:
12
Exploring the Variety of Random
Documents with Different Content
rajonghatunk a szűkebb nemzeti és a még szűkebb individualis
eszme után.
Ezek iránt közönyösek vagyunk, sőt megvetéssel viseltetünk.
Persze a szélső idealismus hamar lejárta magát. 1825-ben
Vörösmarty már ostrozza a gyáva kort, melyben álom öldösi a
magyar ember szivét.
A szélső egyetemes iránti rajongás kora nagyon rövid szokott
lenni, de elég arra, hogy az emberiség megtisztúljon a realis idők
erkölcsi szennyétől, a népben uralomra jusson a vallási és erkölcsi
tekintély tisztelete, a családban elfoglalja szerepét az atya és férj, az
irodalomból és művészetből eltünjék az érzéki, az állati kéj,
különösen háttérbe szorúljon a meztelen nő, kit annyi változatban
másol a realis idők művésze és fényképésze.
XXXIII.
AZ ISTEN.
A KÉTFÉLE OK BÖLCSÉSZETE.
A HÁZASSÁG.
A HITVES HŰSÉGE.
CIVILISATIÓNK VESZEDELME.
ebookgate.com