다음을 통해 공유

Rubik’s Enterprise Architecture

  • 아티클

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.

Comments

  • Anonymous
    April 30, 2009
    In some ways, I agree with your assertion Nick. Regarding the "optimum" technical architecture there are roadmaps and solutions that can be delivered. The problem that most EA's typically fail to factor is the human element. In your analogy, even with the cube itself, the thing that's doing the moving are people. If we extend the rubik's cube example, the problem isn't how many moves it takes to solve, but in what amount of time. I can give 10 people 10 cubes and the same 51 steps to take. Guess what? I will not get 10 perfected cubes at the same point of completion. Why? Because how the people process the information and move the technology (in this case the cube itself) is different. Business and enterprise architecture is performed by people. Elegant solutions carried out in a specified manner -- by training and repetition -- yield efficient, repeatable results. Without traing and repetition of your people process, you get variability that affects the entire solution. Just a thought.

  • Anonymous
    May 04, 2009
    Nick: I am not sure I buy your analogy entirely. The Rubik's cube has no inertia as an element of the Cube moves. What I mean by that is that all parts of an element of the cube can move at the same speed and together. The major problem EAs have to deal with is that each time an Enterprise utilize a product or a technology, it writes and deploye business logic / configuration / metadata in a way that seriously hamper future evolutions as it is captured in an obscure proprietary format that cannot be consummed in the new (position) technology. I don't think EA will have any measurable impact in an organization until there is an environment where architecture refactoring becomes a reality. Today, architecture refactoring means rip and rebuild. There is no real ROI for, and that people only do it for technologies that go unsupported or for compliance reasons (not the kinds of drivers you want for an EA organization). Today, there are a couple options that could be considered:

  • PaaS which offer decent "upgradability" paths but create a large amount of lockin
  • MOP (Metamodel Oriented Programming) which offer a foundation for Architecture Refactoring but require that you write adaptors and translators to deploy artifacts in particular architecture stacks. There is no free lunch. JJ-