On Roger Sessions’ LinkedIn group, Simpler IT, the discussion “What do I mean by Simplifying” talks about finding simple solutions to problems. Roger’s premise is that every problem has its own inherent complexity:

Let’s say P is some problem that we need to solve. For example, P could be the earthquake in Tom’s example or P could be the need of a bank to process credit cards or P could be my car that needs its oil changed. P may range in complexity from low (my car needs its oil changed) to high (a devastating earthquake has occurred.)

For a given P, the complexity of P is a constant. There is no strategy that will change the complexity of P.

Roger goes on to say that for any given problem, there will be a set of solutions to that problem. He further states “…if P is non-trivial, then the cardinality of the solution set of P is very very large”. Each solution can be characterized by how well it solves the problem at hand and how complex the solution is. These attributes can be graphed, as in the image to the right, yielding quadrants that range from the most effective and least complex (best) to least effective and most complex (worst). Thus, simplifying means:

The best possible s in the solution set is the one that lives in the upper left corner of the graph, as high on the Y axis as possible and as low on the X axis as possible.

When I talk about simplifying, I am talking about finding that one specific s out of all the possible solutions in the solution set.

Simplification, as a strategy, makes a great deal of sense in my opinion. There is, however, another aspect to be considered. While the complexity of a given problem P is constant, P represents the problem space of a system at a given time, not the entire lifecycle. The lifecycle of a system will consist of a set of problem spaces over time, from first release to decommissioning. An architect must take this lifecycle into consideration or risk introducing an ill-considered constraint on the future direction of the product. This is complicated by the fact that there will be uncertainty in how the problem space evolves over time, with the uncertainty being the greatest at the point furthest from the present (as represented by the image below).

Some information regarding the transition from one problem space to the next will be available. Product roadmaps and deferred issues provide some insight into what will be needed next. That being said, emergent circumstances (everything from unforeseen changes in business direction to unexpected increases in traffic) will conspire to prevent the trajectory of the set of problem spaces from being completely predictable.

Excessive complexity will certainly constrain the options for evolving a system. However, flexibility can come with a certain amount of complexity as well. The simplest solution may also complicate the evolution of a system.

Excellent post, Gene.

Considering the relative merits of different solutions over multiple time horizons is key.

LikeLike

Thanks, Dan. I agree, growing the product over the long term is where the true value of architecture is realized.

LikeLike

Hi Gene,

Seems like Roger might be channeling the spirit of Frederick Brooks. (see: http://www.sci.brooklyn.cuny.edu/~sklar/teaching/s10/cis20.2/papers/brooks-no-silver-bullet.pdf).

Absolutely agree on the concepts of essential complexity (inherent in problem) and accidental complexity (introduced by the solution). I also agree with your characterization of lifetime complexity and the uncertainty that surrounds it. The only conceptual adjustment I might suggest is a “time value”factor. Complexity 10 years from now may be less harmful than complexity in 1 year, as (in theory) you have time to correct it.

Now us procrastinators know full well that there are few problems that can’t be put off until tomorrow. There are still PC’s running Windows 95 and mainframes running OS-370. Yet, the general rule is that people frequently implement a temporary solution and repair/replace it.

So, I guess my point is that if we consider the full lifecycle of problems, we should also expand our concept of solution to include the full lifecycle of interventions.

P.S. After reading this, I realize that I need a “personal architect” to carefully and objectively consider all of the inherent complexity in my life and magically come up with the upper left quadrant solution that will maximize benefit and minimize complexity over my expected tenure 🙂

Best Regards,

Charlie

LikeLike

Charlie,

Great comments, as always. The time value factor is an interesting twist. In a way, my thoughts on adding complexity up front for reasons of flexibility/expected needs touches on it, but in an indirect and accidental way. As you say, you have time to correct it or in my example, you may grow into it.

Absolutely agree that the full lifecycle (both problems and solutions) should be taken into consideration. So many costly interventions could have been prevented with a little prophylactic maintenance before the situation became critical.

Should you find the “personal architect”, be sure to give me their contact info!

LikeLike

The Murphy’s Laws of Ham Radio:

1) Temporary installations tend to become permanent.

2) Permanent installations never are.

LikeLike