Enterprises as Complex Systems: Extended Axiomatic Design Theory and its Application in Enterprise...

A Systemic Perspective to Managing Complexity with Enterprise Architecture

Pallab SahaNational University of Singapore, Singapore

A volume in the Advances in Business Information Systems and Analytics (ABISA) Book Series

Published in the United States of America by Business Science Reference (an imprint of IGI Global)701 E. Chocolate AvenueHershey PA 17033Tel: 717-533-8845Fax: 717-533-8661 E-mail: [email protected] site: http://www.igi-global.com

Copyright © 2014 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.

Library of Congress Cataloging-in-Publication Data

British Cataloguing in Publication DataA Cataloguing in Publication record for this book is available from the British Library.

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.

For electronic access to this publication, please contact: [email protected].

A systemic perspective to managing complexity with enterprise architecture / Pallab Saha, editor. pages cm Includes bibliographical references and index. Summary: “This book highlights the current advances in utilizing enterprise architecture for managing organizational complexity by demonstrating its value and usefulness”-- Provided by publisher. ISBN 978-1-4666-4518-9 (hardcover) -- ISBN 978-1-4666-4519-6 (ebook) -- ISBN 978-1-4666-4520-2 (print & perpetual access) 1. Information technology--Management. 2. Management information systems. 3. Computer architecture. 4. System design. 5. System theory. I. Saha, Pallab, 1970- HD30.2.S95175 2014 658.4’038011--dc23 2013020605 This book is published in the IGI Global book series Advances in Business Information Systems and Analytics (ABISA) (ISSN: 2327-3275; eISSN: 2327-3283)

Managing Director: Production Manager: Publishing Systems Analyst: Development Editor: Acquisitions Editor: Typesetter: Cover Design:

Lindsay Johnston Jennifer Yoder Adrienne Freeland Christine Smith Kayla Wolfe Lisandro Gonzalez Jason Mull

72

Copyright © 2014, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.

Chapter 2

Enterprises as Complex Systems:

Extended Axiomatic Design Theory and its Application in

Enterprise Architecture Practice

ABSTRACT

The concept of self-evolving/self-designing systems is defined using the notion of life cycle relationships. The authors propose that to design complex enterprises as systems of systems on each level of hierar-chy one should maintain a self-designing property, that is, the designers should be part of the system. It is explained that by so distributing the design authority, under certain circumstances the “apparent complexity” of the system visible to any one designer can be reduced. To ensure the success of organ-ised self-design, the approach uses their extension of Suh’s axiomatic design theory with the “axiom of recursion.” The authors quantitatively demonstrate through two examples the benefits of applying these design axioms in enterprise engineering to reduce the complexity of a system of interest, as well as the complexity of a system which designs the system of interest.

Hadi KandjaniGriffith University, Australia

Peter BernusGriffith University, Australia

Lian WenGriffith University, Australia

DOI: 10.4018/978-1-4666-4518-9.ch002

73

Enterprises as Complex Systems

1. INTRODUCTION

1.1. Uncontrollability of Human-Engineered Systems

One way to look at the history of homo-sapiens is to consider it as the history of inventing, building, using, continuously improving and reinventing tools to support human endeavour. This history starts with the creation of simple tools, such as weapons for hunting and warfare, through to to-day’s complex engineering objects and production, transport, financial and governmental etc. systems.

With the invention and application of comput-ers, humankind has created the means to design and build systems of unprecedented complexity, solving problems and providing services that were impossible before. However, early in the use of computers it was realised that the creation of ever more complex software systems has limits (Brooks 1982). This is a serious problem, because humankind came to rely on systems of which the complexity makes them harder and harder to invent, specify, design, build, operate and control, and finally, to disestablish.

The field of complexity is gaining more impor-tance in science and engineering and goes beyond traditional disciplines, as all of natural science, engineering, as well as social science must tackle the complexity problem (Suh 2005). Suh (2005) points out that due to the lack of “unifying theories” and terminologies, different disciplines and their constituent fields have defined and viewed com-plexity differently to respond to their “immediate needs” with a lack of a fundamental approach to complexity. However, Suh (ibid) points out that “the field of complexity may emerge as a unified discipline using a common set of principles and theories but with a different knowledge base and constraints, and to achieve this goal, we have to define ‘complexity’ in an unambiguous man-ner”: an ultimate goal of the complexity field is

to replace the “empirical approach” in designing, operating and managing complex systems with a more “scientific approach.”

Various disciplines have experienced the prob-lem of having to design and construct more and more complex systems and built tools to handle ever more complex models. Our observation is that while improved design methodologies, modelling languages and analysis tools can decrease the de-signer’s problem, they only extend the complexity barrier that a designer (or group of designers) can deal with – they do not remove the barrier. This is because the desired functionality of the system may be intrinsically complex, i.e. the complexity can only be avoided by giving up on some desired system characteristics. Therefore any designer who needs to model the complete system in its entirety will eventually face a problem.

Our hypothesis is that perhaps the system, or system of systems, and the designer should not be separated: systems should design themselves, out of component systems that have the same self-designing property. This means that while the system of systems may have an intrinsically complex nature – by some significant complexity measure – this complexity would only have to be seen by an omniscient external observer, but not necessarily by any involved design authority.

1.2. Enterprises and Complexity

Enterprises could be looked at as intrinsically complex adaptive systems: they can not purely be considered as ‘designed systems’, because deliber-ate design/control episodes and processes, such as ‘enterprise engineering’ using models in the design of the changed enterprise, are intermixed with emergent change episodes and processes – that may perhaps be explained by models.

In stages of deliberate change during their life history, enterprise may be considered a kind of engineered system, where change is supported by

74


some form of enterprise engineering methodol-ogy. However, unless these methodologies adopt appropriate complexity reduction methods, such enterprise engineering efforts may create results that display one or several undesirable systemic properties due to uncontrolled design complex-ity. Therefore, the main aim of this chapter is to propose a theoretical framework and principles that can be adopted for tackling complexity in enterprise engineering

We intend to apply theories and principles ad-opted form the complexity field and demonstrate their use in enterprise engineering as ‘architecting principles’. These architecting principles can be used as guidelines and help enterprise architects to propose solutions that have desirable systemic properties.

First we shall propose to adopt an existing theory of design of complex systems, Axiomatic Design (AD) – a theory that originated from mechanical engineering (Suh, 2001). Second, we propose an extension to this theory and its principles to cater for the design of enterprises as a special class of complex systems, namely adaptive and self-evolving systems.

In section 1.1 we briefly introduced the problem of uncontrollability of human-engineered systems. Section 2 describes the complexity problem in enterprise architecture practice. Section 2.1 briefly introduces different categories of measures of complexity. In section 2.2, the consequences of the complexity problem are described. In sec-tion 2.3we look at the disciplines that studied how to tackle the complexity problem, and in section 2.4we introduce a pragmatic measure of complexity.

Section 3.1 discusses complexity from the enterprise engineering point of view and reviews Axiomatic Design Theory and its two axioms. In section 3.2 we introduce the extension to Axiom-atic Design and how this theory could be applied in enterprise engineering.

In section 4 we introduce a hypothesis by introducing self-evolution/self-design as a way to tackle the complexity problem and then define a self-evolving system using the concepts of the ISO 15704 standard.

Section 5 reviews Kolmogorov Complexity as a proxy for the complexity of a design, and demonstrates how to estimate this measure, thereby allowing alternative design solutions to be compared.

In section 6, using simple examples, we dem-onstrate how to apply Extended Axiomatic Design Theory to enterprise engineering. For this purpose in section 6.1 we demonstrate the Application of AD’s Axioms I & II in designing a virtual enter-prise X (Bernus et al, 2002) and in section 6.2 we show the Application of our Axiom III of Design of self evolving systems in designing the project that creates a virtual enterprise X.

2. THE COMPLEXITY PROBLEM IN ENTERPRISE ARCHITECTURE

2.1. Measures of Complexity

Gershenson (2007) points out, that the complexity of the representation of a system depends on the observer (stakeholder). The explanation of this fact is as follows.

When modelling any system, different elements (such as levels of detail, properties, dimensions, states, and probabilities of events and etc.) are considered relevant by different stakeholders of that system (such as user, designer, manager, …).

