chris horn's blog

What kicked of this blog entry for me were some reflections I had as I chaired a one day conference, with a preceding half day workshop, a couple of weeks ago, which was organized in Galway by Fidelity Investments, on the subject of Web 2.0, and how commercial organizations – such as Fidelity – can benefit from and add value to the global internet community.

A core theme of Web 2.0 is the collective wisdom that results from the network effects of sharing across the community. The wisdom of the crowd is sometimes more than the sum of the individuals therein. Wikipedia is one prime example, since collective knowledge can trigger insights for individuals, which can then augment the collective wisdom: the added knowledge which would not arise if the group did not collaborate together. I recently wrote a blog entry about a similar phenomenon in multi-disciplinary research. Group and individual reasoning can positively feed off each other.

One of the dichotomies of the Web 2.0 phenomenon is on one hand, the power of the group and the collective knowledge of the crowd; and yet on the other the significance of each individual. Yes, collective knowledge such as Wikipedia and del.icio.us (and of course Google!) have emerged, but blogs written and commented by individuals are still a fundamental force. Some may argue that indeed the information in specific blogs written by certain individuals is more valuable, accurate and reliable than that in shared wiki repositories maintained by the amorphous net community. There is room for both individuals and the crowd.

In the race to be successful on the web, the focus is on attracting and retaining users, eyeballs and clicks. For the promoters of a web site - whether a commercial venture, or just a worthy cause for society at large - building and growing a “market” is key. Monitoring usage patterns, listening and reacting to user feedback, all builds momentum: hopefully a tipping point is passed, and the network effect of market momentum reinforces the popularity and acceptance. However: does a mass market strategy play only to the crowd, and not to the individuals therein ?

For Web 2.0 , Chris Anderson introduced the term “long tail” to emphasise deploying:

“customer-self service and algorithmic data management to reach out to the entire web, to the edges and not just the center, to the long tail and not just the head”.

As noted by an Amazon employee quoted by Wikipedia: “We sold more books today that didn't sell at all yesterday, than we sold today of all the books that did sell yesterday” -- read that slowly to yourself again if you hadn’t come across it before..

Further, in his discussion on technology market dynamics, Christensen noted:

“Simply put, when the best firms succeeded, they did so because they listened responsively to their customers and invested aggressively in the technology, products, and manufacturing capabilities that satisfied their customers' next-generation needs. But, paradoxically, when the best firms subsequently failed, it was for the same reasons--they listened responsively to their customers and invested aggressively in the technology, products, and manufacturing capabilities that satisfied their customers' next-generation needs ….But the problem established firms seem unable to confront successfully is that of downward vision and mobility, in terms of the trajectory map….”

Success – at least in some industries, such as the disk drive and earth moving machinery industries which Christensen documents – can equally lay the foundation for failure. Group and individual behaviour can play off each other, creating emerging forces from below.

Combining the Anderson’s exhortation to reach out to the edge, with the warning by Christensen not to be outflanked by emerging disruptive technologies from below, it would seem wise to ensure that a Web 2.0 market strategy explicitly recognises the potential of the individual, as well as the mass market of the group. Even more important is to react to dynamics in the market and to changing tastes. The observation is: that in a global market of mass consumerism, the ability to cater for the vast number of changing individual personal tastes and desires – to personalise and dynamically tailor your products and services – may be much more commercially – and socially – valuable, than volume plays of standard products and services to an anonymous amorphous group.

The long tail changes: it wags. The universe of micro-markets in the long tail is worth addressing – this is Anderson’s observation. In addition, changes in a micro-market may in due course influence the mass market (and blind side you) – this is in essence Christensen’s observation.

Ajit Jaokar was one of the contributors at the Fidelity event in Galway, and he reminded the audience of Tim O’Reilly’s characterization of the Web 2.0 phenomenon:

• the web as a platform;
• harnessing collective intelligence;
• data as the next Intel inside;
• the end of the software release cycle;
• software above the level of a single device; and
• rich user experiences.

