Can SOA and architecture really be described with 'Lego blocks'?
Many SOA proponents and architects are routinely chastised for making things appear too complex for decision makers to grasp. It becomes a question of how simple should things be presented when selling SOA and enterprise architecture to the business? 
A couple of years back, we surfaced a debate on the whole "Lego block" analogy pertaining to SOA, noting that it may have been a bit too simplistic to describe everything that goes into service-orienting systems and processes.
Yet, it persists as an analogy. The temptation is that it just makes things so very easy to explain to the business: applications and services can simply be snapped into place on demand, everything is standardized across the board, everything is interoperable. You even have a choice of colors. And, at the end of the day, you can simply tear your whole structure down -- be it a castle -- and rebuild it as something else, maybe an airplane, without a blip in your IT infrastructure. In fact, that's the end goal -- what Miko Matsumura once described as a purely "weightless" SOA scenario.
Why do I bring the Lego block argument up again? Richard Veryard, an outspoken proponent of good enterprise architectural practices, says the Lego-block analogy doesn't work for explaining EA. He was responding to a suggestion that "If your enterprise architecture can not be illustrated in 3D using Lego then you have a problem."
Richard's response: "The reason Lego cannot reliably express architecture is because just looking at the model doesn't tell us which elements are architecturally significant." For instance, did the enterprise architect specify a certain color or size of bricks, or was this left open for interpretation?
Again, it's a question of complexity versus simplicity in selling SOA and enterprise architecture to the business. Do we need analogies such as Lego blocks? Are such analogies even accurate, or as Richard suggests, misleading and confusing?
(Photo credit: Wikimedia Commons.)