An omniscient observer ‘O’ would have to be aware of all such elements, as may be represented by O’s model of the system (MO). However, individual stakeholders (Si) only need to see ap-propriate views of this model. Each such view is a model MSi of the system seen by the respective stakeholder Si. Therefore, while it may be pos-

75


sible to define an intrinsic complexity measure of a system (based on MO), this may not have to be seen by any real stakeholder at all.

Contemporary researchers in architecture, biology, computer science, dynamic systems, engineering, finance, game theory, etc., have de-fined different measures of complexity for each field: Lloyd (2001) observes that researchers are asking the same or similar questions and that their answers have much in common Following Lloyd, there are three questions posed when attempting to quantify the complexity of an entity, which Lloyd calls a ‘thing’:

1. How hard is it to describe the entity?2. How hard is it to create the entity?3. What is its degree of organization of the

entity?

Lloyd (2001) lists the following measures for each:

For (a), the difficulty involved in completely describing the entity (typically quantified in bits): Information; Entropy; Algorithmic complexity or algorithmic information content; Minimum description length; Fisher information; Rényi entropy; Code length, Chernoff information; Dimension; Fractal dimension; Lempel-Ziv com-plexity. NB. for our treatment here the references to each are not necessary.

For (b), the difficulty involved in constructing or duplicating the entity: Time/space Computa-tional complexity; Information-based complexity; Logical depth; Thermodynamic depth, etc.

For (c), the degree of what Lloyd calls ‘organi-zation of the entity’. NB, Lloyd does not elaborate on the dimensions used to quantify these. This measure is subdivided into:

1. The difficulty involved in describing the organizational structure: Effective com-plexity; Metric entropy; Fractal dimen-sion; Excess entropy; Stochastic complex-ity; Sophistication; Effective measure complexity.

2. The amount of information shared between the parts of a system as the result of its or-ganizational structure: Mutual information; Channel capacity; Correlation; etc.

2.2. Consequences of the Complexity Problem

What groups (a) and (c) have in common is that they measure the difficulty an observer encoun-ters when describing the entity as a system, for the purpose of analysing, designing or control-ling it. This observation is not entirely new: e.g., Gershenson (2007) introduced a relative measure of complexity (see Def 1 below).

Def 1: “The complexity of a system Csys“ … [is a measure, which] … “scales with the number of its elements #E, the number of interac-tions #I between them, the complexities of the elements Cej, and the complexities of the interactions Cik” (Gershenson 2002).

This definition is relative, because the descrip-tion of the system is made from an observer’s point of view, so as to be able to make predictions about some properties of the system about which the observer cares. (Gershenson 2004) illustrates this rather abstract measure, using the example of Random Boolean Networks (Kauffman 1993), in which the chance of chaotic behaviour increases with the number of nodes (#E) and the number of interactions determined by the number of con-nections (#I) between nodes. Namely, with the increase in the number of interactions between nodes slightly different starting states tend to produce increasingly different outcomes, making the prediction of the network’s next state very difficult or impossible.

Although this discussion helps us show how system complexity contributes to the difficulty of predicting system behaviour, (Melvin 2003) argues that we need large and complex systems to be able to satisfy all functional requirements of a system. However, it is precisely the complexity of

76


a system that makes it difficult to predict that the system will always do what is required! Indeed, Axiomatic Design Theory (Suh 2001) defines a ‘complex’ system as one that can not be predicted for certain that it will always satisfy its functional requirements.

We emphasise that Gershenson’s and Suh’s complexity definitions are relative notions, be-cause depending on the concerns of the observer the same entity may be viewed as having different number of elements / interactions, and the com-plexity of elements and their interactions may in turn be viewed differently by each observer. We therefore conclude that ‘being complex’ is not an inherent property of an entity, but it is a property seen by an observer considering the entity as a system.

As an example, in the area of Enterprise Ar-chitecture one of the important questions is to maintain a coherent and coordinated investment activity. Complexity is a threat to this endeavour, because it can increase uncertainty and may im-pose risk (Saha, 2006). Given the relative notion of complexity, while from certain aspects the system may be complex, thus unpredictable, there is scope for finding architectural solutions, i.e. solution architectures with appropriate systemic properties, so that while system state may remain to some extent unpredictable, properties of the system that matter for investment efficiency stay predictable.

Smarr (1985) explains that the concept of com-plexity is multidimensional and multi-disciplinary and there is no single way to define and measure it. A mathematician may define it by the number of degrees of freedom in computational operations, while a physicist may define it by the number and frequency of interactions in a system.

Abraham (2002) analysed the twentieth cen-tury history of complexity theory and described the theory’s three roots, their interactions and bifurcations as a complex dynamic system itself;

he considers the roots to be cybernetics, general systems theory / theoretical biology, and system dynamics.

Castellani (2009) also identifies three roots of complexity science, but somewhat differently: systems theory, cybernetics and artificial intel-ligence, and defines derivations of complexity science from these roots, giving a historical per-spective of the area.

Complex Adaptive Systems Theory (Holland 1992; Gell-Mann 1994) looks at the problem of a complex system as a system that is created from the interactions of systems – possibly by itself – and which interaction produces emergent properties, without there being a designer at all. We must add though that the problem still exists for the observer who encounters such a system without claiming to have ‘designed’ it: after all we still may need to know how is it possible to control the system or predict its future behaviour – at least to some desired extent.

2.3. Disciplines that Studied How to Tackle the Complexity Problem

Software Engineering (SE) has been trying to devise methods to reduce apparent complexity. Efforts to reduce the complexity of software in-clude the use of design principles and patterns, encapsulation in Object Oriented software devel-opment (Snyder 1986), Object Oriented Analysis and Design (OOAD) (Meyer 1988), Component Oriented Development (Nierstrasz, Gibbs et al. 1992), Service Oriented Architecture (Krafzig, Banke et al. 2004; Erl 2005) and Multi Agent Systems (Wooldridge and Jennings, 1995), where-upon Software Process Improvement concentrates on the system that develops software manageable (Osterweil, 1987).

Traditional Systems Engineering (SysEng) has been successful at satisfying complex ‘design, develop, and deploy’ requirements (Dromey 2006;

77


Wen and Dromey, 2006 and 2009). However, Bar-Yam (2003a, 2003b) argues that there is a transition from procedure-driven to capability-based engi-neering processes and systems engineering must rely on the self-organising ability of engineering – something traditional system engineering was never proposed to handle.

Systems engineering grew out of the need to tackle the complexity of designing large scale systems and developed various approaches and methods (e.g. ‘multistage analysis’, ‘evolutionary engineering’ [Bar-Yam, 2002, 2003b]). Systems engineering attempts to overcome the limitations of ‘decomposition based’ engineering and focuses on planned methods to analyse and design a sys-tem of systems rather than a way to remove the complexity of the designed system(s) (Bar-Yam & Kuras, 2003).However, Bar-Yam (2003b) thinks that if the task is intrinsically complex for usual systems engineering processes, then it is better to use an evolutionary process to create an environ-ment within which continuous innovation can be carried out.

Note, that Suh’s Axiomatic Design (AD) theory developed an understanding of complex systems, with its own definition of ‘complex’, explaining reasons of emerging complexity in design (Suh, 1999). AD is also a formal design theory, defining principles that designers of systems need to follow to produce systems with minimal complexity (in Suh’s sense).

Enterprise architecture(or ‘enterprise engi-neering’) addresses the same problem: enterprises are unquestionably complex systems, but while they can be partly characterised as ‘designed sys-tems’ they are also ‘complex adaptive’ in nature because the system being changed/designed is usually an evolving ‘living system’ – a property also studied in General Systems theory (Berta-lanffy, 1968). Enterprise architecture frameworks e.g., GERAM (IFIP-IFAC Task Force, 1999; ISO15704:2000), aim at enlisting a collection of tools, methods and models to be used in enterprise change efforts and effectively become a “toolkit

of concepts for designing and maintaining enter-prises for their entire life history” (ISO, 1999a; Bernus et al., 2003).Therefore we expect that EA frameworks may be used to systematize various contributions of the field that address the creation and sustenance through life of the enterprise as a complex system.

Although other architecture frameworks might be applicable to the context of the current paper, we chose GERAM because of its distinct features: a) complete life-cycle coverage of enterprise ar-chitecture, b) equally important treatment of the human and technical views of a system, c) ability to cover hybrid systems, like socio-technical sys-tems, and d) ability to demonstrate relationships between life cycle and life history of entities of an enterprise as a complex system – an important distinction not provided by any other systems engineering or enterprise architecture framework.