I thought about each of these six facets as I reflected on the dynamics of the micro-markets, and list some (not all!) of my observations below: how does Web 2.0 address the wagging long tail ?

One common way of reaching out to the long tail, and monitoring its movements, is “data as the next Intel inside”. Google exploits what its itself calls the ”uniquely democratic nature of the web” to derive data on the click activity of millions of users to drive its PageRank algorithm. I suspect that social networking sites, such as MySpace, Facebook, Bebo and LinkedIn, could likewise exploit their data about networks of people. I’ve always wondered in passing how data regulators, such as the Irish Data Protection Commissioner, view such click gathering and social networking activities…

As Web 2.0 embraces beyond “the level of a single device” – which was Ajit’s theme of his presentation - I observe that telecommunications operators, such as Vodafone, O2 and T-Mobile, collect and record quantities of data, ironically in a large part due to regulatory requirements of data retention legislation in jurisdictions such as Ireland. These vast data archives capture about social communication patterns of populations – it is not just the social networking sites which have such data! There are opportunities, and privacy risks, to exploit these vast patterns to provide commercial value. One can imagine intelligence being generated by mobile phone operators to enable targeted marketing by third parties and content providers…

Quietly collecting mouse click activity, or analyzing phone call patterns and triangularising the locations of their owners, are data driven ways of using to drive for the long tail. Importantly, the data is dynamic and therefore so also is the derived collective intelligence: as trends emerge, or change, so can the offerings tailored for particular sets of individuals. But it seems to me that these approaches may wear a clandestine cloak: there are more explicit ways of using collective intelligence for the wagging long tail.

A successful web site needs stickiness to retain, and track, its audience, including the wagging long tail. A social networking site such as those above in part generates its stickiness because of the network effect of having ones friends, co-workers and colleagues using the same site: most people think it is too cumbersome to re-register oneself and encourage one’s cohort elsewhere. IMHO, the resulting stickiness is in fact rather superficial, rather than systemic: it consequently threatens any purported fiscal value for the site. The SIOC project at DERI in Galway underlines the benefits, and business consequences, of seamless federation of online communities. Stickiness should not be driven by re-registration inertia, but rather by community value and impact - which is one reason why I believe Ammado will succeed.

Another strategy to capture the long tail wags is “harnessing collective intelligence” – another of O’Reilly’s Web 2.0 facets. One explicit way is to allow individuals to define their own collections of interesting items, and then to share and discuss them with other like-minded souls. A simple way to do this is just by tagging items: for example, photos tagged with “Galway” on Flickr will appeal to certain people. But tagging rather quickly loses its impact when trying to find items with a combination of tags, requiring tedious trials of various search criteria; and tag synonyms are a problem in a global world: try “football” in del.icio.us as an example – or even “Galway Hooker” in Flickr!

Rather than expecting people to work out the correct search and query expression across a set of tag values for what they actually want, another way is to let people explicitly define and share their own collections. Hobbyists – such as stamp collectors – have been doing this for years, and a craft worker likewise learns what the set of right tools are for the job from the experiences of his trade. Enabling individuals – and micro-markets and even the crowd - to share what works well together when, is a positive tactic for managing the wagging long tail, and which I wrote about recently in the context of software configurations and Cloudsmith.

When doing a little research for this blog entry, I came across Dan Bricklin’s interesting blog entry on When the Long Tail Wags The Dog. His theme is that “must have” items have more value than those which are less likely to fit the job at hand; and that general purpose items are likely to have most value since they can entertain the dog as well as its long tail. While I don’t disagree, my thoughts about the dynamics of the long tail, and how to work with within it, are a slightly different emphasis.

Reinforcing Bricklin, being relevant to the individuals and small groups in the long tail requires customization and tailoring of general purpose offerings. In the enterprise software space, software vendors have traditionally worked with systems integrators to tailor more appropriate solutions to different niches of the market. With componentization in the software industry, in principle useful aggregations of different constituent parts can more likely be used to tailor specific solutions. Collective intelligence can be harnessed by explicitly sharing these aggregations, as I indicated above.

