The Mathematics of Simplification

People who know me, know that I am a huge fan of mathematical foundations for anything related to architecture. We have far too many frameworks, methods and theories that are not scientifically (e.g. mathematically) founded. It is my believe that this holds us, enterprise (IT) architects, back in delivering quality in a predictable and repeatable way. Much of the architecture work I come across can be cataloged under ‘something magical happened there’.

Examples

There are examples of mathematics being used to improve our knowledge and application of that knowledge.

Jason C. Smith has used mathematics to create a representation of design patterns that is independent of the programming language used. It allows you to analyse code or designs and find out which patterns actually have been used (or misused).

Odd Ivar Lindland has used simple set theory to create a basis to discuss quality of conceptual models. Highly recommended if you want to think more formally on the quality of your models.

Monique Snoeck and Guido Dedene have used algebra and formal concept analysis to create a method for conceptual information modeling, finite state machines and their consistency. A good introduction is the article ‘Existence Dependency: The key to semantic integrity between structural and behavioral aspects of object types‘.

This is just a grab in the formalization of Enterprise Architecture. There are many more examples!

The Mathematics of IT Simplification

Recently I came across a whitepaper from Roger Sessions titled ‘The Mathematics of IT Simplification’. In this white paper the author describes a formal method to partition a system so that it is an optimal partition. He offers a mathematical foundation to support his method. It’s really interesting and I would encourage anyone to have a look.

The whitepaper suffers from a serious defect though. It makes a few assumptions, some expliciet and some implicit, that are crucial to the conclusions. But some of those assumptions are not as safe or obvious after some scrutiny.

  1. Only two types of complexity are considered: functional and coordination}. The author states that only these two aspects of complexity exist or are relevant. It is also stated that aspects are also independent of each other. There are no references to existing research that supports this assumption nor is there any attempt being in the article itself to justify the assumption.
  2. The Glass constant. The author needs a way to quantify the increase of complexity when adding new functionality. He uses a statement made by Robert Glass. But how true or applicable is that statement? Even the author himself states Glass may or may not be right about these exact numbers, but they seem a reasonable assumption.
  3. Coordination complexity is like functional complexity. This is probably the most troublesome assumptions. The author builds up a (non scientifically) case for the mathematics for functional complexity. He fails to do this for coordination complexity and simply states that the same mathematics will probably apply.
  4. A final assumption, even though not explicitely made in the article but nevertheless present, is that adding a new function does not affect complexity of existing functions. I can imagine adding functions that actually lower complexity of existing functions. The article in fact is only valid for completely independent functions, which makes it not usuable with decomposition or dependent functions. But those are in fact the most common circumstances for doing complexity analysis to justify partitions

Nowhere in the article is there any scientific proof that these assumptions are ‘probably’ true. Arguments in favor of the assumptions are either leaning towards it is worst case so it can only get more precise or the assumptions feels right, doesn’t it. Neither of these are accepted in the scientific world. Scientists know how dangereous it is to base conclusions on assumptions that are not founded in research, be it empirical or theoretical.

Research to quantify complexity, even if just for comparison, is valuable. Therefore I applaud this effort but I would encourage the author to go forward with it:

  1. conduct empirical research to gather data that supports the assumptions made;
  2. find similar research that either supports or rebutes your assumptions and conclusions;
  3. and finally the most important, apply for publication in an A-level publication to get quality peer review.

All of the examples I gave in the introduction did these steps. Their conclusions are supported by empirical research, they stand on the shoulders of prior research and their work has been peer reviewed and published in A-level journals. That is the kind of scientific foundation Enterprise Architecture needs.