The GERA modelling framework of GERAM reduces the apparent complexity of enterprise models by introducing the view(point) concept as the generalisation of the view(point) concepts of several other architecture frameworks. Different views constructed on the basis of these viewpoints may highlight certain aspects and level of detail of an enterprise entity and hide the rest of aspects and detail.

It is important to note the completeness of GERA’s scope. GERA) uses an ‘epistemological trick’ inherited from several frameworks (Bernus, Nemes and Williams, 1996) to achieve complete-ness: the scope is complete by definition because subdivisions in the GERA metamodel are made in a way that preserves completeness – namely GERA considers

• Everything that is done by humans and ev-erything done by non-humans.

• Everything that the system does to satisfy its purpose (i.e., to provide service to, or produce goods for someone else) and ev-erything that the system does for itself (i.e., management and control).

78


• Everything done by hard systems (i.e., ‘hardware’) and by non-hardware (i.e., ‘software’, or ‘information that controls the state / configuration of the hard system’).

• Everything from the system’s functional viewpoint (i.e., function and information), as well as the system’s structural view-point (i.e., constituent resources), and the relationship, or mapping, from resources to functions / information (i.e. the system’s organisation).

• Every process that is done to the system, pertaining system change, and by the sys-tem to create or change it, operate it and decommission it, or part of it. These ‘life cycle processes’ or ‘phases’ may be per-formed by the system, or by the environ-ment – which latter may contain other sys-

tems. The processes that create or change the system are further categorised by the same completeness-preserving method: we account for every process that consid-ers the system at a level more abstract than requirements-level: identification and con-cept, and at the requirements-level, as well as everything that considers the mapping of requirements to structure: architectural design, and finally every process needed to institute the change: detailed design & implementation, building / release to op-eration. NB, the terminology ‘to consider the system’ is deliberately vague, because it is intended to mean either ‘to describe the system due to design intent’ or ‘to de-scribe the system due to intent to discover’ (see Figure 1).

Figure 1. The GERA modeling framework’s viewpoints (adapted from IFIP-IFAC Task Force, 1999)

79


2.4. A Pragmatic Measure of Complexity

As we try to solve the difficulty of having to use complex design descriptions, we turn to Axiom-atic Design Theory’s complexity measures. AD proposes techniques for reducing complexity in multiple engineering domains, including software development (Suh and Do, 2000).

Suh (2005) divides “the treatment of com-plexity” into two distinct domains: treating the complexity in the “physical domain” and treating the complexity in the “functional domain.” In the first domain most engineers, physicists and math-ematicians consider complexity as an “inherent characteristic of physical things, including algo-rithms, products, processes, and manufacturing systems.” Suh (2005) believes that this idea that ‘physical things with various parts are inherently more complex’ “may or may not be true from the functional point of view.” He believes that “the complexity defined in the functional domain is a measure of uncertainty in achieving a set of tasks defined by Functional Requirements (FRs) in the functional domain.” The “functional” approach is to treat complexity as a relative concept that evaluates how well we can satisfy “what we want to achieve” with “what is achievable” (Suh 2005). Accordingly Suh believes that: “the complexity based on the physical thinking would have field-specific “dimensions,” whereas the complexity based on the functional thinking would be dimen-sionless regardless of the specific subject under consideration.”

Note that some complexity definitions are easy to understand but hard to measure: e.g., Chaitin (1966) and Kolmogorov (1969) proposed a defini-tion of complexity of a software calculated as the length of its most compact description. However, these measures can not be explicitly computed (Suh, 1999; Vitányi, 2007).

What we propose as the measure of complex-ity is a proxy of the above measure, even though approximation techniques exist to estimate Kol-mogorov complexity; see for example Section 5.2of this chapter. For a system to always satisfy its functional requirements it must have ‘enough knowledge’ of the state of its surroundings (e.g. for software systems this includes the operat-ing system, storage, processor, communication network…), the states of the control information received from other systems, and the possible states of the system’s inputs: in each case two states are deemed different if the system must respond to them differently. To function correctly, the system has to know the relevant states of its surroundings. By having to encode these relevant states the minimum length of system description grows with the number of these states: so we can use the number of these relevant states as an approximate complexity measure, and call it ‘In-formation Content’ (IC) because it is information the system must have about its environment. Note that ‘knowing the state of the environment’ may include knowing state history if this is relevant for determining what is the system’s appropriate response, and ‘state’ should interpreted in an ab-stract sense). Example: consider the environment that contains a counter, which always increments by one, until it reaches 100 after which it resets to zero. Let the functional requirement of the system be to ring a bell when the counter in the environ-ment shows 100. There are two relevant states of the environment: counter=100 and counter<100, though the counter has 100 different states.

The chance of success of a design solution (Suh, 1999) is low if the designer needs to use an overwhelming amount of information to create a design that satisfies the FRs. This is equivalent to having to consider too many states of the environ-ment in which a system must operate. Therefore our Information Content (IC) as a complexity

80


measure is a proxy of what Suh calls information content (whereupon ICSuh = the negative logarithm of the probability that the system always satisfies its FRs).

In addition to this IC being measurable quan-tity, this concept can be used to devise enterprise engineering methods that exploit the fact that this IC can be made relative. This opportunity is further discussed in Section 4.

3. ENTERPRISE ENGINEERING AND COMPLEXITY

3.1. Enterprise Engineering Principles for Complexity Reduction

We interpret Lloyd’s complexity measure clas-sification as:

1. Complexity of the system’s function (i.e., the difficulty to describe the function, behaviour, and states of the system).

2. Complexity of the process creating the system (i.e., the difficulty to describe and execute the process creating the system).

3. Complexity of architecture (i.e., the difficulty to describe the relationship between physical and functional structure, e.g. due to number of relationships / dynamics of relationships).

Complexity measures a) and c) talk about a ‘target system’, in our case an ‘enterprise’, whereupon measure b) talks about the system that creates / changes the enterprise.

To see the relationship between Suh’s two complexity domains and Llloyd’s three domains we have two observations. Category a) treats the complexity of the target system in the functional domain while category c) treats the complexity of the target system in the “physical domain.” Category b) is about a different system, to which therefore complexity categories a) and c) would apply if the system were considered the target.

As enterprise engineering can be considered as a special case of systems engineering, we can try to apply principles of Axiomatic Design (AD), given that AD claims to codify (in a discipline-independent way) what a ‘best design’ is, therefore it can be expected that AD will contribute impor-tant design principles to enterprise engineering.

Suh’s two axioms of design are as follows (Suh, 1990):

Axiom I: Independence Axiom

The independence of FRs must always be main-tained.

Explanation: a FRi is independent of other FRs if there exists a solution, i.e. list of ‘Design Param-eters’ (DP), such that if changing one FRi only one DP needs to be changed.

As mentioned before, the “functional” ap-proach is to treat complexity as a relative concept that evaluates how well we can satisfy “what we want to achieve” with “what is achievable” (Suh 2005).Therefore this approach needs a mapping from the “functional domain” to the “physical domain” to determine the complexity. According to Suh (1990), design is the result of a series of mappings across four design domains. Once we identify and define the perceived customer needs (CA), or the attributes the customers looking for in a product, these must be translated into (FRs), and there may be several ways to do this. After the (FRs) are chosen, we map them into the physical domain to conceive design with specific (DPs) that can satisfy the (FRs). The fourth mapping is to find processes PVs that implement DPs (see Figure 2).

The mapping process is typically a one-to-many process, that is, for a given FR, there can be many possible (DPs) (see Figure 3).

According to Suh, design is a process to find DPs such that [FR] = [[A]] × [DP], where [FR] is the vector of FRs, [DP] is the vector of DPs and [[A]] is a matrix mapping DPs to FRs.

81


• If [[A]] is a diagonal matrix the design is called uncoupled, meaning that full inde-pendence of FRs is achieved.

• If [[A]] is triangular then the design is de-coupled, and as a result the implementa-tion process of DPs is ‘serialisable’

• If [[A]] can not be rearranged to be tri-angular then the design is coupled, and consequently the implementation is not ‘serialisable’.

Therefore, if an uncoupled design solution is not possible then the number of dependencies must be minimised, through trying to achieve

decoupled solutions. If decoupled solutions do not exist then the number of couplings must be minimised.