However, once delivered, installed and put into use, assemblies of software components in production environments have in the past usually been relatively static. The challenge is that the long tail wags: micro-markets and even mass markets change, and production systems need to more easily do so too. One promise of the dynamic module environment of OSGi is to enable dynamic evolution: if collective intelligence can be dynamic as trends emerge, or change, and then suggest new offerings tailored for particular sets of individuals, then perhaps also can production software assemblies in business and enterprise environments be dynamically adjusted. This is a theme which we are working upon in IONA, particularly in the context of our highly dynamic plug-in architecture for Artix and our open source FUSE offerings – see Eric Newcomer’s blog.

But if the world is dynamic, and contains a universe of micro-markets as well as a mass, can offerings not only be tailored so as to be a good fit, but also be priced attractively for each ? What when micro-markets change ? As I wrote about, one industry which faces these challenges is the mobile/cell phone operators, for whom intelligent and responsive bundling of services (SMS and MMS and call rates and roaming charges etc) is competitively critical. The ability to generalise this approach into the world of software components and packages is of interest and relevance to the wagging long tail. LeCayla is one company building a common approach to the issue of dynamically rolling out new charge and billing rates so that software vendors can competitively foster specific micro-markets.

Let me summarise: the internet as a platform enables a global market to be addressed. Web 2.0 uses collective intelligence to play in both the mass markets, and the long tail of numerous micro-markets. There is room for both individuals and the crowd, and group and individual reasoning can positively feed off each other. – creating the ever lurking possibility of being disrupted from below. Scalably addressing both the mass market and the long tail is however not the complete issue: markets change, the long tail wags, and scalably addressing dynamic markets is even harder – but possible.

Footnote: my 7 month old Alsatian, Charlie, has yet to grow into his long long tail. He wags it a lot.

Like some other teenagers of my generation in the seventies, one of my hobbies at the time was faithfully constructing scale models from plastic kits from Airfix, Revell, Historex etc. As I developed my skills and interest, I took great pride in adding extra levels of detail – particularly for ship kits. Eventually I converted particular kits so as to model an aircraft, ship or vehicle not directly available as a standard kit, by moulding balsa, crafting acetate sheet and so on – for example building a twin engine, triple tail fin Avro Manchester from the Airfix kit of the successor four engine Lancaster. The monthly Airfix Magazine was a great source of designs and examples, and I still have a shelf full of back copies here in my office at home.

When I was an engineering student, I took a similar interest in building my own, albeit fairly simple, analogue electronic circuits – the usual things such as oscillators, radios, fire/smoke detectors, etc. Of course, as with converting plastic kits, having a good stock of spare parts - scavenged from broken electronic circuits – was useful. I used to keep them sorted into empty margarine tubs on my shelves.

In more recent years, I became more and more involved in computers, from the digital gates and circuits up to microcode, assembler, compiler/interpreter systems and finally full systems and applications. I was fascinated when they became affordable as home systems, and played around adding extension cards and interfaces to my first PC. I was initially really impressed by Dell when I saw their range of alternative pre-configured systems for direct order across the internet. Dell used to have a plant in Bray just a few miles away from my home, and I have bought many systems over the years from them for home, school and charitable use.

But I’ve often thought there must be quite a few people out there like me who aren’t quite happy with a specific system they buy from Dell (or indeed any other supplier). Although I carefully chose a configuration before buying, still afterwards I frequently tailor my purchase further with additional cards, expansions and options. I also wonder whether somebody out there has already built the perfect system for creative digital photography, or multi-screen home media management, or whatever. Or whether anyone would be interested if I could publish my own designs and configurations. Or whether any configurations would be commercially interesting, for example for specialist systems such as creative digital media design.

