Saturday, October 29, 2011

SIP Complexity Model

SIP, as you probably know, stands for Simple Iterative Partitions, a methodology for finding the least complex solution to a complex IT problem. I have written about SIP elsewhere, for example, in my White Paper The Mathematics of IT Simplification. My goal in this blog is to give a high level description of the model SIP has for IT complexity.

This blog is a work in progress. I will modify it based on suggestions and eventually turn this into a white paper. So please leave your suggestions as comments. If I use them, I will credit you in the eventual white paper. You might want to subscribe to this blog, so that you can follow the discussion.

Let's assume that we have a business problem, BP, that needs an IT solution. Let's say a solution, S001, is proposed. There are a number of attributes of S001 that we could think about. One obvious attribute is how much of the business problem, BP, does S001 solve? In other words, high closely aligned is the solution S001 to the problem BP?

Let's say we have a function A that measures the alignment of S001 to BP and returns a result as an integer between 0 and 100, where 0 is complete non-alignment (S001 doesn't solve any of BP) to 100 (S001 completely solves BP.)

We can write this as y = A(BP, S001)

Let's say we also have a function C that measures the complexity of S001 and returns as a result some number of complexity units. I won't try to describe these complexity units here, but I have described them in the above referenced Mathematics white paper.

We can write this as x = C(S001)

Note that A is a binary function (it takes two arguments) because it must compare the proposed solution to the original problem. C, on the other hand is a unary function (it takes one argument) because complexity is not dependent on the problem, only the proposed solution.

Since S001 now has both a y value, A(BP, S001), and an x value, C(S001), we can plot it on a graph in which y is alignment and x is complexity. This is shown in Figure 1.

Figure 1. Graph of S001, A Solution to BP

Now BP doesn't just have one possible solution, it has a whole bunch of solutions. Let's say we have identified 25 possible solutions to BP. We can name these solutions S001, S002, ... S025.

Just as we plotted S001 in Figure 1, we can plot each of the other solutions. This is shown in Figure 2.

Figure 2. Graph of S001-S025

In general, the values of Sx will be bounded by a tetragon, as shown in Figure 3.

Figure 3. Complexity Tetragon Bounding Sx

Why are the values bounded by this tetragon? At the upper edge, values are bounded by alignment. It is not possible to have more than 100% alignment, so that cuts off values at the top. The x axis is bounded at the low end by the lowest complexity observed in any of Sxs and at the high end by the highest complexity observed in any of the Sxs.

The upper left corner of the tetragon is bounded in the x direction by the lowest possible complexity that still gives the maximum alignment with BP. We can still find simpler Sx, but they can only get simpler by losing functionality that BP needs.

The upper right corner of the tetragon is bounded in the x direction by the highest possible complexity that still gives the maximum alignment with BP. We can still find more complex Sx, but their complexity will result in a loss of ability to meet the needs of BP.

We can further divide the Complexity Tetragon from Figure 3 into four quadrants, as shown in Figure 4.

Figure 4. Four Quadrants of Complexity Tetragon

The lines marking the quadrant boundaries are shown as fuzzy because the boundaries themselves are fuzzy. We can focus on these quadrants by removing the points and adding quadrant names, as shown in Figure 5.
Figure 5. The Four Quadrants With Names

I'll come back to the quadrant names in a moment, but let's just consider the characteristics of solutions that live in each quadrant. The characteristics are as follows:
  • vital quadrant contains solutions that have low complexity and high alignment to the business problem.
  • stagnant quadrant contains solutions that have high complexity and high alignment to the business problem.
  • chaotic quadrant contains solutions that have high complexity and low alignment to the business problem.
  • simplistic quadrant contains solutions that have low complexity and low alignment to the business problem.
Now you might wonder why I have focused on complexity in the X axis. Why not, say, agility? The reason is that a number of important characteristics are all directly related to complexity. Agility, for example, goes up as complexity goes down and goes down as complexity goes up. A partial list of these characteristics and their relationship to complexity are as follows:
  • Agility, inversely related to complexity
  • Security, inversely related to complexity
  • Performance, inversely related to complexity
  • Reliability, inversely related to complexity
  • Cost, positively related to complexity
  • Time to deliver, positively related to complexity
A quick examination of the above list will show you that desirable characteristics go down as complexity increases and undesirable characteristics go up as complexity increases. Therefore complexity is the most important characteristic to consider. Mathematically, we can say that complexity is the independent variable and agility, security, etc are the dependent variables. I will not try to prove this assertion here, but I have written about this elsewhere (for example, in my book, Simple Architectures for Complex Enterprises.)

Now I can describe why I have named the quadrants as I have. 

Solutions in the vital quadrant have low complexity and good alignment to the problem. I call this quadrant vital because these solutions have the best agility of all the quadrants that are aligned with the business problem. Because solutions in this quadrant have high agility, they can change as needed.

Solutions in the stagnant quadrant also solve the problem, but at a high complexity cost. Among other problems, these solutions are hard to change as business needs change. I call this quadrant stagnant because solutions in this quadrant are stuck in time.

Solutions in the chaotic quadrant have no redeeming features. They do not solve the problem and they are highly complex. I call this quadrant chaotic because nothing useful comes out of it. Chaotic solutions get canceled someplace along the project life cycle before delivery, usually after considerable money is dumped into trying to make them work.