We see Axiom I as the intent to minimise the complexity of the system’s architecture – complex-ity type ‘c’ above; examples of this are found in many engineering disciplines.

Axiom II: Information Axiom

Out of the designs that satisfy Axiom I that design is best that has the minimal information content.

Note that Suh defined information content as the negative logarithm of the ‘probability of

Figure 2. Mappings across four design domains (apdated from Suh, 2003)

Figure 3. Mapping of the design domains in axiomatic design theory to GERA life cycle activities (adapted from Moghaddam, et al., 2008; Kandjani & Bernus, 2011)

82


success’, we propose to use alternate measures (proxies) for this property, due to pragmatic advantages: namely IC as defined in Section2.4, and IC as the Kolmogorov complexity of the FR → DP mapping matrix (as shown in Section 5.2).

According to these two axioms of design an enterprise as a system must be specified and designed for its FRs to be satisfied by design parameters that are as independent as possible, and where the combined information content is minimal.

AD proposes ‘Zigzagging’ as a design meth-odology for producing a design that satisfies the two axioms. Zigzagging is used to simultaneously decompose FRs and DPs in the functional and the physical domains to create FR and DP hierarchies and to make sure that the two design axioms are applied when mapping DPs to FRs (Suh, 2003).

This is because depending on the nature of high level DPs, FRs could be decomposed in different ways, because to decompose a function, one has to devise a process, activities of which are invocations of lower level functions, and it is well known that usually there are many different processes that can perform the same transformation.

Mathematically, if a system S has a function F which could be implemented by a process P, con-sisting of a set of activities A={Ai}, then each Ai must be an invocation of some function in the set of functions L={Lj} implemented by the set of DPP. In this case L={Lj} is a functional decomposition

of F. However, an alternative process R may ex-ist, with a different set of activities B={Bi} each being an invocation of some function in K={Kj} of design parameters DPR. Thus normally there is no single functional decomposition of a function (see Figure 4).

In fact, we should not decompose high level FRs unless we first find some DPs that can sat-isfy these highest-level FRs, otherwise the feasi-bility of the design is not ensured.

Therefore, when we define the FRs, we have to “zig” to the physical domain, and after DPs are found and chosen, we have to “zag” back to the functional domain for further decomposition.

NB, enterprises that specify FRs at all levels with no zigzagging between the functional and the physical domains will miss opportunities for innovation (Suh, 2003) (see Figure 5).

These two axioms can be used as architecting principles when considering the structuring or re-structuring of an enterprise, including its Busi-ness Model: practically, the way the enterprise is structured from business units, supporting logis-tics, facilities, and other infrastructure, such as Information Technology. However, as will be discussed in Section 3.2, some of the complexity is not automatically addressed by applying these two axioms as design principles.

A practical consequence of Axiom I is apparent when considering its use as an architecting prin-ciple in Service Orientation. A Service Oriented

Figure 4. L={Lj} and K={Kj} are alternative decompositions of F

83


Architecture is believed to foster agility and flex-ibility of the enterprise. For example, a Service Oriented business is characterised by the business units having clear functional interfaces, such that a service to the customer could be composed by a customer facing unit out of the services of lower level internal or external services. Similarly, the separation of business processes from the under-lying functions of software applications using a Service Oriented IT architecture, is believed to allow the configuration of a multitude of new or changed business processes out of underlying application functions. The question is therefore, what methodology can be used to design busi-ness- and IT architectures to foster the highest level of agility and flexibility?

The action space of the enterprise is deter-mined by the set of possible combinations of the underlying / available functions, from which services to the customer can be combined. This ‘combination’ is achieved by a process, which can be ultimately decomposed into activities that in turn are invocations of service functions.

If the first axiom is observed, then the enter-prise has the largest action space (i.e. the richest possible combination of [invocations of] functions into processes), because there is no limitation to combining independent functions. In other words,

Axiom I is an essential principle to observe when designing service oriented architectures – either business or IT.

Furthermore, Axiom II insists on the architect selecting the simplest solution out of the ones that satisfy Axiom I. ‘Simplest’ in this context can be illustrated as ‘fewer elements and relation-ships among elements’, thus reducing the number of possible design- and implementation errors and oversights and consequently improving the chances that the implemented system will under all circumstances be operating as expected. As demonstrated in Section 5, there exists a simple mathematical algorithm that can be built into a design system, which calculates an approximation of the information content of alternative designs, so as to enable to designer the select the one which is best from this point of view.

3.2. Extension to Axiomatic Design

Observe, that complexity of type ‘b’ is not auto-matically addressed by AD in enterprise engineer-ing. An entity’s life history according to GERAM is the representation in time of life cycle activities carried out on the particular entity during its life. E.g., several concurrent design and implementa-tion processes may be executed in one enterprise

Figure 5. Zigzagging, the result of mapping and decomposition (adapted from Suh, 2003)

84


engineering process, and these work in parallel with the enterprise’s operation. Notice that the life history of the target system is a representation in time of the processes of the ‘change system’ that changes the target system. Given that usually mul-tiple dependencies exist among change activities it is important to address the complexity in the change system as well, in addition to complexity of the target system (see Figure 6).

According to the previously mentioned study of Random Boolean Networks (Kauffman 1993) the more dependency links exist between subse-quent states, the higher the probability of chaos in the life of a system. E.g., if the architect pro-duces a draft architectural design, and the de-signer of a subsystem can work without having to depend on design specifications of other sub-systems, progression is predictable. However, if a complete design specification of all subsystems is needed for designers to progress, change in one subsystem’s specification propagates, which may cause unpredictability.

The example indicates that there are insepa-rable dependencies between states of different life-cycle activities throughout the life-history of a system. We suppose that if there are too many dependencies and these dependencies are not controlled, then possibly the evolution of the system during its life history becomes chaotic. Li and Williams (1994) attempted to use AD in enterprise engineering, and demonstrated its use to the development of a master planning meth-odology (Williams, 1994). In a way their work is an early attempt to address complexity type ‘b’, i.e. to minimise the complexity of the system that creates the system.

While Li and Williams demonstrated the ap-plication of AD to the development of a methodol-ogy of master planning, typically, in addition to the instantiation of such a methodology in form of a master planning project, there usually exist multiple other change processes, performed on a target system – all at the same time. E.g. a long term master planning effort may be parallel with

Figure 6. Parallel processes in the entity’s life-history (adapted from IFIP-IFAC Task Force, 1999; ISO15704:2000)

85


multiple shorter term change processes. These pro-cesses all change the entity (often called ‘system of interest’) on various time horizons.

What we propose below is to define methodol-ogy-agnostic principles of change to be satisfied when co-ordinating multiple change projects / processes.

The set of change projects operating on a system could use different methodologies or processes, but their target is the same entity, so there will be dependencies among these projects. The change projects themselves form a ‘change system’, which could be considered as a complex system in itself. As a consequence, the complexity of the process that creates the system (complexity type ‘b’) arises from the complexity of type ‘a’ and ‘c’ of this change system. We therefore propose that the two AD axioms must also be applied to the change system itself (see Figure 7).

The requirement for a target system (the en-terprise) not to deteriorate during its life can be expressed as the recursion axiom, meaning that change projects as a system of systems not only have to use axiomatic design but they must be ‘axiomatically designed’ (see Figure 8).

Axiom III. Recursion Axiom

The system that designs a system must satisfy Axioms I and II of design.

Explanation: A system (e.g. enterprise) that satis-fies Axioms I and II does not necessarily satisfy Axiom III and while at a given moment in time in its life history a system may be considered moderately complex, the same system may be very hard to create or change. E.g., denote three consecutive stages of a system S as S1, S2 and S3.

Figure 7. The relationship between design domains of change system and target system

86


In S1 system S is operating and has a design that either intentionally, or by pure chance, satisfies Axioms I & II. S2 is the stage of change, where the original system has been extended by a change project P. The task of P is to create S3. When S1cre-ates P it can mandate that P must use Axioms I & II to design S3. However, whether P and thereby S2 satisfy Axioms I and II remains undetermined.

Thus, P can be more complex than necessary and even if its mandate is to design S3, the likeli-hood of success of this endeavour may be less than desired, i.e. P does not satisfy Axioms I & II– even if it applies them to design S3. Axiom III states is that S1 not only has to mandate that P use Axioms I & II, but S1 has to design P using Axioms I & II to improve the probability of suc-cessful evolution.

