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], "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. >