Solutions in the simplistic quadrant do not solve the business problem, but at least they are not burdened with overwhelming complexity. I call this quadrant simplistic because the solution is overly simplistic with respect to the need. A rock, for example is a simplistic car.

When considering a solution to a business problem, it is helpful to consider which quadrant that solution lives in. 

If the solution lives in the vital quadrant, you are in good shape. You have a solution to the business problem and it has low complexity and is thus highly likely to have a number of important characteristics (agility, etc.)

If the solution lives in the stagnant quadrant, the solution has hope. At least it appears to solve the business problem. Now you just need to focus on removing the complexity that is going to rob you of the characteristics you want.

If the solution lives in the chaotic quadrant, the solution has no hope. The best thing you can do is to kill the solution as quickly as possible and start from scratch. Learn your lessons and be happy you didn't lose more money.

If the solution lives in the simplistic quadrant, the solution has hope. At least you are not mired in complexity. Now just try to meet more of the business needs without substantially adding to the complexity.

Clearly, our ideal solutions live in the vital quadrant. But not all solutions in the vital quadrant are equal. The ideal ideal solution is the one in the upper left corner, shown as a target in Figure 6. This solution is the one with the absolute lowest complexity that still meets all of the business needs. This is the solution we would like to find.
Figure 6. Complexity Tetragon With Ideal Solution

So far, I have just looked at the SIP Complexity Quadrants at a moment in time. We can also look at how things drift over time. There are two distinct undertows that are pulling at solutions. One undertow is pulling from greater alignment to lesser alignment. The second undertow is pulling from lesser complexity to greater complexity. These undertows are added to the tetragon in Figure 7.

Figure 7. Complexity Tetragon With Undertows

By understanding the undertows we can predict that a solution that is vital on the day it is delivered is going to drift over time to being less aligned and more complex. This tells us that we need to put ongoing energy into fighting these undertows. We want to not only start out with a solution in the vital quadrant, we want to stay in that quadrant for the life of the solution. In fact, the lifetime of the solution will be highly influenced by which quadrant the solutions starts in and how effectively we fight the undertows after the solution is delivered.

Figure 7 now gives us a complete picture of the complexity landscape of a proposed solution. It gives us considerable information about how good a solution is, what steps need to be taken to improve it, and what forces are going to be pulling at the implemented solution over the long term. 

What do you think? Is this a good start to helping you understand the SIP Complexity Model? Keep in mind this is a draft and I will be adding to it as I respond to comments. Feel free to leave comments here, tweet me at @RSessions, or email me (userID: roger; domain:

Friday, October 28, 2011

New Word: Simplility

I am introducing a new word into the IT lexicon: simplility. Simplility is defined as the intentional architectural design of simplicity into a software application

Simplility follows a long tradition of "ilities" such as portability, reliability, and scalability. These all imply that somebody has made an intentional decision to include specific attributes in an application. Nobody expects an application to be portable, reliable, or secure by accident. We understand that it take skill and effort to give an application these attributes. And we understand that there are important reasons for doing so.

Why, you may ask, do we need a new word? Why not just use the word simplicity? The problem with simplicity is that we take it for granted. To say that an application is simple simply does not have the same cachet as saying the application is scalable. We understand that scalable has business value. 

So we need a word that elevates the attribute of simplicity to the same level of the other ilities that we understand provide business value. We need a word that announces that simplicity is a business asset and that it takes skill, effort, and commitment to incorporate this attribute into applications.

There is one problem with the world simplility. It implies that simplility is equal in importance to portability, reliability, or security. In fact, simplility is more important. It is the primary architectural attribute, the one from which all other attributes flow. 

Take security, for example. A system that has simplility baked in is one that will be much easier to make secure than one that lacks simplility. Complex systems are inherently insecure. 

The same with reliability. The greater the simplility, the greater the reliability. Complex systems are inherently unreliable.

So if we are serious about IT architecture, we need to get serious about simplility. It is the most important ility of all. And starting today, it has its own word.

Tuesday, October 25, 2011

Public or Private Cloud? Wrong Question!

Many people are asking if it is best to use a public or private cloud. They are asking the wrong question.

The bigger issue for most organizations is not whether to use a private or public cloud, but whether to use any cloud at all. The issue here is not whether the cloud is a good idea or a bad idea, but whether the organization has sufficient maturity to make effective use of any cloud. Most don't.

Most organizations use a pre-cloud architecture. The cloud places specific demands on a app with respect to efficiency, performance, reliability, and security. Very few organizations understand these demands and thus very few apps of any significant size are architected to meet those demands.

A good historical comparison is the switch from client/server programming to three-tier programming. A new generation of technologies enabled three-tier programming, namely transaction processing monitors (TPMs.) TPMs promised a radical improvement in the efficiency of computer resources, very similar to what the cloud promises today. Many organizations took their existing client/server applications and "ported" them to a TPM environment. They then discovered the hard way that a client/server architecture is totally unsuited for a TPM environment.

Organizations that take their existing three-tier, SOA, or even client/server apps and "port" them to the cloud are in for an equally rude awakening. They will find that these apps are expensive to run, highly fragile, insecure, and will have poor performance.

Asking if a public or private cloud is best for most apps is like asking if a public or private road is best for most boats.