Measuring IT Complexity

Mike's Notes

Here is a small extract of an excellent paper written by Roger Sessions in 2009. It describes the maths he uses to describe IT complexity.

Sadly, his websites have not been updated for years, and many of the links to his excellent papers are now broken.

Usually, I use a webcrawler to archive excellent websites, but I didn't add ObjectWatch. I am now actively scouring the web to create an electronic archive of his work before it disappears.

His work was brilliant and deserves a wider audience.

Resources

References

  • The IT Complexity Crisis: Danger and Opportunity. A White Paper by Roger Sessions. October 22, 2009
  • Fact and Fallacies About Software Engineering. By Robert Glass
  • Woodfield, Scott N. 1979. “An Experiment on Unit Increase in Problem Complexity.” IEEE Transactions on Software Engineering, (Mar.) p76-79 Scott N. Woodfield:

Repository

  • Home > Ajabbi Research > Library > Authors > Roger Sessions
  • Home > Handbook > 

Last Updated

30/05/2025

Measuring IT Complexity

By: Roger Sessions
ObjectWatch 22/10/2009

Roger Sessions, a tireless advocate for efficiency through simplicity, is the CTO of ObjectWatch, a company he founded thirteen years ago. He has written seven books including his most recent, Simple Architectures for Complex Enterprises, and dozens of articles. He assists both public and private sector organizations in reducing IT complexity by blending existing architectural methodologies and SIP. In addition, Sessions provides architectural reviews and analysis. Sessions holds multiple patents in software and architectural methodology. He is a Fellow of the International Association of Software Architects (IASA), Editor-in-Chief of the IASA Perspectives Journal, and a Microsoft recognized MVP in Enterprise Architecture. A frequent keynote speaker, Sessions has presented in countries around the world on the topics of IT Complexity and Enterprise Architecture. Sessions has a Masters Degree in Computer Science from the University of Pennsylvania. He lives in Chappell Hill, Texas.

Roger loves feedback (and a good, stirring debate or two!) Join Roger in his crusade against complexity. His blog is SimpleArchitectures.blogspot.com and his Twitter ID is @RSessions.

...

Measuring IT complexity is easier than you might think. It all starts with Glass’s Law [06], that for every 25% increase in the complexity of the problem space, there is a 100% increase in the complexity of the solution space. In IT systems, there are two contributors to the complexity of the problem space. The first is the number of business functions in the system. The second is the number of connections that system has to other systems.

We need to start with a standard complexity unit (SCU). I’ll define one SCU as the amount of complexity that a system has which contains only one business function and no connections to other systems. Based on Glass’s Law, this is the least complex system possible.

Okay, we start with a system with one business function and no connections. By definition, this has 1 SCU. Now let’s start adding more business functions into the system. As we add more functions into the system, the number of SCUs goes up a predictable amount. This amount is calculated using Bird’s Formula. Bird is Chris Bird, who showed me how to rewrite Glass’s Law as a mathematical formula.

Let’s say a system S has bf number of business functions, and no connections to other systems. Then the number of SCUs in that system is given by

S = 10 raised to the power of ((log(2)/log(1.25) X log (bf))

The log(2) and the log(1.25) are both constants, and can thus be combined, giving

S = 10 raised to the power of (3.1 X log(bf))

or, more simply,

S = 10 3.1 log(bf)

Similarly, we can calculate the complexity of a system with one business function and cn connections to other systems. Note that I am simplifying the analysis by assuming that a new connection adds about the same amount of complexity as a new business function, which follows my experience. If you don’t agree, it is easy enough to modify the equation accordingly. But given my assumption, the complexity because of connections is as follows:

S = 10 3.1 log(cn)

Most systems have both multiple business functions and multiple connections, so we need to add the two together:

S = 10 3.1 log(bf) + 10 3.1 log(cn)

Most systems are not made of a single system, but a number of smaller systems, each of which has a complexity described by the above equations. An SOA, for example, would have multiple services, each of which has a complexity rating.

If we assume that our system is an SOA, then the complexity of the SOA as a whole is the summation of the complexity of each of the individual services. This is expressed as what I describe as Sessions’s Summation of Bird’s Formulation of Glass’s Law. It looks like this:


Now while Sessions’s Summation looks rather ugly, it is in fact easily calculated using a straightforward spreadsheet.

Sessions’s Summation gives us an easy way to compare two different architectures with respect to their complexity. Just plug both into Sessions’s Summation and read the resulting number. That number is the complexity in SCUs of the architecture. If one architecture has a total SCU of 1,000 and another a total SCU of 500, then the first is twice as complex as the second. It is also twice as likely to fail.

Notice that while functionality is a factor in complexity, it is not the major factor. Much larger factors are how many services there are, how many functions there are in each of the services and how those services are connected to each other.

...

[06] Glass’s Law comes from Robert Glass’s Fact and Fallacies About Software Engineering. He did not discover the law. He actually described it from a paper by Scott Woodfield, but Glass did more than anybody to publicize the law.

By ,
Tags , , ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)