Reflecting on my fads above, the common aspects are a desire to build interesting variations of basic designs; from additional parts either built myself, or stock-piled somewhere (not necessarily in margarine tubs!), or purchased elsewhere; to look at designs published by others, and perhaps even to publish my own.

Well, that’s what Cloudsmith is doing for the world of software. One way to think of Cloudsmith is as a derivation of Dell’s world, for software. You can browse an online catalogue at Cloudsmith and see what “distros” – configurations - of software components are available. If you want to chose any particular one, you click it and it “materializes” – ie downloads its parts, and then automatically assembles them together – onto your machine. And like getting a system from Dell, the different components of your configuration will usually come from different “repos” (repositories - think Dell sub-suppliers) around the world. So rather than just a single download of a binary file, a materialization will usually automatically fetch multiple files, from multiple places, and assemble them automatically for you on your machine as a complete system. The distro is thus “virtual”: it is not monolithic (like an old download) and its parts are not hosted at Cloudsmith (any internet repo can contribute).

If you like what you find, you can send others the “Cloudlink” you used. When they click it, the same components will materialize from the cloud of components available in multiple repos across the internet, and assemble and install on their machine too. So, you can materialize something specific without having to yourself connect to the Cloudsmith site and without having to search the online catalogue for it – just get the Cloudlink for it from someone else via an email or blog or whatever, and the magic will happen when you click.

Whats kinda nice about the Redhats of this world is that they pre-assemble a large collection of software components for you as a full Linux system. Whats nice about Cloudsmith is that if you build your own interesting set of software components, then you can publish that configuration at Cloudsmith, and reliably make it available for other people to use. It need not of course be as complex as a full operating system: just a nice application or tool or subsystem for a particular use which you have put together, using your own design or as an interesting derivation from somebody else's published distro. You can publish novel and interesting things that you’ve done, for others to take a look at and possibly use – no longer are you or they tied just to the pre-assembled varieties which the software equivalents of Dell provide. And if you have components from a new repo which Cloudsmith does not yet know about, you yourself can simply add that repo to Cloudsmith’s map of the world – it is the Cloudsmith software equivalent to introducing Dell to a new sub-supplier.

Why hasn’t a service like Cloudsmith existed up to now ? One reason is that although there has been a proliferation of useful re-useable software components developed and published around the world in many online repos, there has equally been a proliferation of software version control, make and build systems. It is difficult to justify re-engineering everything globally to use the same version control and build technology. IMHO it is impossible to impose one build or version control technology, or one IDE, on everyone: and it is short-sighted to expect everyone else to use the one that you happen to think is best. However, with some thought and help, it is possible for systems like Cloudsmith to automatically, on the fly, interpret the meta-information in all these version control and build system technologies, and thus automatically derive a global perspective and capability across many different repos.

But how do you know that somebody else’s published configuration is any good, and trustworthy? Well how does a plastic modeler or an electronics hobbyist know that somebody else’s design is any good ? Part of the answer is the popularity of the design – how many others are using it, and what do they say about it – and part of it is the reputation of the designer. Social community sites on the internet in general work because most people are ethical, and many people can watch, observe, comment and mend where necessary information which is incorrect.

Assembling and publishing new configurations of components is fun. Is it however just for hobbyists and software hot-rodding ? I believe that many commercial organizations will find interest in discovering and contributing to software configurations and assemblies that add real value in their business domains. I think enterprise managers will find reassurance not only in the popularity of certain distros, but also because they can be reassured that precisely the same distro (and bill of materials) is reliably installed on every machine under their control, and because component updates can be notified and controlled. I think vendor product managers and technology strategists will find interest in the concept of being able to build their own private “cloudspaces” for their licensed customer communities, to manage and distribute software in a controllable way.

Now, let me put my hand up and confess that all of this isn’t yet as smooth as we would like at Cloudsmith just right at the moment: it is an alpha version for the community to experiment with and give us feedback on. The materialization wizard, the wizard to build a cloudlink are IMHO both pretty good and straightforward to use. Private and public cloudspaces are ready to use. But today, the publishing wizard and the wizard to register a new repo are IMHO a bit clunky: we’re improving them right now and we expect better versions within a couple of weeks. Our online documentation is being improved. However, if you’re interested, contact us and we’ll talk you through online and get you involved in the Cloudsmith community.

