Web 2.0 Reaches Fever Pitch

This week I have had two acquaintances in South Australia evangelize about Web 2.0. The first was Mike Seyfang. He is interviewed in an article in "The Adelaide Review". from the world of Microsoft. The last time I was contact with Mike he was working for Microsoft in an Innovation Centre they had set up in partnership with the SA Government. The article focused on micro-blogging in twitter and facebook and did not really get to the heart of Web 2.0 which I feel is the collaboration and the easy combination of tools.

The second Web 2.0 evangelist was Kym Farnik from IBM. This is a man with huge credentials in serious IT and he was describing what big blue was doing in this space. Kym was presenting the Australian Computer Society, IT Architect SIG. He was focusing more on the tools to create product that can be used in mash-ups.

The message from both of these respected IT people was that Web 2.0 is ready to come in from the realm of the teenage hobbyists and the anarchic masses to provide some real business benefits. It is a hard message to sell. Instant messaging has been around for quite some time and does not seem to have penetrated the organizations I work for. A Wiki has found a place amongst a group of my IT people but it struggles to be recognized as an information store of any importance.

There is no doubting the utility of the Web 2.0. What is it about business that squeezes the life out of this technology? It could be the control that big business demands over its information assets. It could be the lack of freedom in relation to IT. It could be that web 2.0 succeeds in a world where people want to collaborate for the sake of collaborating. Collaboration in the business world has to be much more directed to some other outcome.

I think we'll see more applications of Web 2.0 in the business arena, especially as the power of Microsoft and IBM are behind its evangelizing. I look forward to this. Watch the mobile phone application space. This could be really big, however I do not think Web 2.0 itself will be seismic shift in the way most organizations do business. Expect a few neat add-ons to web applications to be developed with Web 2.0. I would also expect some workgroup collaborative tools that will have a fairly narrow focus rather than replacing the way we all work.

Reference
Beyond Blogging in "The Adelaide Review" , No 319, June 22-July5 2007, p8, http://www.adelaidereview.com.au/

Farnik, Kym, Making on-line communities and community collaboration real(Leveraging Web 2.0), http://sa.acs.org.au/it_arch/images/a/a7/ACS_Web_2.0.pdf

Lego and SOA

Lego has been used many times as a metaphor for SOA. I first came across it during a vendor presentation and was not particularly impressed by it as I immediately saw some shortcomings in the metaphor.

After thinking about how I would explain some of the benefits of SOA like agility and loose coupling I decided Lego might be fairly descriptive after all. I ended up doing my own presentation on SOA at a planning session complete with blocks from my kids' Lego set. I felt this was one of my more entertaining presentations and it helped get across some good messages. I plan to post a transcription of the presentation on this blog. As it was a "show and tell" presentation I need to get my digital camera fixed first.

When I did this talk I did not realise the Lego metaphor for SOA was so common. Google brings up many hits that relate the two. It is sometimes handy in IT to show something tangible to explain our concepts. What we build is never clearly visible and how we build it is often very abstract.

Gian Trotta does a good job of looking at this metaphor.

These components are loosely coupled code components that represent well-defined and self-contained business services. “This is important. Loose coupling is a design criterion that enables agility. It can't depend on the context or state of other services,” she noted.

The business services become part the overall service oriented architecture (SOA). “Service-oriented architectures require well-defined interfaces and this is the evolving role of Web services. Finally, we have a standard interface that everyone's agreed on, enabling service-oriented architectures to take off,” Gold-Bernstein added.

I do not think much of the Swiss army knife metaphor though. For me SOA is not a grab bag of utilities that can be applied to any problem.

Jason Bloomberg was the source of the above illustration (which is not actually Lego, see footnote) but covers the whole Lego issue pretty well.

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

Some of Jason's points identify problems with Lego rather than problems with Lego as a metaphor for SOA. He raises the issue that Lego blocks are so unbreakable that they get passed down the generations so new generations do not buy enough new blocks. This is why the new Lego has so many different parts and looks more realistic. The Lego company is trying to get kids to build it and put it on display rather than reuse it. I see this as a strength of the Lego metaphor (or 'analogy' as Jason refers to it). This is excellent reuse but it also shows the importance of overall architecture. The architecture has adapted to meet the purposes of the business.

The physical nature of Lego means that structures are easier to break as they get bigger, composed of more building blocks. It is interesting to speculate on whether this is true for SOA. Will a big SOA implementation become more fragile? My feeling is that with good design and testing it could be fairly robust but in practice any system with more components and connections will have more points of failure.

Jason states "Lego blocks are interoperable with each other, but not with other kinds of toys." He has a very good point here. Adapters can be built for Lego. I used some sticky tape and a bit of wire attached to Lego blocks when I was demonstrating legacy adapters for an SOA. It is not common practice though to interface Lego with other toys.

Jason's last negative characteristic is "Lego blocks are for children, but children couldn't build Legoland". All metaphors have to break down at some time. SOA is not for children. Services are not made of plastic or cannot fit in an ice cream container either. The metaphorical point is that services can be composed together in an ad hoc fashion without much forethought, but to build large systems with many services that meet the needs of the business requires good SOA and discipline.

One failure of the metaphor I do think has merit is from Jack van Hoof who observes

First start building a nice fortress with LEGO blocks. Then after you finished it, just change one little LEGO block somewhere in the middle of the wall. You won't be very happy, I suppose. Not to mention creating a new window or a door. ... LEGO constructs are easy to be build, but a nightmare to be changed ...