An important note about the independence of Axiom III. One could argue that P is a separate system from S, and as such Axioms I and II ap-ply as the high level functional requirements of designing S, therefore Axiom III is unnecessary. However, notice that Axiom III is really about the

quality of design of S, and not about the quality of design of P. What Axiom III is intended to state is that out of the designs of S which satisfy Axioms I and II that one is best which is able to axiomatically design its own change. Thus Axiom III is pertinent to the design of systems that are involved in managing their own change, and its use is to ensure that S does not deteriorate with time. In everyday language: Axioms I and II are about the system being the best design from the point of view of doing what it is supposed to do. Axiom III is about the system being able to change as is intends to change. Thus, we introduced the third Axiom for the design of enterprises as special class of systems, namely self-evolving systems.

As demonstrated, systems at one stage of life may satisfy Axioms I & II but may lose this de-sign quality as they evolve / change, and through reducing the likelihood of success of the change process this quality may even be lost perma-nently. To prevent such state of affairs we had to introduce Axiom III. Pragmatically: a large and complex system is created by complex systems

Figure 8. Mapping of design domains to GERA’s life cycles and the relationship between the change system’s and the target system’s life cycle activities

87


to the design of which axiomatic design needs to be applied NB, the change system of systems is called the set of ‘supporting systems’ in systems engineering (see ISO 15288:2000).

4. SELF-EVOLUTION AND COMPLEXITY

A way to minimise the amount of information that a designer needs to have about the states of a system S and its subsystems Si is to minimise the amount of information the designer has to have about the set of states Ti of each subsystem. There are two ways to minimise the observed information content:

1. The designer of a system elaborates the de-pendencies of subsystems for each system state in Πi=1,…,nTi and defines the desired system behaviour for each such state (where ‘n’ is the number of subsystems). Note that in large systems multiple parallel change processes of subsystems may create very large values of Ti. The designer may in-stead, stipulate a set of relevant states ti of each subsystem, where |ti | << |Ti|, such that dependencies are artificially restricted to avoid chaotic life history. E.g., the designer of a system may stipulate ti and request a ‘controlled release of change’ from the sub-system’s designer. This technique reduces the chance of undesired system behaviour but does not alleviate the designer’s problem, because the designer still has to consider all of Ti.

2. It is known from practice that for the same pragmatic purpose a designer situated out-side of the system needs a more detailed model of the system than a designer that is part of the system itself. This is because a designer who is part of the system will have developed tacit knowledge and will have already have the knowledge of how to collapse Ti into ti – without actually having

to enumerate Ti at all: the designer who is part of the system knows what the relevant distinctions are regarding the system’s ability to satisfy its requirements. Thus the apparent information content of the system from this ‘embedded designer’s point of view is less than the apparent information content.

The Self-Design Hypothesis

The above discussion is the basis for our hypoth-esis according to which the system (or system of systems) and the designer (or group of designers or design authorities) should not be separated and systems and subsystems should design them-selves, out of component systems with the same self-designing property.

Def 2: Self-evolving System

A self-evolving system is a system which can perform its own life-cycle activities by using its own resources or acquiring them from others.

To minimise apparent complexity of a self-evolving system as it appears to any one designer, axiomatic design principles may be used. All of Axioms I, II and III must be satisfied, as the system designs its own change system. Self-evolution can be illustrated by life cycle relationships (see Figure 9).

By satisfying all three axioms the system must attempt to make its life cycle activities as independent, controlled and uncoupled as possible so that the designer can predict the next relevant states of the life history and avoid a chaotic change, i.e. change of those states of which the size and direction must be predictable. Note that this still allows behaviour that an external observer may characterise as chaotic.

According to (1) and (2), self-design results in minimised Information Content (IC) and thus creates a ‘best design’, from the point of view of the likelihood of success. Applying this logic to the change system we derive the conjecture:

88


Self-Evolution Conjecture

Among those change systems which satisfy and apply the first two design axioms, that “change system” is the best which is designed by the stake-holders of the system of interest itself.

While we have no formal proof, the rationale for this statement is: that change system (change project/ change program) is most likely to succeed whose model used to create and control it is the simplest. The argument behind this conjecture is that management, who are the designers of the system’s future, needs to be able to make decisions and plan in light of information about the change environment, and it is the stakeholders themselves with tacit knowledge, who have the least need for explicit information in order to make predictions about and control the change process.

In other words, models used by these ‘em-bedded designers’ can be simpler than models necessary for an external observer because the embedded designers know the important dis-tinctions between relevant states. Conversely, embedded designers can recognise two states as identical from the point of view of relevance to the change process, whereupon the same two states

of the change environment would be considered different by ‘outsiders’ (external observers) who do not have tacit knowledge of this environment.

As a consequence, the requisite variety of the change system (Ashby, 1957; p. 202) can be mini-mised through the change process being designed by embedded designer agents.

5. KOLMOGOROV COMPLEXITY AS A PROXY FOR THE INFORMATION CONTENT

5.1. Definitions

The concept of Kolmogorov complexity was developed by the Russian mathematician Andrey Kolmogorov (1965). While Kolmogorov is cred-ited with the concept, several other mathematicians appear to have arrived at the same conclusion simultaneously but independently of each other (Nannen 2010) in the 1960s. Kolmogorov com-plexity is one of the key elements in information theory; it provides a mathematical definition of the information quantity in individual objects, which can be abstracted as binary strings or integers. For about half a century, Kolmogorov complex-

Figure 9. Self-evolution and life cycle relationships

89


ity has been applied in various disciplines (Li, Vitányi 2008).

The Kolmogorov complexity K xU ( ) of a string x with respect to a universal computer U is defined as the length l of the shortest program p running on U that prints x and halts. It is denoted as:

K x l pU pU p x( ) min ( )

: ( )=

=

If the computer already has some knowledge about x, for example the length of x as l x( ) , it may require a shorter program that prints x and halt. In this case, we define the conditional Kol-mogorov complexity as:

K x l x l pU pU p l x x( | ( )) min ( )

: ( , ( ))=

=

Theorem 1

If U is a universal computer, ∀V which is an-other universal computer, ∃c is a constant, so for ∀ ∈x { , }*0 1 (i.e. for each binary number x)

K x K x cU V( ) ( )≤ +

The proof can be found in (Cover, Thomas 2006) and will not be repeated here.

Theorem 1 indicates the universality of the Kolmogorov complexity; it shows that the differ-ence of Kolmogorov complexity with respect to different computers is smaller than a constant. If the string x is long, the difference of Kolmogorov complexity caused by different computers be-comes trivial. Therefore, we can discuss Kol-mogorov complexity K x( )without referring to a particular computer.

We use logn to mean log2 n . We also define

log log log log log log log ...* n n n n= + + +

until the last positive term.

Theorem 2

For an integer n, the Kolmogorov complexity K(n) satisfies:

K n n c( ) log*≤ +

The proof of Theorem 2 can be found in Cover’s book (2006). We will explain it in an informal manner here. Generally, we can use a program like “print the integer n” to print n. The program needs the number n, which can be en-coded in logn bits. However, the length of n is unknown, so it requires log logn bits to code the length of n and then requires log log logn bits to code the length of the length of n etc.

Theorem 3

For an integer n, if the length of n is known, the conditional Kolmogorov complexity K(n|l(n)) satisfies:

K n l n n c( | ( )) log≤ +

The proof of Theorem 3 is similar to the previ-ous theorem.

5.2. Estimating the Kolmogorov Complexity of a Transition Matrix

For a given transition matrix M, which maps Design Parameters to Functional Requirements we propose a simple scheme to calculate an upper boundary of its Kolmogorov complexity.

Let M be a n n× matrix, where the value of each element in the matrix can only be 1 or 0. The number of ones in M is m. In order to describe the matrix, we need to record the following infor-mation: the number n, the number of ones m, and the position of those ‘1’s. Accordingly, we can calculate the Kolmogorov complexity of M as:

90


K M K n K m K n

mn

m n mc

mn( ) ( ) ( ) ( ) log*

log* log!

!( )!

≤ + + ≤

+ +−

+

2

2

2

(1)

If M is a diagonal matrix, because all the non- zero elements are ones, it is an identity matrix. It is obvious that in order to record an identity matrix, the only information we require is its size n. Therefore, the Kolmogorov complexity of an identity matrix can be estimated as:

