book

Managing Complexity of Information Systems: The Value of Simplicity

by Pirmin P. Lemberger, Mederic Morel

January 2012

Intermediate to advanced

225 pages

4h 25m

English

Wiley

Read now

Unlock full access

Cover
Title Page
Copyright
Foreword
Preface
Chapter 1: Why Simplicity?
1.1. Solving conflicting requirements1.2. Three periods in IS management1.2.1. Management driven by technology1.2.2. Management through cost reduction1.2.3. Management through value creation1.3. And now … simplicity!1.3.1. Technology, cost reduction, value creation …So whats next?1.4. Plan of the book
Chapter 2: Complexity, Simplicity, and Abstraction
2.1. What does information theory tell us?2.1.1. Shannons entropy2.1.2. Kolmogorov complexity2.1.2.1. Complexity of objects versus complexity of binary strings2.1.2.2. Relation to Shannons entropy2.1.2.3. Can we compute K-complexity?2.1.3. Bennetts logical depth2.1.4. Abstraction in light of scale and depth2.1.5. Harvesting information theory2.2. What does the design tell us?2.2.1. Simplicity by reduction2.2.2. Simplicity by hiding complexity2.2.2.1. Customers2.2.2.2. Business analysts2.2.2.3. IT personnel2.2.3. Simplicity through organization2.2.4. Simplicity through learning2.2.4.1. Learning obviates the need to hide complexity2.2.4.2. Learning allows complexity transformation2.2.5. Simplicity implies time saving2.2.5.1. Lack of time2.2.5.2. How simplicity saves time2.2.6. Simplicity needs trust2.2.7. What does software architecture tell us?2.2.7.1. The complexity of code and of IS architecture2.2.7.1.1. Cyclomatic complexity2.2.7.1.2. Scale-invariant complexity2.2.7.1.2.1. The spaghetti graph2.2.7.1.2.2. The hierarchical graph2.2.8. Abstraction in software engineering2.2.8.1. Abstraction is everywhere in software 602.2.8.2. Depth and scale revisited2.2.8.2.1. Object-oriented programming2.2.8.2.2. Good or bad abstraction?2.2.8.2.3. Good abstraction is a form of simplicity!2.2.8.2.3.1. MDA and abstraction
Chapter 3: Value or Values?
3.1. Who is concerned?3.1.1. Internal stakeholders3.1.2. External stakeholders3.2. Concepts of value for an IS3.2.1. Book value3.2.2. Net worth3.2.3. Use value3.2.3.1. Functional criterion3.2.3.2. Non-functional criteria3.2.4. Strategic value3.2.5. Sustainability value3.3. Are these values sufficient and independent?3.3.1. IT chaos3.3.2. Tech academy3.3.3. Alignment trap3.3.4. Users are unimportant3.3.5. Business-user tyranny3.3.6. Wrong direction3.3.7. Architecture is a waste of money3.3.8. IS heaven
Chapter 4: Promoting Value Through Simplicity
4.1. Growing technical heterogeneity4.1.1. Openness4.1.1.1. Why complexity increases4.1.1.2. Implementing simplicity4.1.2. Rapid obsolescence of IT4.1.2.1. Why complexity increases4.1.2.2. Implementing simplicity4.1.3. Absence of technological vision and leadership4.1.3.1. Why complexity increases4.1.3.2. Implementing simplicity4.2. Changing requirements4.2.1. Why complexity increases4.2.2. Implementing simplicity4.2.2.1. Technical answers4.2.2.1.1. Reuse in software architecture4.2.2.1.2. Reuse in functional architecture4.2.2.1.3. Reuse on the semantic level4.2.2.2. Organizational answers4.2.2.2.1. Achieving agility4.2.2.2.2. Deciding when writing throwaway code is the best option?4.3. Human factors4.3.1. Multidisciplinarity4.3.1.1. Why complexity increases4.3.1.2. Implementing simplicity4.3.2. Disempowerment of IT Skills4.3.2.1. Why complexity increases4.3.2.2. Implementing simplicity4.3.3. Local interest is not global interest4.3.3.1. Why complexity increases4.3.3.2. Implementing simplicity
Chapter 5: Simplicity Best Practices
5.1. Putting simplicity principles into practice5.2. Defining a generic IS5.3. A simplicity framework5.3.1. Simplicity in hardware5.3.1.1. Growing technical heterogeneity5.3.1.1.1. Evaluation5.3.1.1.2. Simplicity actions5.3.1.2. Changing requirements5.3.1.2.1. Evaluation5.3.1.2.2. Simplicity actions5.3.1.3. Human factors5.3.1.3.1. Evaluation5.3.1.3.2. Simplicity actions5.3.2. Simplicity in software data access5.3.2.1. Growing technical heterogeneity5.3.2.1.1. Evaluation5.3.2.1.2. Simplicity actions5.3.2.2. Changing requirements5.3.2.2.1. Evaluation5.3.2.2.2. Simplicity actions5.3.2.3. Human factors5.3.2.3.1. Evaluation5.3.2.3.2. Simplicity actions5.3.3. Simplicity in software services5.3.3.1. Growing technical heterogeneity5.3.3.1.1. Evaluation5.3.3.1.2. Simplicity actions5.3.3.2. Changing requirements5.3.3.2.1. Evaluation5.3.3.2.2. Simplicity actions5.3.3.3. Human factors5.3.3.3.1. Evaluation5.3.3.3.2. Simplicity actions5.3.4. Simplicity in softwareuser interface5.3.4.1. Growing technical heterogeneity5.3.4.1.1. Evaluation5.3.4.1.2. Simplicity actions5.3.4.2. Changing requirements5.3.4.2.1. Evaluation5.3.4.2.2. Simplicity actions5.3.4.3. Human factors5.3.4.3.1. Evaluation5.3.4.3.2. Simplicity actions5.3.5. Simplicity in Functional Architecture5.3.5.1. Growing technical heterogeneity5.3.5.1.1. Evaluation5.3.5.1.2. Simplicity actions5.3.5.2. Changing requirements5.3.5.2.1. Evaluation5.3.5.2.2. Simplicity actions5.3.5.3. Human factors5.3.5.3.1. Evaluation5.3.5.3.2. Simplicity actions