A VP friend at major global corporation – let me call him K-san, rather than give his complete name and afflliation - put it to me thus last week: “The fundamental issue that we have with SOA is skills shortage. With CORBA, it was much easier: there was just one, relatively cohesive, family of standards, and we could recruit to these. In the good days of J2EE, equally so. Now today, SOA is just too ill-defined, and a common set of skills are just not there in the market”.

Wow. Despite all the excitement, all the momentum, all the vendor investment in Service Oriented Architectures (SOA), we in the enterprise software industry are failing to produce an adequate talent pool for our customers. SOA is an architectural style in which complex enterprise systems are composed from business logic components, structured as loosely coupled software services. Because SOA is an architectural style, rather than a specific technology, some (many ?) apparently find it difficult to make a commitment to SOA, and to find staff.

Why is SOA relevant ? One frequently cited justification is – at long last – a common basis for dialogue between business executives and IT specialists. The fundamental building block for SOA is a specific business function, usually encapsulated as a software service. A business function may also be a step purely carried out by humans, with no direct machine intervention. Business processes can be choreographed as appropriate sets of interacting (business level) software services, and human steps if necessary.

A key business value which results from SOA is encapsulating, or wrapping, each business logic component as a (usually, software) service. Other parts of the system can then make use of each such service, regardless of the physical location (in-house or off-premises) or specific technology used to implement that particular service. In turn, a business judgment that a service could be profitably re-located or re-implemented can be executed upon, without a cascade of changes being required on those other components which use that service.

A second, perhaps less obvious, business value is the reduction in effort to implement new business services. This can arise both because business components can be choreographed to work together in concert, and new routines can then be quickly defined to provide new services; and also because new business components can be developed and added into the portfolio of available software services, re-using where appropriate some of the functionality already available elsewhere in the portfolio.

From my own personal experience, the epitome of a practical enterprise scale SOA initiative is that undertaken by Credit Suisse First Boston, built on products from IONA and other vendors, starting in the late 1990s under the leadership of Stefan Murer and Martin Prater. I am sure there are others. The CSFB experience is well summarized in online presentations by Hermann Schlamann and Keith Tice. In some of their SOA metrics – see the presentations - CSFB state they have over 900 business logic components implemented as software services, used by over 150 composite enterprise applications, with an average of 3.7 services used per client application, 43% re-use and development savings of over 12,000 mandays. I understand that more recent figures show even high re-use figures and savings.

But back to my VP friend K-san. In the good old days, you could use CORBA to do SOA – and CSFB did do so. Today, there is confusion about SOA technologies and standards, yielding a perceived show stopper: lack of skilled staff.

I take it as a given that staff are professional: everybody does the best job they can, given their education, training, abilities and knowledge. My own view is that it is hardly the fault of the people: it is the fault of the process. What is it about our approach to SOA that makes it difficult to find people ? How can we change our thinking about SOA so that it becomes tractable, pragmatic, and harder for corporations to make expensive mistakes ?

In chatting to Larry Alston about this, he reminded me of the “people to process” transition made by Henry Ford. Henry Ford did not invent the automobile: the problem was that up until Henry arrived on the scene, cars were being hand-crafted by extraordinarily skilled, and expensive, workers. Henry Ford focused on process: he empowered ordinary mortals to reliably build cars by creating the correct processes, and paid them high wages to do so.

Today’s manufacturing processes are derivative of the innovation of Lean Manufacturing. As K-san effortlessly reminds me, Lean is of course associated with Toyota, and specifically the founder Sakichi Toyoda, his son Kiichiro, the external consultant Shigeo Shingo; the engineer Ohno Taiichi, and the HR executive Isao Kato. The story goes that, in the 1950s, a delegation from Toyota visited the Ford manufacturing plants in Michigan. Although Ford was a global industry leader at the time, the Toyota people were apparently not particularly impressed by what they saw at Ford. In particular they observed large quantities of inventory sitting idle, and noted that the production across the entire plant did not flow smoothly, with staff occasionally just waiting around.

