Cover -- Managing Complexity of Information Systems -- Title Page -- Copyright Page -- Table of Contents -- Foreword -- Preface -- Chapter 1. Why Simplicity? -- 1.1. Solving conflicting requirements -- 1.2. Three periods in IS management -- 1.2.1. Management driven by technology -- 1.2.2. Management through cost reduction -- 1.2.3. Management through value creation -- 1.3. And now … simplicity! -- 1.3.1. Technology, cost reduction, value creation … So what's next? -- 1.4. Plan of the book -- Chapter 2. Complexity, Simplicity, and Abstraction -- 2.1. What does information theory tell us? -- 2.1.1. Shannon's entropy -- 2.1.2. Kolmogorov complexity -- 2.1.2.1. Complexity of objects versus complexity of binary strings -- 2.1.2.2. Relation to Shannon's entropy -- 2.1.2.3. Can we compute K-complexity? -- 2.1.3. Bennett's logical depth -- 2.1.4. Abstraction in light of scale and depth -- 2.1.5. Harvesting information theory -- 2.2. What does the design tell us? -- 2.2.1. Simplicity by reduction -- 2.2.2. Simplicity by hiding complexity -- 2.2.2.1. Customers -- 2.2.2.2. Business analysts -- 2.2.2.3. IT personnel -- 2.2.3. Simplicity through organization -- 2.2.4. Simplicity through learning -- 2.2.4.1. Learning obviates the need to hide complexity -- 2.2.4.2. Learning allows complexity transformation -- 2.2.5. Simplicity implies time saving -- 2.2.5.1. Lack of time -- 2.2.5.2. How simplicity saves time -- 2.2.6. Simplicity needs trust -- 2.2.7. What does software architecture tell us? -- 2.2.7.1. The complexity of code and of IS architecture -- 2.2.8. Abstraction in software engineering -- 2.2.8.1. Abstraction is everywhere in software -- 2.2.8.2. Depth and scale revisited -- Chapter 3. Value or Values? -- 3.1. Who is concerned? -- 3.1.1. Internal stakeholders -- 3.1.2. External stakeholders -- 3.2. Concepts of value for an IS -- 3.2.1. Book value.

3.2.2. Net worth -- 3.2.3. Use value -- 3.2.3.1. Functional criterion -- 3.2.3.2. Non-functional criteria -- 3.2.4. Strategic value -- 3.2.5. Sustainability value -- 3.3. Are these values sufficient and independent? -- 3.3.1. IT chaos -- 3.3.2. Tech academy -- 3.3.3. Alignment trap -- 3.3.4. Users are unimportant -- 3.3.5. Business-user tyranny -- 3.3.6. Wrong direction -- 3.3.7. Architecture is a waste of money -- 3.3.8. IS heaven -- Chapter 4. Promoting Value Through Simplicity -- 4.1. Growing technical heterogeneity -- 4.1.1. Openness -- 4.1.1.1. Why complexity increases -- 4.1.1.2. Implementing simplicity -- 4.1.2. Rapid obsolescence of IT -- 4.1.2.1. Why complexity increases -- 4.1.2.2. Implementing simplicity -- 4.1.3. Absence of technological vision and leadership -- 4.1.3.1. Why complexity increases -- 4.1.3.2. Implementing simplicity -- 4.2. Changing requirements -- 4.2.1. Why complexity increases -- 4.2.2. Implementing simplicity -- 4.2.2.1. Technical answers -- 4.2.2.2. Organizational answers -- 4.3. Human factors -- 4.3.1. Multidisciplinarity -- 4.3.1.1. Why complexity increases -- 4.3.1.2. Implementing simplicity -- 4.3.2. Disempowerment of IT Skills -- 4.3.2.1. Why complexity increases -- 4.3.2.2. Implementing simplicity -- 4.3.3. Local interest is not global interest -- 4.3.3.1. Why complexity increases -- 4.3.3.2. Implementing simplicity -- Chapter 5. Simplicity Best Practices -- 5.1. Putting simplicity principles into practice -- 5.2. Defining a generic IS -- 5.3. A simplicity framework -- 5.3.1. Simplicity in hardware -- 5.3.1.1. Growing technical heterogeneity -- 5.3.1.2. Changing requirements -- 5.3.1.3. Human factors -- 5.3.2. Simplicity in software - data access -- 5.3.2.1. Growing technical heterogeneity -- 5.3.2.2. Changing requirements -- 5.3.2.3. Human factors -- 5.3.3. Simplicity in software - services.

5.3.3.1. Growing technical heterogeneity -- 5.3.3.2. Changing requirements -- 5.3.3.3. Human factors -- 5.3.4. Simplicity in software-user interface -- 5.3.4.1. Growing technical heterogeneity -- 5.3.4.2. Changing requirements -- 5.3.4.3. Human factors -- 5.3.5. Simplicity in functional architecture -- 5.3.5.1. Growing technical heterogeneity -- 5.3.5.2. Changing requirements -- 5.3.5.3. Human factors -- Conclusion -- APPENDICES -- Appendix 1. Digging into Information Theory -- A1.1. Shannon entropy -- A1.2. Shannon entropy in short -- A1.3. Kolmogorov complexity -- A1.4. Choosing a scale of description -- A1.5. Relation to Shannon entropy -- A1.6. Computing the Kolmogorov complexity -- A1.7. Kolmogorov complexity in short -- A1.8. Bennett's logical depth -- A1.9. Bennett's logical depth in short -- Appendix 2. Two Measures of Code Complexity -- A2.1. Cyclomatic complexity -- A2.2. An example of a scale-invariant complexity measure -- A2.3. Conclusion -- Appendix 3. Why Has SOA Failed So Often? -- A.3.1. The need for flexibility -- A.3.2. First issue: no suitable enterprise architecture -- A.3.3. Second issue: no data integration -- A.3.4. Identifying the operating model -- A.3.4.1. Data integration -- A.3.4.2. Process standardization -- A.3.5. Which models are compatible with SOA? -- A.3.5.1. Diversification model -- A.3.5.2. Replication model -- A.3.5.3. Coordination model -- A.3.5.4. Unification model -- A.3.6. Conclusion on SOA -- Bibliography -- Index.