Conclusion
Appendices
Appendix 1: Digging into Information Theory
A1.1. Shannon entropyA1.2. Shannon entropy in shortA1.3. Kolmogorov complexityA1.4. Choosing a scale of descriptionA1.5. Relation to Shannon entropyA1.6. Computing the Kolmogorov complexityA1.7. Kolmogorov complexity in shortA1.8. Bennetts logical depthA1.9. Bennetts logical depth in short
Appendix 2: Two Measures of Code Complexity
A2.1. Cyclomatic complexityA2.2. An example of a scale-invariant complexity measureA2.3. Conclusion
Appendix 3: Why Has SOA Failed So Often?
A.3.1. The need for flexibilityA.3.2. First issue: no suitable enterprise architectureA.3.3. Second issue: no data integrationA.3.4. Identifying the operating modelA.3.4.1. Data integrationA.3.4.2. Process standardizationA.3.5. Which models are compatible with SOA?A.3.5.1. Diversification modelA.3.5.2. Replication modelA.3.5.3. Coordination modelA.3.5.4. Unification modelA.3.6. Conclusion on SOA
Bibliography
Index

Content preview from Managing Complexity of Information Systems: The Value of Simplicity

Appendix 2Two Measures of Code Complexity

A2.1. Cyclomatic complexity

Among the myriad of metrics of code complexity available, cyclomatic complexity is probably the best known. Most code analysis tools can measure it.

Cyclomatic complexity aims to measure the amount of decision logic encapsulated in a software module or a function.

For simplicity, we shall assume henceforth that there is a single point of entry and a single exit point to the module whose complexity we wish to evaluate. Cyclomatic complexity is defined by first associating a control-flow graph to the code under consideration. Nodes in this graph represent elementary statements, while edges, which have a direction, represent transfer of control between these statements. This control-flow graph represents all possible execution paths through the module.

Figure A2.1. The flow graph associated to a piece of code containing one decision and one loop

The earlier definition of Shannon entropy could perhaps encourage us to define the complexity of the code simply as the total number of such execution paths (or its logarithm). This, however, would not account for the over-counting due to the many paths that are not truly independent. In other words, we should be aware that many paths can be obtained by combination of others. Cyclomatic complexity C_cycl precisely takes this into account and, assuming an entry point ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 9781118566053Purchase book

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

Managing Complexity of Information Systems: The Value of Simplicity

by Pirmin P. Lemberger, Mederic Morel

Appendix 2Two Measures of Code Complexity

A2.1. Cyclomatic complexity

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.