By contrast, during their visit they happened to be shopping in a local supermarket, and observed the simple idea of an automatic drink re-supplier: once a customer takes a drink, another is automatically ordered and replaces it. The supermarket deferred re-ordering and re-stocking goods until customers made purchases.

On return to Japan, Toyota further developed the basic concepts of what is now known as the Toyota Production System, which greatly reduced lead-time and wastage, whilst simultaneously improving quality. The basic ideas of “Lean Manufacturing” were subsequently taken into Toyota’s R&D and design shops, yielding “Lean Design”. Today, Toyota use the tagline ( at least here in Ireland, where we have no car manufacturing of our own and thus import global brands): “The best built cars in the World.”

How do we turn ordinary mere mortals in the software industry into powerfully productive professionals for SOA ? Is it just a matter of education, training, abilities and knowledge ? What about process ? What can we in the software industry learn from what has gone before ?

Lean thinking has had a dramatic impact on the global software community. Significant momentum in Lean Software Development and Lean Product Development developed back in 2003 when Mary and Tom Poppendieck published their excellent book on the topic. The Poppendieck’s studied the lessons of Lean Manufacturing, and particularly Lean Design, and applied it to software development. Elimination of waste, delayed decision making, fast execution, integral integrity, learning amplification, team empowerment are the key factors which they identified in driving a holistic view of the process.

Agile software development is related, but had a different starting point. Rather than a heritage in manufacturing systems, Agile has its nemesis in software development projects and by developers themselves. It is particularly associated with Kent Beck, Ron Jeffries, and Ward Cunningham (now at eclipse.org and a committer to the Eclipse Spaces project which I mentioned last week), during their work on development of a payroll system for Chrysler in 1996, leading to the Extreme Programming (XP) movement. However Wikipedia also notes that the "practice of test-first development, planning and writing tests before each micro-increment" was used as far back as NASA's Project Mercury, in the early 1960s.

Thad Sheer provides an excellent explanation of the differences in philosophy between Lean and Agile approaches in his 2005 blog post. Lean projects need not necessarily be Agile, and vice versa. In summary, he suggests that Lean usually gets more initial corporate support than Agile since it uses concepts to which most executives can relate, rather than terminology more appropriate to software developers. He also states: “There’s a lot more bang for the buck vis-à-vis the bottom line with a partially completed Lean initiative than a partially completed Agile initiative. Once an organization is LEAN, becoming AGILE is a step that developers can take on their own without requiring much management backing.”

In IONA, we started looking seriously at Extreme Programming back in about 2002, when we hosted Kent Beck in person several times to meet with our software development organization. I personally recall that Ciaran Dynes drove much of the initiative within IONA, as one of our engineering managers, and I am grateful for his leadership. Ciaran went on to build our Beijing based development centre – using XP - and is currently our Artix product manager, based out of Dublin.

So Chris, what about SOA, and do Lean and/or Agile apply ? Well, interestingly there is an analysis published by IBM which in its first part summarises various approaches to both Lean and Agile software development; and in its second part discusses that these approaches are not incompatible to SOA. The take-away is “Oil and Water do mix!”

Ooof. Personally, I find such a take-away divisive: it implies that the world of SOA and the world of Lean/Agile are fundamentally confrontational, but that perhaps with sufficient management effort they can probably be brought together. To be fair, the folks at IBM say they were responding to a previous article suggesting that SOA and Lean/Agile actually are incompatible!. All of this is hardly comforting to corporate strategists thinking about SOA adoption, and I suspect would not be greeted with relief by my VP friend K-san.

I think I have a differing view. I believe that a successful SOA results from Lean thinking. I discuss this in my next posting.