K I K n n cn( ) ( ) log*= ≤ + (2)

6. SIMPLE EXAMPLES

We introduce two examples to demonstrate the application of the three design axioms. The first case study demonstrates an example of a coupled design, a bad design which is more complex than necessary, for a virtual enterprise (called ‘company X’) and applies the first two design axioms which results in an uncoupled design.

The second case demonstrates an example of a decoupled design for a project which creates company X and the application of the 3rd axiom of design, which is the axiom of recursion, to re-duce the complexity of the project which designs, creates and implements company X.

We use an upper bound estimation of the Kolmogorov complexity of the design matrix as a proxy of Suh’s Information Content to demonstrate the difference between the bad and the good designs by calculating the complexity of the design matrix in both case studies before and after applying design axioms. We therefore demonstrate in both concrete examples how the application of extended axiomatic design theory can reduce the complexity of designing a system of interest, as well as the complexity of a system which designs the system of interest.

Systems, at one stage of life, may well satisfy Axioms I & II but may lose this design quality through uncontrolled change, because uncon-trolled change reduces the likelihood of success of the change process and the above quality may even be lost permanently. Therefore the second case study demonstrates the application of the third axiom as a solution to this problem.

6.1. Example One: Application of the Axioms I and II in Designing a Virtual Enterprise X

‘Company X’, which is actually a virtual enterprise, produces one product including three parts Pt1, Pt2 and Pt3. There are five functional requirements listed below:

• FR1: Each part needs to have a blueprint.• FR2: Pt1 needs to be cut and drilled.• FR3: Pt2 needs to be cut and painted.• FR4: Pt3 needs to be cut, drilled and painted• FR5: All parts need to be assembled

together.

Let the original design parameters to imple-ment these functions as follows:

• DP1: Company A provides service of draw-ing blueprint.

• DP2: Company I provides service of cut-ting.

• DP3: Company J provides service of dril-ling.

• DP4: Company K provides service of pai-nting.

• DP5: Company L provides service of ass-embling.

Based on the FRs and the DPs above, we can write the FR to DP mapping formula for company X as:

91


FR

FR

FR

FR

FR

1

2

3

4

5

1 0 0 0 0

0 1 1 0 0

0 1 0 1 0

0 1 1 1 0

=

00 0 0 0 1

1

2

3

4

5

DP

DP

DP

DP

DP

It is clear that the design transition matrix is coupled.

According to the first axiom of design, we must maintain the independence of the functional requirements all the times. Therefore to apply axiomatic design principles, we introduce a broker company B which provides the generic service of ‘manufacturing parts’. Then we refine the structure of company X to X’ with the functional require-ments and design parameters as follows:

• FR1: Each part needs to have a blueprint.• FR2: Each part needs to be manufactured.• FR3: All parts need to be assembled

together.• DP1: Company A provides service of

drawing blueprint.• DP2: Company B provides service of

manufacturing.• DP3: Company C provides service of

assembling.

Then the FR-DP transition matrix for X’ is shown below is a diagonal matrix:

FR

FR

FR

DP

DP

DP

1

2

3

1

2

3

1 0 0

0 1 0

0 0 1

=

The FRs and DPs for the (broker) company B are:

• FR1: Some parts need to be cut.• FR2: Some parts need to be drilled.• FR3: Some parts need to be painted.

• DP1: Company I provides service of cutting.

• DP2: Company J provides service of drilling.

• DP3: Company K provides service of painting.

The design transition matrix is a diagonal3×3 matrix as well.

Let us now calculate the Kolmogorov complex-ity of each transition matrix of the manufacturing case study. In the original design, the transition matrix M is:

M =

1 0 0 0 0

0 1 1 0 0

0 1 0 1 0

0 1 1 1 0

0 0 0 0 1

For this transition matrix, we have n=5, m=9, so based on inequality (1), we have:

K M n m d

nm n m

m d

( ) log* log* log*

log!

!( )!log .

≤ + +

+−

+ × ≈ ( )2

229 9 bits

For the new design, based on Axiomatic Design principles, we have two diagonal transition ma-trices and both matrices happen to be 3×3 iden-tity matrices:

I 3

1 0 0

0 1 0

0 0 1

=

Based on inequality (2), we have:

2 2 4 53K I n n d( ) (log* log ) .≤ + ≈ ( )bits

92


It is clear that the design based on Axiomatic Design principles is much simpler.

6.2. Example Two: Application of Axiom III of Design in Designing the Project that creates a Virtual Enterprise X

Let N be the network which is the aggregation of n enterprise partnersP p p pn= { , , ..., }1 2 . The network N is managed by a Network Office M. M utilizes N to form a number of projects PrX, PrY, PrZ… to create Virtual Enterprises (VEs), such as X, Y and Z etc. Each VE consists of a set of enterprise partners collaborating to create the value chain of the respective VEs. We use PX, PY and PZ to denote the sets of associated enterprise partners for VEs X, Y and Z respectively. Each enterprise partner may participate in zero or more virtual enterprises. Therefore, we have:

P P P P P PX Y Z⊆ ⊆ ⊆, ,

ϕ ϕ ϕ⊆ ∩ ⊆ ∩ ⊆ ∩P P P P P PX Y X Z Y Z, , .

We suppose that the network N that designs, creates and changes VEs (including X) already exists E.g. N may have been created by the net-work office M.

Now consider the VE creation project PrX.PrX has the functional requirements listed

below:

• FR1: Provide the Identification and Concept of X and specify all its require-ments, including functional and non-func-tional ones.

• FR2: Provide the Preliminary or Architectural Design of X: estimate cost, resources needed, selected members etc.

• FR3: Provide the detailed design descrip-tions, and all the tasks that must be carried out to build or re-build and release X into operation.

Let the design parameters to implement this project be the following:

• DP1: PX1is the set of participants who to-gether identify and develop the concept, such as principles, business model, etc of X, This would typically require the knowl-edge of at least some feasible architectural solutions.

• DP2: PX2is the set of participants who to-gether develop the Architectural Design (‘master plan’) of X identifying the list of the selected members, cost and time neces-sary to build X, etc. This would typically be done by reusing existing designs [‘ref-erence models’ or ‘partial models’] where the feasibility of design and building under the constraints of the non-functional re-quirements is known.

• DP3: PX3detailed design of the common parts of the company with a list of the qualified members creates and the new VE into operation.

Based on the FRs and the DPs above and the life cycle dependencies between project tasks of Requirements Analysis, Architectural Design, detailed Design and Build, the transition between DPs to FRs is as below:

FR

FR

FR

DP

DP

DP

1

2

3

1

2

3

1 1 1

0 1 1

0 0 1

=

For the transition matrix:

MX =

1 1 1

0 1 1

0 0 1

We have n=3, d=1, m=6. Based on inequality (1), we estimate the information content:

93


K M n m d

nm n m

m d

X( ) log* log* log*

log!

!( )!log .

≤ + +

+−

+ × ≈ ( )2

218 6 bits

According to Axiom III of design: “The system that designs another system not only must apply but also must satisfy the axioms of design.”

The project (PrX) that creates X could be a sys-tem that designs/changes another system (X). Thus PrX is itself, based on its life-cycle dependencies shown in the triangular matrix above, a complex system that not only should design another sys-tem that has reduced complexity (namely X) by applying axiomatic design theory, but it has to also have reduced complexity and be designed to satisfy axioms I and II.

To achieve the above, we shall reduce the direct communication among life cycle activities of PrX. Neglecting this communication creates additional complexity in the execution of the life cycle activities (FR1, FR2 and FR3) of PrX.

Notice, that practically, the problem is caused by mixing the information dependencies among the life cycle activities with the control of their repeated, iterative invocation.

These dependencies may result in unpredict-able chaotic states of PrX and decrease the prob-ability of success of the resulting design (the Company X). This effect is well known in manag-ing complex projects and arises if the information flow among life cycle activities is not managed and controlled.

6.3. Separation of Management Functions from Operations

What is required to solve the problem in Section 5.2 is to reduce the complexity of the design of PrX itself to guarantee the achievement, or preserva-tion, of the design qualities of X. A solution is to allocate a sub-project manager to each life cycle activity (FR1, FR2, and FR3) and to have them take part in the project management board meetings and to communicate ‘just’ at the management level.

