Cover image for Managing Complexity of Information Systems: The Value of Simplicity

Managing Complexity of Information Systems: The Value of Simplicity

Author Mederic Morel , Pirmin P. Lemberger
Release Date: 2012/01/01
ISBN: 9781118566053
Topic:
0%
18
Chapters
0-1
Hours read
0k
Total Words
    Start Reading Now    
       Add to Wishlist       
View table of contents

Book Description

This book is about complexity in Information Systems (IS). The subject is addressed from both conceptual and applied perspectives. Concepts are drawn from information theory, industrial design and software engineering. Its content capitalizes on experiences gathered by the authors during various contracting jobs involving software architecture, modeling and IS architecture that were conducted for large organizations in the banking and industry sectors, as well as in the public sector.

The authors develop the point of view according to which mastering complexity involves two essential steps: first, one should develop a clear understanding of the real nature of complexity within the IS; second, one should identify the primary causes which contribute to its uncontrolled growth and organize these into a logical framework, in order to define efficient countermeasures. Both technical and psychological causes of complexity are to be considered. Two themes make up the main thread of the book: complexity and value. Both themes are quite common when considered separately, but their interplay remains a largely unexplored topic. The analysis of this interplay is one of the sources of originality of this book.

Book Description

This book is about complexity in Information Systems (IS). The subject is addressed from both conceptual and applied perspectives. Concepts are drawn from information theory, industrial design and software engineering. Its content capitalizes on experiences gathered by the authors during various contracting jobs involving software architecture, modeling and IS architecture that were conducted for large organizations in the banking and industry sectors, as well as in the public sector.

The authors develop the point of view according to which mastering complexity involves two essential steps: first, one should develop a clear understanding of the real nature of complexity within the IS; second, one should identify the primary causes which contribute to its uncontrolled growth and organize these into a logical framework, in order to define efficient countermeasures. Both technical and psychological causes of complexity are to be considered. Two themes make up the main thread of the book: complexity and value. Both themes are quite common when considered separately, but their interplay remains a largely unexplored topic. The analysis of this interplay is one of the sources of originality of this book.