The concern I originally had with the Lego metaphor is aptly covered by a quote from an article by Joe McKendrick who in turn is quoting a vendor white paper

But unlike a single LEGO block, which can only be used in one design at a time, a 'service' can be used by several applications at once (much like a letter in a crossword puzzle).

It is an advantage of software that it can used to process many business processes and it does not get consumed in the process. I sometimes like to consider the service is the block design rather than the actual block but I would not want to try to explain this to an audience as the metaphor starts to lose its simplicity.

The Lego metaphor has been used before in IT and will probably be used for other engineering disciplines. It is a popular model for describing why one might want to build things in parts, why we use standards and how we make big, complex systems out of simple building blocks. For me, Lego continues to be descriptive for SOA. Any discussion about its strengths or weaknesses as a metaphor just seem to help explain more concepts about SOA.


Footnote:
The image above has been presented in a number of articles by Jason Bloomberg of Zapthink. Please note that the blocks illustrated here are not standard Lego blocks. This is a photo of some other interconnecting toy. Standard Lego blocks have the Lego trademark on each of the bumps. Standard Lego blocks also have a gap between the bumps which is larger than the radius of the bumps.

References

• Totta, Gian, The Lego/Swiss Army Knife Approach to SOAs http://www.ebizq.net/topics/soa/features/4040.html
• Bloomberg, Jason, The Lego® Model of SOA, http://www.zapthink.com/report.html?id=zapflash-20061212
• Van Hoof, Jack, SOA and LEGO, do you dare to compare?, http://soa-eda.blogspot.com/2006/12/soa-and-lego-do-you-dare-to-compare.html
• Taylor, James, If SOA is Lego then decision services are Mindstorms http://www.ebizq.net/blogs/decision_management/2006/12/if_soa_is_lego_then_decision_s.php
• McKendrick, Joe, Why are we building ‘enterprise’ SOAs with ‘LEGO blocks’?http://blogs.zdnet.com/service-oriented/?p=777

LEGO® is a trademark of the LEGO Group of companies which does not sponsor, authorize or endorse this content.

Hype Cycle for Application Development

I recently read an article from Gartner Research (Hype Cycle for Application Development, ID Number G00147982). Generally I find the material from Gartner great. It's reasonably independent and provides the right level of detail for me mostly. It costs alot to access so you have to find an employer or university to part with the cash to subscribe. I recently heard from a vendor of mapping software that said Gartner wanted $40k to do a review of their software and include them in an appropriate "Magic Quadrant". So their independence is not absolute.

The "Hype Cycle" article was a good summary of what is happening in software development today and the relative maturity of a number of technologies, concepts and product sets. It was handy to brush up on some acronyms. ARAD SODA apparently means Architected Rapid Application Development Services-Oriented Development of Application. You can also have Architected, Model-Driven SODA. Now that seems to be putting all the current buzzwords together in a couple of long acronyms. When did 'architect' become a verb? Any way now I know that what I am trying to do at work is a SODA and, even though I quibble about the grammar, I want it to be architected.

The article itself was written by a number of contributors and provide a mix of succinct insightful writing and some marketing waffle. One of the less well defined concepts was Enterprise Information Management (EIM) which is its 'technical trigger' phase rising to a 'peak of inflated expectations'. I find EIM a little similar to Knowledge Management (KM) which in turn can be almost anything related to the enterprise. KM can be include building design, HR practices and telephone lists. It was one of those definitions that a like to ask "What is it not?" and more to the point "How is it useful?". EIM, like KM will be more an approach to looking at the whole organisation. This may bring up some useful concepts. KM seemed to spawn the concepts of tacit knowledge and explicit knowledge. Before that people talked about the "stuff in our heads" and the "stuff written down" or for the geeks "biological data stores" and "digital data stores". Tacit knowledge was a vaguely useful concept. I don't think I'll championing my organisation to do EIM.

One of the more insightful parts of this article was the analysis of SOA by Roy Shulte and Yefim Natis. I am glad to see SOA is climbing the 'Slope of Enlightenment'. Something I have been struggling with is how many services my organisation has developed. I had assumed the number was zero until one of my senior developers showed me a list of all the EJBs he had built to access mainframe data and said "look at all these services". This did no fill me confidence. In a service I expect to see late binding, loose coupling, an XML interface, some aspect of self description and the ability to integrate using business process technology. Most of the SOA definitions I have seen are pretty vague and some a clearly business focused. These did no give me the ammunition to say that this was not the type of service I had in mind. The definition added to what I had seen previously.

"An application is an SOA application if it s modular; the modules are distributable; software developers have written or generated interface metadata that specifies and explicitly contract so that another developer can find and use the service; the interface is separate from the implementation (code and data) of the service provider; and the services are shareable..."

This should give me something to work on when I say I want this sort of service. Of course I could just say I want a web services with a SOAP interface. That might be easier. I get told SOA is not just web services though.

Hype cycles have their detractors but in general these hype cycles help see the big picture. IT shops are bombarded with a huge number of technologies. We are made to feel inferior by the marketers and our more progressive staff that we are behind because we are not employing the latest tools and techniques. The bottom line though is that many of these tools and techniques are not mature. They do not actually benefit all organisations and it takes time for conservative organisations to reap any benefit from investment some products that are billed as the next big thing.