Using this method the project manager of PrX should make the project’s life cycle activities as independent as possible by delegating each life cycle activity to independent sub-projects that communicate just through management of each project and hide the unnecessary operational details of each life cycle activity of creating PrX from the rest of the project’s operations.

We therefore decompose PrX into two parts: PrM is the management of the project and PrO is the operation of the subproject. Let FRM be the functional requirement (to ‘Manage’ Pr), and FRO the functional requirement(s) describing what Pr has to actually achieve, namely the function of the project’s ‘Operations’. In this case PrM (the project’s management) takes care of the control of the communication among operational boundar-ies. Thus on the high level we have:

FR

FR

DP

DPM

O

M

O

=

1 0

0 1

The operational function of the project can be further decomposed into three functions (i.e., life cycle activities, or ‘phases’):

1. The identification phase.2. The architectural design phase.3. The detailed design and building phase of

X.

During the three phases, there are three cor-responding functional requirements:

• FRO1: Provide the Identification and Concept of the virtual company X and specify all its requirements – based on in-put / control received from PrM.

• FRO2: Provide the Preliminary or Architectural Design of X– estimates of cost, resources needed, selected members of the company X etc, based on input / con-trol received from PrM.

94


• FRO3: Provide the detailed design descrip-tions, and all the tasks that must be carried out to build or re-build and implement the company X– based on input / control re-ceived from PrM.

Based on the three functional requirements, we construct three design parameters:

• DPO1: PrO1 identifies different VE types, develops their master plan based on exist-ing preliminary design of partial models of the new company X, and provides the detailed design of the common parts of the company with a list of the qualified suppliers.

• DPO2: PrO2 provides the Architectural Design of X with a list of the selected suppliers for Architectural Design of the company;

• DPO3: PrO3 creates and operates the new VE, and monitors the results of X.

The relationship between the functional requirements and the design parameters can be expressed as:

FR

FR

FR

DP

DP

DP

O

O

O

O

O

O

1

2

3

1

2

3

1 0 0

0 1 0

0 0 1

=

Under the new design approach, we have two transition matrices which are actually two identity matrices I2 and I3.

Based on inequality (2), we have:

K I K I( ) ( ) log* log* .2 3 2 3 3 3+ ≤ + ≈ ( )bits

Compared with the original design, which has the complexity of the design matrix of about 18.6 bits, the design based on the AD principles is significantly simpler.

Note that the reader may suspect a ‘trick’ in this design, because the internal management process of PrM needs to channel the communica-tion among invocations of life cycle activities. This is true of course, however, the separation of content from control has a significant effect: PrM only needs to know about the state of the information maintained by the subprojects, not the content. For example, managers of large projects normally use controlled information / version release processes so as to avoid project instability and ensure convergence. Note also that the method is not to be taken as a counter-argument against collaborative design, after all PrO1, PrO2 and PrO3 possibly share contributors, but their contributions are in different roles.

In this article it was the authors who applied Axioms I and II to ensure that PrX is least complex. In reality PrX may be a project, created by either the Network X itself as a change project, thus ef-fectively X being a self designing system obeying Axiom III by mandating PrM to satisfy Axioms I and II when creating the operational part of PrX.

The authors believe that further work will be needed to study the complexity of project life histories, as opposed to structure that was studied here, i.e., how to apply the above design axioms and associated design methods to reduce the complexity of dependencies among life cycle activity instances. This is because due to itera-tions and feedback most life cycle activities will be performed several times during the project.

7. CONCLUSION

This chapter reviewed a number of complexity measures that can help characterise how hard it is to design and change a system. By applying Axi-omatic Design theory two types of complexity can be avoided or reduced, but we have demonstrated that the third type of complexity—the difficulty to create the system, as defined by Lloyd—is

95


actually the repetition of the other two types of complexity, only targeting the change system not the system of interest.

As a consequence, for enterprises as self evolv-ing systems, we extended the collection of Suh’s design axioms with Axiom III – the Axiom of Re-cursion and demonstrated the application of these three design axioms using two simple examples. The first example shows a coupled design for a virtual enterprise—a bad design which is more complex than needed—and demonstrates how we can apply the first two design axioms to arrive at an uncoupled, less complex design.

The example shows a decoupled design for a project which creates a virtual enterprise X and shows the application of Axiom III to reduce the complexity of the project, i.e., the system, which designs, creates, implements, or changes X.

We applied a known approximation of the upper bound of Kolmogorov complexity to calculate a proxy of AD’s Information Content, and compared the bad and the good designs by calculating the approximate complexity / information content of the design matrix. We therefore demonstrated in both concrete examples how the application of extended axiomatic design theory can reduce the complexity of designing a system as well as the complexity of the system which designs the system of interest.

We formulated a conjecture, according to which the reduction of the apparent complexity of systems, such as enterprises, can be achieved if systems design themselves, and the designer is part of the system. This was derived based on logical considerations of how systems and their designers differentiate ‘relevant states’ of the environment, but further work is needed for a formal proof.

We also introduced the notion of self-evolving systems, a category of evolving systems: those deliberately designing themselves.

REFERENCES

Abraham, R. (2002). The genesis of complexity. Retrieved from www.ralph-abraham.org

Ashby, W. R. (1957). An introduction to cybernet-ics. London: Chapman & Hall.

Bar-Yam, Y. (2002). Large scale engineering and evolutionary change: Useful concepts for imple-mentation of FORCEnet. Cambridge, UK: NECSI.

Bar-Yam, Y. (2003a). Unifying principles in complex systems. In Roco, M. C., & Bainbridge, W. S. (Eds.), Converging Technology for Improv-ing Human Performance (pp. 380–409). Boston: Kluwer.

Bar-Yam, Y. (2003b). When systems engineering fails – Toward complex systems engineering. In Proceedings of the International Conference on Systems, Man, & Cybernetics, (Vol. 2, pp. 2021-2028). Piscataway, NJ: IEEE.

Bar-Yam, Y., & Kuras, M. L. (2003). Complex sys-tems and evolutionary engineering. Cambridge, UK: NECSI.

Bernus, P., Baltrusch, R., Tølle, M., & Vesterager, J. (2002). Better Models for agile virtual enter-prises – The enterprise and its constituents as hybrid agents. In Karvoinen, I. et al. (Eds.), Global Engineering and Manufacturing in Enterprise Networks (pp. 91–103). Helsinki, Finland: VTT.

Bernus, P., Nemes, L., & Smith, G. (Eds.). (2003). Handbook on enterprise architecture. Berlin: Springer. doi:10.1007/978-3-540-24744-9.

Bernus, P., Nemes, L., & Williams, T. J. (Eds.). (1996). Architectures for enterprise integration. London: Chapman and Hall. doi:10.1007/978-0-387-34941-1.

96


Brooks, F. Jr. (1982). The mythical man month. Reading, MA: Addison-Wesley.

Castellani, B. (2009). Complexity map. Re-trieved from http://www.art-sciencefactory.com/complexity-map_feb09.html

Chaitin, G. J. (1966). On the length of programs for computing finite binary sequences. Journal of the ACM, 13, 547–569. doi:10.1145/321356.321363.

Cover, T. M., & Thomas, J. A. (2006). Elements of information theory (2nd ed.). Hoboken, NJ: Wiley.

Dromey, R. G. (2006). Formalizing the transition from requirements to design. In Liu, Z., & He, J. (Eds.), Mathematical Frameworks for Com-ponent Software, Models for Analysis and Syn-thesis (pp. 173–206). London: World Scientific. doi:10.1142/9789812772831_0006.

Erl, T. (2005). Service-oriented architecture: concepts, technology, and design. Hoboken, NJ: Prentice Hall.

Gell-Mann, M. (1994). Complex adaptive systems. In Cowan, G. A., Pines, D., & Meltzer, D. (Eds.), Complexity: Metaphors, models, and reality (pp. 17–45). Reading, MA: Addison-Wesley.

Gershenson, C. (2002). Complex philosophy. In Proceedings of the 1st Biennial Seminar on Philosophical, Methodological & Epistemological Implications of Complexity Theory. La Habana, Cuba: Academic Press.

Gershenson, C. (2004). Introduction to random Boolean networks. In M. Bedau, P. Husbands, T. Hutton, S. Kumar, & H. Suzuki (Eds.), Proceed-ings of the 9th International Conference on the Simulation and Synthesis of Living Systems, (pp. 160-173). Retrieved from http://arxiv.org/abs/nlin/0408006