Table of Contents

  1. Cover
  2. Title Page
  3. Copyright
  4. Foreword
  5. Preface
  6. Chapter 1: Why Simplicity?
    1. 1.1. Solving conflicting requirements
    2. 1.2. Three periods in IS management
      1. 1.2.1. Management driven by technology
      2. 1.2.2. Management through cost reduction
      3. 1.2.3. Management through value creation
    3. 1.3. And now … simplicity!
      1. 1.3.1. Technology, cost reduction, value creation …So whats next?
    4. 1.4. Plan of the book
  7. Chapter 2: Complexity, Simplicity, and Abstraction
    1. 2.1. What does information theory tell us?
      1. 2.1.1. Shannons entropy
      2. 2.1.2. Kolmogorov complexity
        1. 2.1.2.1. Complexity of objects versus complexity of binary strings
        2. 2.1.2.2. Relation to Shannons entropy
        3. 2.1.2.3. Can we compute K-complexity?
      3. 2.1.3. Bennetts logical depth
      4. 2.1.4. Abstraction in light of scale and depth
      5. 2.1.5. Harvesting information theory
    2. 2.2. What does the design tell us?
      1. 2.2.1. Simplicity by reduction
      2. 2.2.2. Simplicity by hiding complexity
        1. 2.2.2.1. Customers
        2. 2.2.2.2. Business analysts
        3. 2.2.2.3. IT personnel
      3. 2.2.3. Simplicity through organization
      4. 2.2.4. Simplicity through learning
        1. 2.2.4.1. Learning obviates the need to hide complexity
        2. 2.2.4.2. Learning allows complexity transformation
      5. 2.2.5. Simplicity implies time saving
        1. 2.2.5.1. Lack of time
        2. 2.2.5.2. How simplicity saves time
      6. 2.2.6. Simplicity needs trust
      7. 2.2.7. What does software architecture tell us?
        1. 2.2.7.1. The complexity of code and of IS architecture
          1. 2.2.7.1.1. Cyclomatic complexity
          2. 2.2.7.1.2. Scale-invariant complexity
            1. 2.2.7.1.2.1. The spaghetti graph
            2. 2.2.7.1.2.2. The hierarchical graph
      8. 2.2.8. Abstraction in software engineering
        1. 2.2.8.1. Abstraction is everywhere in software 60
        2. 2.2.8.2. Depth and scale revisited
          1. 2.2.8.2.1. Object-oriented programming
          2. 2.2.8.2.2. Good or bad abstraction?
          3. 2.2.8.2.3. Good abstraction is a form of simplicity!
            1. 2.2.8.2.3.1. MDA and abstraction
            2. Chapter 3: Value or Values?
              1. 3.1. Who is concerned?
                1. 3.1.1. Internal stakeholders
                2. 3.1.2. External stakeholders
              2. 3.2. Concepts of value for an IS
                1. 3.2.1. Book value
                2. 3.2.2. Net worth
                3. 3.2.3. Use value
                  1. 3.2.3.1. Functional criterion
                  2. 3.2.3.2. Non-functional criteria
                4. 3.2.4. Strategic value
                5. 3.2.5. Sustainability value
              3. 3.3. Are these values sufficient and independent?
                1. 3.3.1. IT chaos
                2. 3.3.2. Tech academy
                3. 3.3.3. Alignment trap
                4. 3.3.4. Users are unimportant
                5. 3.3.5. Business-user tyranny
                6. 3.3.6. Wrong direction
                7. 3.3.7. Architecture is a waste of money
                8. 3.3.8. IS heaven
            3. Chapter 4: Promoting Value Through Simplicity
              1. 4.1. Growing technical heterogeneity
                1. 4.1.1. Openness
                  1. 4.1.1.1. Why complexity increases
                  2. 4.1.1.2. Implementing simplicity
                2. 4.1.2. Rapid obsolescence of IT
                  1. 4.1.2.1. Why complexity increases
                  2. 4.1.2.2. Implementing simplicity
                3. 4.1.3. Absence of technological vision and leadership
                  1. 4.1.3.1. Why complexity increases
                  2. 4.1.3.2. Implementing simplicity
              2. 4.2. Changing requirements
                1. 4.2.1. Why complexity increases
                2. 4.2.2. Implementing simplicity
                  1. 4.2.2.1. Technical answers
                    1. 4.2.2.1.1. Reuse in software architecture
                    2. 4.2.2.1.2. Reuse in functional architecture
                    3. 4.2.2.1.3. Reuse on the semantic level
                  2. 4.2.2.2. Organizational answers
                    1. 4.2.2.2.1. Achieving agility
                    2. 4.2.2.2.2. Deciding when writing throwaway code is the best option?
              3. 4.3. Human factors
                1. 4.3.1. Multidisciplinarity
                  1. 4.3.1.1. Why complexity increases
                  2. 4.3.1.2. Implementing simplicity
                2. 4.3.2. Disempowerment of IT Skills
                  1. 4.3.2.1. Why complexity increases
                  2. 4.3.2.2. Implementing simplicity
                3. 4.3.3. Local interest is not global interest
                  1. 4.3.3.1. Why complexity increases
                  2. 4.3.3.2. Implementing simplicity
            4. Chapter 5: Simplicity Best Practices
              1. 5.1. Putting simplicity principles into practice
              2. 5.2. Defining a generic IS
              3. 5.3. A simplicity framework
                1. 5.3.1. Simplicity in hardware
                  1. 5.3.1.1. Growing technical heterogeneity
                    1. 5.3.1.1.1. Evaluation
                    2. 5.3.1.1.2. Simplicity actions
                  2. 5.3.1.2. Changing requirements
                    1. 5.3.1.2.1. Evaluation
                    2. 5.3.1.2.2. Simplicity actions
                  3. 5.3.1.3. Human factors
                    1. 5.3.1.3.1. Evaluation
                    2. 5.3.1.3.2. Simplicity actions
                2. 5.3.2. Simplicity in software data access
                  1. 5.3.2.1. Growing technical heterogeneity
                    1. 5.3.2.1.1. Evaluation
                    2. 5.3.2.1.2. Simplicity actions
                  2. 5.3.2.2. Changing requirements
                    1. 5.3.2.2.1. Evaluation
                    2. 5.3.2.2.2. Simplicity actions
                  3. 5.3.2.3. Human factors
                    1. 5.3.2.3.1. Evaluation
                    2. 5.3.2.3.2. Simplicity actions
                3. 5.3.3. Simplicity in software services
                  1. 5.3.3.1. Growing technical heterogeneity
                    1. 5.3.3.1.1. Evaluation
                    2. 5.3.3.1.2. Simplicity actions
                  2. 5.3.3.2. Changing requirements
                    1. 5.3.3.2.1. Evaluation
                    2. 5.3.3.2.2. Simplicity actions
                  3. 5.3.3.3. Human factors
                    1. 5.3.3.3.1. Evaluation
                    2. 5.3.3.3.2. Simplicity actions
                4. 5.3.4. Simplicity in softwareuser interface
                  1. 5.3.4.1. Growing technical heterogeneity
                    1. 5.3.4.1.1. Evaluation
                    2. 5.3.4.1.2. Simplicity actions
                  2. 5.3.4.2. Changing requirements
                    1. 5.3.4.2.1. Evaluation
                    2. 5.3.4.2.2. Simplicity actions
                  3. 5.3.4.3. Human factors
                    1. 5.3.4.3.1. Evaluation
                    2. 5.3.4.3.2. Simplicity actions
                5. 5.3.5. Simplicity in Functional Architecture
                  1. 5.3.5.1. Growing technical heterogeneity
                    1. 5.3.5.1.1. Evaluation
                    2. 5.3.5.1.2. Simplicity actions
                  2. 5.3.5.2. Changing requirements
                    1. 5.3.5.2.1. Evaluation
                    2. 5.3.5.2.2. Simplicity actions
                  3. 5.3.5.3. Human factors
                    1. 5.3.5.3.1. Evaluation
                    2. 5.3.5.3.2. Simplicity actions
                    3. Conclusion
                    4. Appendices
                      1. Appendix 1: Digging into Information Theory
                        1. A1.1. Shannon entropy
                        2. A1.2. Shannon entropy in short
                        3. A1.3. Kolmogorov complexity
                        4. A1.4. Choosing a scale of description
                        5. A1.5. Relation to Shannon entropy
                        6. A1.6. Computing the Kolmogorov complexity
                        7. A1.7. Kolmogorov complexity in short
                        8. A1.8. Bennetts logical depth
                        9. A1.9. Bennetts logical depth in short
                      2. Appendix 2: Two Measures of Code Complexity
                        1. A2.1. Cyclomatic complexity
                        2. A2.2. An example of a scale-invariant complexity measure
                        3. A2.3. Conclusion
                      3. Appendix 3: Why Has SOA Failed So Often?
                        1. A.3.1. The need for flexibility
                        2. A.3.2. First issue: no suitable enterprise architecture
                        3. A.3.3. Second issue: no data integration
                        4. A.3.4. Identifying the operating model
                          1. A.3.4.1. Data integration
                          2. A.3.4.2. Process standardization
                        5. A.3.5. Which models are compatible with SOA?
                          1. A.3.5.1. Diversification model
                          2. A.3.5.2. Replication model
                          3. A.3.5.3. Coordination model
                          4. A.3.5.4. Unification model
                        6. A.3.6. Conclusion on SOA
                    5. Bibliography
                    6. Index
18.118.226.105