Here is another perspective on the Lego model:
<<Joel Spolsky is one of our most celebrated pundits on the practice
of software development, and he's full of terrific insight. In a
recent blog post, he decries the fallacy of "Lego programming" -- the
all-too-common assumption that sophisticated new tools will make
writing applications as easy as snapping together children's toys. It
simply isn't so, he says -- despite the fact that people have been
claiming it for decades -- because the most important work in software
development happens before a single line of code is written.
By way of support, Spolsky reminds us of a quote from the most
celebrated pundit of an earlier generation of developers. In his 1987
essay "No Silver Bullet," Frederick P. Brooks wrote, "The essence of a
software entity is a construct of interlocking concepts ... I believe
the hard part of building software to be the specification, design,
and testing of this conceptual construct, not the labor of
representing it and testing the fidelity of the representation ... If
this is true, building software will always be hard. There is
inherently no silver bullet."
As Spolsky points out, in the 20 years since Brooks wrote "No Silver
Bullet," countless products have reached the market heralded as the
silver bullet for effortless software development. Similarly, in the
30 years since Brooks published "The Mythical Man-Month" -- in which,
among other things, he debunks the fallacy that if one programmer can
do a job in ten months, ten programmers can do the same job in one
month -- product managers have continued to buy into various
methodologies and tricks that claim to make running software projects
as easy as stacking Lego bricks.
Don't you believe it. If, as Brooks wrote, the hard part of software
development is the initial design, then no amount of radical workflows
or agile development methods will get a struggling project out the
door, any more than the latest GUI rapid-development toolkit will.
And neither will open source. Too often, commercial software companies
decide to turn over their orphaned software to "the community" -- if
such a thing exists -- in the naïve belief that open source will be a
miracle cure to get a flagging project back on track. This is just
another fallacy, as history demonstrates.
In 1998, Netscape released the source code to its Mozilla browser to
the public to much fanfare, but only lukewarm response from
developers. As it turned out, the Mozilla source was much too complex
and of too poor quality for developers outside Netscape to understand
it. As Jamie Zawinski recounts, the resulting decision to rewrite the
browser's rendering engine from scratch derailed the project anywhere
from six to ten months.
This is a classic example of the fallacy of the mythical man-month.
The problem with the Mozilla code was poor design, not lack of an able
workforce. Throwing more bodies at the project didn't necessarily
help; it may have even hindered it. And while implementing a community
development process may have allowed Netscape to sidestep its own
internal management problems, it was certainly no silver bullet for
success.
The key to developing good software the first time around is doing the
hard work at the beginning: good design, and rigorous testing of that
design. Fail that, and you've got no choice but to take the hard road.
As Brooks observed all those years ago, successful software will never
be easy. No amount of open source process will change that, and to
think otherwise is just more Lego-programming nonsense.>>
You csn read this timorous viewpoint at:
http://www.infoworld.com/article/06/12/11/50OPopenent_1.html?source=NLC-OPENT2006-12-12
Gervas
--- In
[email protected]<service-orientated-architecture%40yahoogroups.com>,
"Gervas
Douglas" <[EMAIL PROTECTED]> wrote:
>
> ZapThink
>
<http://www.zapthink.com/styles/Internet_Market/images/zapthinkheader.jpg>
>
>
>
>
>
>
> The LegoR Model of SOA
>
>
> Document ID: ZAPFLASH-20061212 | Document Type: ZapFlash
> By Jason <mailto:[EMAIL PROTECTED]> Bloomberg
> Posted: Dec. 11, 2006
>
> Any attempt to explain Service-Oriented Architecture (SOA) to a business
> audience typically elicits one of two standard responses: "this is
techie
> stuff; you should talk to my IT people" or even worse, "I don't see the
> business value." The irony, of course, is that Service Orientation is a
> business approach for leveraging IT capabilities as business
resources to
> meet the changing needs of the business in agile, cost-effective
ways, and
> is thus critically relevant to today's business. But taking all the
> admittedly technical benefits of SOA, including loose coupling,
> composability, and reusability, and placing them in a sufficiently
> explanatory business context has always been a difficult challenge.
>
> To rise to this challenge, ZapThink likes to use the analogy of Lego
blocks.
> We feel the Lego block metaphor for business Services is so powerful, in
> fact, that we put a picture of some on our
>
> home page. Whenever we introduce the concept of SOA, out comes the
picture
> of the Lego blocks. We even recommend the Lego analogy to vendors
who are
> looking for a way to explain SOA to businesspeople. As with any
analogy, the
> parallels only go so far, but with Lego blocks, we've found four
positive
> salient characteristics -- and four negative ones -- that serve to
> illustrate both the power as well as the drawbacks of SOA to any
audience.
>
> The Four Advantages of Lego Blocks
> The four characteristics of Lego blocks that are most appropriate for
> illustrating the strengths of business Services in the context of
SOA are
> the following:
>
> * Lego blocks are interoperable. Yes, it's all about the
> bumps. Because the blocks all have standard bumps, any Lego block
will fit
> into any other Lego block. Standards-based interfaces are the secret
to the
> blocks' interoperability -- or to be more precise, it's the Service
contract
> that matters. After all, we've had decades of standards-based
interfaces of
> various sorts and that hasn't gotten us that close to the Lego vision.
>
> * Lego blocks are unbreakable. When was the last
time you
> saw half a Lego block? Even the most rambunctious three-year-old can't
> damage the things. Clearly, the business would appreciate it if IT could
> deliver capabilities that were as unbreakable as Lego blocks. Now,
it's not
> that Lego blocks are truly unbreakable, but rather, that the Lego Group
> designed them with significant robustness in mind. And that's what
we want
> from SOA -- a design for robustness. The key is that it's the
architecture
> of the Lego block that makes it strong enough for a three-year-old,
just as
> IT needs to function in a way that's robust enough for business.
>
> * Lego blocks are composable. One Lego block by
itself is no
> fun at all. The whole point to the toy is taking many of them and
assembling
> them to meet the need of the day, just as the business wishes to compose
> Services into applications that implement business processes in a
flexible
> way.
>
> * Lego blocks are reusable. On the one hand, you can
build
> one structure with your blocks, then disassemble it and reuse the
blocks to
> build something else. Another way of looking at reusability is to
consider
> the colors of the blocks. If you consider, say, all red blocks to
represent
> customer information Services, for example, then you can easily use red
> blocks in many different structures, just as you can compose customer
> information Services into many business processes.
>
> There's little the business wants from IT that doesn't fall under
the four
> characteristics above. The business cares little for how the blocks are
> constructed or why they do what they do. The business simply wants
> composable, reusable, interoperable, unbreakable components they can
> leverage in flexible ways to meet the changing needs of the business.
>
> The Downside of Lego Blocks
> As with any good analogy, the parallels extend beyond the positives, and
> also help highlight some of the limitations of SOA. Here are four
examples:
>
> * Lego blocks' strengths pose business challenges
for their
> manufacturer. It's no secret that the Lego Group who manufactures
the blocks
> has had its ups and downs. Changing preferences for toys have
impacted their
> business, to be sure, but the blocks' unbreakability, reusability, and
> composability have actually caused their own share of problems, as well.
> Once a family buys enough Lego blocks for their first kid, after all,
> they're usually set for life, regardless of how many children they
> subsequently add to their brood. As a result, sales of Lego blocks have
> waned over time, leading the company to roll out special kits with the
> intention of having children assemble a castle or a spaceship or
what have
> you once, and set it on a shelf. In other words, the vendor talks about
> interoperability and reusability, but really wants to lock you in so
that
> you have to keep buying products from them. Sound familiar?
>
> * Structures built from Lego blocks are only so
strong. If
> you compare Lego blocks to, say, Erector Sets, the Erector Set was
harder to
> work with and less flexible in its capabilities, but once you had that
> bridge or skyscraper constructed, it wasn't going anywhere, and you
could
> virtually climb on the thing. The larger you build a structure with Lego
> blocks, however, the more fragile it gets. In other words, loose
coupling
> comes at a price. While tightly coupled interfaces reduce
flexibility and
> reusability, they also can increase efficiency. Loose coupling, on
the other
> hand, can limit the efficiency of the implementation.
>
> * Lego blocks are interoperable with each other, but not
> with other kinds of toys. This characteristic of Lego blocks might
provide a
> warning about the pros and cons of building on a single platform,
but the
> more interesting story here is that loose coupling occurs on multiple
> levels. You can have loosely coupled interactions on the wire and
message
> protocol levels, and still be tightly coupled on the semantic level.
True
> loose coupling is far more complex and subtle than bumps on Lego
blocks!
>
> * Lego blocks are for children, but children
couldn't build
> Legoland. All parents think the structures their little ones build with
> their Lego blocks are the best in the world, of course, but to build the
> large structures you find in the Legoland theme park, you need
architecture.
> Without architecture, a box of Lego blocks is nothing more than a box of
> toys, and without architecture, a bunch of Services is little more than,
> well, a bunch of Services. Only with a broad design and the
discipline to
> follow it can companies expect to get the full value out of their
Services
> over time.
>
> Lego Blocks and Service Granularity
> OK, all you Lego fans, what is the best size Lego block? Clearly, if
all you
> had were a box of the tiniest, one-bump blocks, you wouldn't be able to
> build very much. Similarly, if you wanted to build, say, a model of
the Taj
> Mahal, you could (in theory) commission the Lego Group to custom-make a
> single Lego block in precisely the shape of the Taj Mahal. As long
as your
> requirements didn't change, that bespoke block would suffice, but
any change
> in your needs, no matter how slight, would necessitate scrapping the
entire
> thing and starting from scratch.
>
> The moral here is that fine-grained Services by themselves aren't
> particularly valuable to the business, but Services can also be so
> coarse-grained that they're too inflexible to meet the needs of the
business
> either. The optimal granularity for Services generally falls
somewhere in
> the middle. Furthermore, ask any child what size Lego block is the
best, and
> they'll look at you funny and reply that they really want a box with
blocks
> of a bunch of different sizes. Just so with business Services --
while the
> most flexible, reusable level of granularity is somewhere between
fine and
> coarse-grained, in practice it makes sense for organizations to
build a mix
> of Services at different levels of granularity.
>
> The ZapThink Take
> Technologists eschew oversimplifications as being unrepresentative
of the
> true value of complex technologies, but business people appreciate
> straightforward analogies that both clarify complex topics while
> illustrating their salient characteristics. ZapThink has found that
the Lego
> block metaphor actually goes over quite well with diverse audiences,
and we
> even know a management consultant who brings actual samples to
meetings with
> C-level executives.
>
> If you find yourself in such a situation, try this: place some red
blocks on
> the table, and explain that these are customer Services. Next, place
some
> blue blocks down, and identify them as operations Services. Likewise
with
> the yellow ones, which are manufacturing and delivery Services.
Next, single
> out a business process important to your audience, say, procure-to-pay.
> Assemble a mix of colors to represent that process. Now, what happens if
> there's a new regulation or competitor or logistical problem that
requires a
> change to the process? Quickly add a block to your structure. What
if you
> want to use the customer Services from that process in another process?
> Reassemble the red blocks from your structure with other blocks on the
> table. You'll be surprised how quickly even the most jaded of executives
> gets the power of Service Orientation -- and you don't even need to
mention
> Services, architecture, or SOA.
>
> LEGOR is a trademark of the <http://www.lego.com> LEGO Group of
companies
> which does not sponsor, authorize or endorse this content.
>