Gershenson, C. (2007). Design and control of self-organizing systems. Mexico City: CopIt ArXives.

Holland, J. H. (1992). Complex adaptive systems. Daedalus, 121(1), 17–30.

IFIP-IFAC Task Force. (1999). GERAM - The generalised enterprise reference architecture and methodology. In Bernus, P., Nemes, L., & Schmidt, G. (Eds.), Handbook on Enterprise Architecture (pp. 22–64). Berlin: Springer.

ISO15288. (2000). Systems and software engineer-ing – System life cycle processes. Geneva: ISO.

ISO15704. (2000). Industrial automation sys-tems – Requirements for enterprise reference architectures and methodologies. Geneva: ISO TC184.SC5.WG1.

Jennings, N. R., & Wooldridge, M. (1995). Ap-plying agent technology. Journal of Applied AI, 9(4), 351–361.

Kandjani, H., & Bernus, P. (2011). Engineering self-designing enterprises as complex systems usingextended axiomatic design theory. IFAC Papers OnLine, 18(1), 11943–11948.

Kauffman, S. A. (1993). The origins of order: Self-organization and selection in evolution. New York: Oxford University Press.

Kolmogorov, A. N. (1969). On the logical founda-tions of information theory and probability theory. Problems of Information Transmission, 5(3), 1–4.

Krafzig, D., Banke, K., & Slama, D. (2004). En-terprise SOA: Service-oriented architecture best practices. Upper Saddle River, NJ: Prentice Hall.

Li, H., & Williams, T. J. (1994). A formalization and extension of the Purdue enterprise reference architecture and the Purdue methodology. TR 158 Purdue Lab. of Applied Industrial Control. West Lafayette, IN: Purdue University.

Li, M., & Vitányi, P. (2008). An introduction to Kolmogorov complexity and its applications (3rd ed.). Berlin: Springer. doi:10.1007/978-0-387-49820-1.

97


Lloyd, S. (2001). Measures of complexity: A non-exhaustive list. IEEE Control Systems Magazine, 21(4), 7–8. doi:10.1109/MCS.2001.939938.

Melvin, J. (2003). Axiomatic system design: Chemical mechanical polishing machine case study. (PhD Thesis in Mechanical Engineering). MIT, Cambridge, MA.

Meyer, B. (1988). Object-oriented software con-struction. Englewood Cliffs, NJ: Prentice Hall.

Moghaddam, M. R. S., Sharifi, A., & Merati, E. (2008). Using axiomatic design in the process of enterprise architecting. In Proceedings of the 3rd International Conference on Convergence and Hybrid Information Technology, (pp. 279-284). ICCT.

Nannen, V. A. (2010). Short introduction to model selection, Kolmogorov complexity and minimum description length (MDL). Retrieved from http://arxiv.org/abs/1005.2364

Nierstrasz, O., Gibbs, S., & Tsichritzis, D. (1992). Component-oriented software development. Communications of the ACM, 35(9), 160–164. doi:10.1145/130994.131005.

Osterweil, L. (1987). Software processes are soft-ware too. In Proceedings of the 9th International Conference on Software Engineering, (pp. 2-13). Los Alamitos, CA: IEEE.

Saha, P. (2006). A real options perspective to enterprise architecture as an investment activity. Journal of Enterprise Architecture, 2(3), 50.

Smarr, L. (1985). An approach to complex-ity: Numerical computations. Science, 228, 403–403. doi:10.1126/science.228.4698.403 PMID:17746870.

Snyder, A. (1986). Encapsulation and inheri-tance in object-oriented programming languag-es. ACM SIGPLAN Notices, 21(11), 38–45. doi:10.1145/960112.28702.

Suh, N. P. (1990). The principles of design. New York: Oxford University Press.

Suh, N. P. (1999). A theory of complexity, periodic-ity and the design axioms. Research in Engineering Design, 11, 116–133. doi:10.1007/PL00003883.

Suh, N. P. (2001). Axiomatic design: Advances and applications. New York: Oxford University Press.

Suh, N. P. (2003). Complexity: Theory and ap-plications. New York: Oxford University Press.

Suh, N. P. (2005). Complexity in engineering. CIRP Annals-Manufacturing Technology, 54(2), 46–63. doi:10.1016/S0007-8506(07)60019-5.

Suh, N. P., & Do, S. (2000). Axiomatic design of software systems. CIRP Annals-Manuf Tech-nology, 49(1), 95–100. doi:10.1016/S0007-8506(07)62904-7.

Vitányi, P. (2007). Analysis of sorting algorithms by Kolmogorov complexity (a survey). Entropy, Search, Complexity. Bolyai Society Mathematical Studies, 16, 209–232. doi:10.1007/978-3-540-32777-6_9.

von Bertalanffy, L. (1968). General system theory: Foundations, development, applications. New York: George Braziller.

Wen, L., & Dromey, R. G. (2006). Architecture normalization for component-based systems. Electronic Notes in Theoretical Computer Science, 160, 335–348. doi:10.1016/j.entcs.2006.05.032.

Wen, L., & Dromey, R. G. (2009). A hierarchical architecture for modeling complex software inten-sive systems using behavior trees. In Proceedings of the 9th Asia-Pacific Complex Systems Confer-ence, (pp. 292-299). IEEE.

Williams, T. J. (1994). Purdue guide for master planning & implementation programs. West-Lafayette, IN: Purdue University.

98


KEY TERMS AND DEFINITIONS

Axiom I: Independence Axiom: “The inde-pendence of FRs must always be maintained.” It means that a FRi is independent of other FRs if there exists a solution, i.e. list of ‘design param-eters’ [DP], such that if changing one FRi only one DP needs to be changed.

Axiom II: Information Axiom: “Out of the designs that satisfy Axiom I that design is best that has the minimal information content.”

Axiom III: Recursion Axiom: The system that designs a system must satisfy Axioms I & II of design.

Axiomatic Design Theory: Is a theory primar-ily originated from Mechanical Engineering and applied in several other design-related disciplines. AD theory helps to understand and design com-plex systems, claiming to codify (in a discipline-independent way) what a ‘best design’ is. AD had its own definition of ‘complex’, explaining reasons of emerging complexity in design. AD is also a formal design theory, defining principles that designers of systems need to follow to produce systems with minimal complexity (in Suh’s sense).

Complex System: According to Axiomatic Design Theory a ‘complex’ system is one that can not be predicted for certain that it will always satisfy its functional requirements.

Coupled Design: If [[A]] can not be rearranged to be triangular then the design is coupled, and con-sequently the implementation is not ‘serialisable.’

Decoupled Design: If [[A]] is triangular then the design is decoupled, and as a result the implementation process of DPs is ‘serialisable’.

Design Matrix: A design or transition matrix [[A]], is a matrix that maps Design Parameters

[DP] to Functional Requirements [FR]. According to Suh, design is a process to find DPs such that [FR] = [[A]] × [DP], where [FR] is the vector of FRs, [DP] is the vector of DPs and [[A]] is a matrix mapping DPs to FRs.

Information Content: Suh defined infor-mation content as the negative logarithm of the ‘probability of success’ which is the probability of satisfying all the functional requirements.

Kolmogorov Complexity: The Kolmogorov complexity K xU ( ) of a string x with respect to a universal computer U is defined as the length l of the shortest program p running on U that prints x and halts.

Number of Relevant States: An approximate complexity measure, and as the ‘Information Con-tent’ (IC) of a system, it is the information that the system must have about its environment. Note that ‘knowing the state of the environment’ may include knowing state history if this is relevant for determining what is the system’s appropriate response, and ‘state’ should be interpreted in an abstract sense.

Self-Evolving System: A self-evolving system is a system which can perform its own life-cycle activities by using its own resources or acquiring them from others.

The Self-Design Hypothesis: The system (or system of systems) and the designer (or group of designers or design authorities) should not be separated: systems and subsystems should design themselves out of component systems with the same self-designing property.

Uncoupled Design: If [[A]] is a diagonal matrix the design is called uncoupled, meaning that full independence of FRs is achieved.

Enterprises as Complex Systems: Extended Axiomatic Design Theory and its Application in Enterprise...

Documents

Transcript of Enterprises as Complex Systems: Extended Axiomatic Design Theory and its Application in Enterprise...