In many ways, the task of creating a complete roadmap for the evolution of an enterprise architecture is similar to the task of creating an optimum path to solving rubik’s cube. With rubik’s cube, the number of total possible combinations of faces is very large. (There are 43,252,003,274,489,856,000 different cube positions).

Yet, a number of years ago, Herbert Kociemba published an algorithm that would not only solve Rubik’s cube, it would do it very quickly. (You can download an easy-to-use application that provides you with a solution from his web site.) His most recent version of his app would solve 7,000 cubes per hour!

So, if it is possible to create a pathway from nearly any combination of Rubik’s cube to a “clean” solution, in 21 moves or less, and to calculate the “roadmap” in less than a second, why is it so difficult to describe the optimum pathway from a “present state” enterprise architecture to a “future state” enterprise architecture?

The advantage that Kociemba had was that the “clean” or “solved” state was fairly easy to describe. All sides have the same color. The “clean” state of an enterprise architecture depends on a lot of things, and there may not be one answer. There can be many “right” answers, each describing a unique configuration of systems, data flows, events, interfaces, technologies, and business process activities.

Another advantage that he had: the solution path did not have to be suitable at any particular step of the way. In other words, you could create any configuration of the cube, at any step, as long as the final configuration was that of a solved cube. Not so with an Enterprise Architecture. At each step of the way, we have to have an environment that is functional and, in most cases, just as capable as it was before the last set of moves was made.

Even with all these constraints, the mathematical feat of solving Rubik’s cube in an optimum number of steps has been accomplished. I don’t believe that it would be more difficult to solve for the “optimum” enterprise architecture. A different problem, true, but one of similar complexity.

Now, there have been “tried and true” methods for solving the cube for years. I learned one when I was a teenager. Regardless of how the cube started, you could follow the set of patterns and, in about 150 moves, you could solve any cube. Kociemba provided us with an optimal path that was NOT a “mathematical reduction” of the tried and true methods.

And perhaps that is the more interesting result of making this comparison. We should not expect that the optimum architectural roadmap is a simple reduction of the “tried and true” architectural roadmap. In other words, for any environment, if you describe all the moving parts, the steps needed to get you to a simpler, less expensive environment may not be obvious. More importantly, you cannot describe a “long path” and then simply “shorten” it by substituting simple sequences of moves with shorter sequences. There may not be a short cut to the optimum solution.

So the next time I hear an architect or a product salesman tell me that they have the “perfect” solution to my problem, I’m going to think about Rubik’s cube, and Kociemba. The “optimum” solution may not be the obvious one.