chris horn's blog

In the 70s I was a postgraduate student at TCD Computer Science, and interested in digital satellite networking and local area networking technologies. I spent some time studying the design of the Cambridge Ring and other token ring networks. I was then completely inspired by the emergence of CSMSA/CD Ethernet algorithm (in turn derived from the earlier ALOHAnet radio broadcast network) whereby instead of carefully synchronized access to the shared medium, senders are optimistically allowed to transmit whenever they wish: if interference occurs on the medium because of simultaneous transmission, then a randomized backoff procedure allows the system to recover.

I was reminded of all this when I was chatting last week to Lawrence Cowsar, head of Bell Labs Ireland and CTO of the CTVR initiative (I'm chair at CTVR). Sometimes interesting systems result from relaxing constraints and encouraging established taboos to be challenged: for Ethernet, the taboo of careful synchronized access was replaced by unconstrained transmission initiation.

Lawrence, over dinner, was bemoaning the fact that academic research funding is usually and inevitably given for highly focused, highly specialist, uni-disciplinary research. As a result, although the majority of postgraduate researchers, PhDs and post-doctorates may have some experience in team work, that team work is only within the constraints of their own particular research area, under the guidance in most cases of an appropriately myopic faculty member.

By contrast, in general in industry, and in Bell Labs as one example, researchers pro-actively participate in inter-disciplinary teams. This in general seems to be in complete contrast to most academic research. One reason this seems to be is that in general it is difficult to find funding agencies willing to invest in real inter-disciplinary projects, for which multiple research laboratories and multiple terminologies and backgrounds are involved – in general proposals for such research are peer reviewed by research specialists who in turn emphasize uni-disciplinary and singular focus as the best way that their own particular state of the art can be advanced.

I was also reminded of the inertia towards “interference” of disciplines and research when chatting to Lawrence about the technology and algorithms of co-channel management for mobile phone (cellular phone, if you are US) networks. In today’s mobile networks, transmitter masts are carefully erected across a city or landscape so as to minimize interference between masts which reuse the same radio frequencies. This co-channel management challenge is usually resolved by map-colouring algorithms, which allocate frequencies to masts during the network design so as to minimize interference. Sometimes, I smiled to myself, do research proposers seeking financial support from various funding agencies use a map colouring algorithm to minimize the overlaps between their work and so optimize their chances of funding ?

CTVR, and the other CSETs funded by SFI, really are inter-disciplinary: multiple laboratories, academic and industrial, with a very large set of skills and backgrounds. Terminology and a common ability to communicate and collaborate were definitely a problem in the early stage of CTVR. However, we are now seeing highly interesting results which IMHO could only have emerged specifically because of the inter-disciplinary nature of CTVR.

One example is collaboration between the thermal (heat) management research team in the University of Limerick, the radio frequency (RF) and dynamic spectrum research team in NUI Maynooth, the software radio team in TCD, and finally the constraint and optimization analysts at UCC (a full list of CTVR partners is here). It turns out that the taboo of pair-wise interference minimization for co-channel algorithms for mobile (cellular) phone networks can be broken. In fact, channels need not be carefully separated, and interference can be allowed. Using insights from “temperature interference” in thermal management systems, instead of pair-wise constraints between transmitters, a single constraint can be applied to all transmitters whose signals can still be reliably discerned by a receiver. Channels can then be allocated in mobile networks in such a way that has the commercial benefit of reducing the numbers of transmission masts and equipment required.

Who would have thought that research into heat management would lead to an interesting new way of allocating channel frequencies in a mobile phone network ?

Another example of multi-disciplinary work is the application of well understood results in the radio frequency and dynamic spectrum field to the relatively younger area of photonics and management of light, for next generation 100Gigabit Ethernet – work being led by Tyndall at UCC, but for which the NUI Maynooth RF engineers have been able to bring remarkable insight.

In my view – and I believe I speak for Lawrence too – some of the ablest and best researchers which industry can hire come from those postgraduates and post-doctorates who have truly experienced and innovated in inter-disciplinary research. Taboos can sometimes be best challenged and overcome by researchers from outside the immediate specialist domain in question. And yet, world-wide, much academic research seems structurally resistant to such ways of working.

As some of you may know, I regularly holiday just outside Roundstone in Connemara. I’ve just come back to Dublin yesterday after some time there again.

If you haven’t yet been to the west of Ireland, I think one of the most striking things is the web of small stone walls that embrace the fields, pastures, meadows, boglands and tracts. Each is made by hand, and almost always as dry stone walls without mortar. They usually are as a result of clearing granite stones and rubble from the fields, and are economic: not requiring mortar, they do not suffer from frost attack, and so little maintenance is needed. At first sight, they all appear similar, but in fact there are different construction styles, with single, double and combination walls as the basic classification. They are malleable: walls can be easily moved and re-configured – gates are not strictly necessary since a few stones can easily be removed and put back again to, for example, let cattle through. Patrick McAfee’s book and website are a very readable commentary.

From ground level, the profusion of little stone walls can appear as a complex pattern, perhaps even fractal-like. But viewed from a high point, perspective reveals the logic of the landscape and the paths – the boreens – lined with walls either side, gently meandering to distant places.

I came back to Dublin last night, and this morning read Martin Banks’, of Reg Developer, excellent overview of Buckminster. Since I first wrote about Buckminster, the team has considerably improved the tool, including the documentation kit. Martin’s article makes use of a bricklaying analogy, and I guess I hinted in my own blog entry that if you are to build structures from re-usable bricks, then it might be useful to have a web site somewhere at which various designs could be published found and compared…

Well, also while I was away in Connemara, www.cloudsmith.com went live. Many of those on the Buckminster team have collaborated to put the site together, and the initial incarnation of the site certainly turned out to have richer functionality than I myself expected in a first iteration. There is a fairly detailed overview on the About Cloudsmith page, but in summary:

• Cloudsmith keeps meta-data about assemblies of software components.

• Software components can be sourced from any number of public and private repositories worldwide. Of course, components from private repositories are only available to those duly authorized to use them.

• Cloudsmith does not store the components themselves: but it knows where they are worldwide and how it can access them in the appropriate repository formats.

• A software publisher – an individual, project, or company – can register one or more specific software component assemblies with Cloudsmith.

• A software consumer – an individual, project, or company – can search and browse for available assemblies; and can readily download and install any particular one – “materialize” in Cloudsmith-speak – onto his local machine (or indeed another machine if appropriately authorized).

In effect, Cloudsmith is building a global map of software components (in various forms: source, binary, versioned, and optionally with test suites, documentation and license agreements). Professional software developers - individually or in a community project or working on a commercial offering – can publish interesting new assemblies of components, sourced across one or more repositories.

One of the neatest capabilities of Cloudsmith is a Cloudlink. A Cloudlink is simply a URL: it can be sent in an email, or given in a blog or whatever. When a Cloudlink is clicked, the software assembly which it denotes is then materialized without further intervention, onto the local machine. This gives a very simple download mechanism: publish a Cloudlink, and anyone clicking on it within a recent-vintage web browser can download your software. In practice, when a Cloudlink is clicked, behind the scenes the Cloudsmith site is contacted, and it resolves the differences between the assembly of software components identified by the Cloudlink, and those already available on the local machine, and then fetches (as appropriate from various repositories worldwide) and downloads the missing components.

Cloudlinking in turn enables “virtual distributions”. A software publisher can create a virtual distro, whose components reside across multiple (eg open source) projects and repositories: materializing a virtual distro requires nothing more than a web browser.

If your project is looking for a simple way to make its software available to the worldwide community; if your project is itself using software from multiple sources and multiple projects; if you want to keep your community regularly updated with patches and extensions; if you want to manage installation and distribution processes; then Cloudsmith should be worth taking a look.

Software components, and configurations and assemblies of them, are very malleable. It is relatively easy to define new interesting configurations, as well as new components. Looking at the world wide activity, and the multitude of repositories and projects, it is easy to become overwhelmed. It is possible to detect patterns, and different styles of construction, but sometimes it can be very confusing to see overall themes, to understand how other people are using configurations, and what changes have occurred.

I’m reminded of Connemara’s dry stone walls. They are numerous, wonderful, simple, easily changed, easily re-built, easily maintained, and as a result have lasted for decades. But in the landscape and up close, they are confusing to absorb and see the overall picture. The perspective of height gives clarity.

Cloudsmith is giving clarity to the construction of assemblies of software components.

What should be the justification for software patents ?

Software patents are now emerging as a major influence on open source software. In 2003, there was SCO’s threatened litigation on Linux. Last November, Novell and Microsoft signed a major agreement in which Microsoft undertook not to dispute use of Microsoft’s patents in Novell’s SUSE Linux technology. More recently, Microsoft has claimed that Linux and open source technologies infringe 235 of its patents.

Major open source organisations like Eclipse and Apache scrutinise contributed source code to try and ensure there are no patent infringements. Furthermore, under some contribution agreements, an individual contributor may become personally liable if (s)he successfully inserts infringing code into such collaborations.

IMHO, software patents are sometimes granted by national patent offices with insufficient scrutiny regarding their originality. A patent should pass the “obviousness” test: the principles claimed in a patent should not be immediately obvious to normally skilled practitioners in the field at the time that those claims are made. Having said that, it is clear that many software patents do pass this test, and are sufficiently original.

It is also illuminating to note that even when a patent is subsequently over-turned by a national patent office, as being “obvious”, a litigant may still be successful. I understand that Research In Motion (who brought the Blackberry to market) settled their purported patent infringement case with NTP for over half a billion dollars, even after many of the patents were overturned by the patent office concerned: the Judge involved would not reconsider his judgement in the light of the overturning of the patents by the patent office.

While thinking about these issues, I was interested to see developments in the use of patents in the global pharmaceutical industry, in a recent Economist article, and wondered about parallels in the software industry.

Recently, the Government of Thailand invoked the compulsory licensing mechanism of the Agreement on Trade-Related Aspects of Intellectual Property Rights (TRIPS), negotiated globally as part of the Uruguay round of the World Trade Organisation.

Under TRIPS, a government can invoke compulsory licensing (see article 31 “Other Use”) in the interests of national emergency or extreme urgency, such as arising from national health concerns, and if efforts to negotiate with the patent owner (for example a pharmaceutical multinational) fail. As a result, a generic drug replacement for a patented drug can either be manufactured domestically, or imported from a third country.

A quick aside, just in case you are unfamiliar with generic drugs. A generic drug contains the same active chemical ingredients as its patented original, but is distributed without a brand name. It is bio-equivalent to the original. A drug patent publishes a chemical structure, which then readily copied as a generic: alternatively, a patented drug can be fairly easily reverse-engineered to produce a generic. Of course, normally a generic drug can only be legally produced once the patent for its original expires, or in territories where the patent does not apply. Compulsory licensing under the TRIPS protocol yields a further way of legalising the use of a generic drug within a specific country.

In general, bringing a new drug successfully to market requires extensive trials, under a rigorous procedure closely supervised by a national drug regulator. This is both time consuming and costly for the inventor, and hence patents are valuable in enabling their owners recoup not only the research and development costs involved, but also the costs of the clinical trials and regulatory procedures. Correspondingly, because a generic drug is bio-equivalent to its patented original, a generic can quickly gain regulatory approval, and therefore its cost is significantly lower.

The trade-off in invoking the TRIPS compulsory licensing mechanism is between a short term gain to obtain a beneficial treatment at lower cost, and a medium to long term disincentive for the industry to invest in research and development for new drugs, particularly for diseases more prevalent in the third world and emerging economies. Equally, the full costs of bringing a new drug to market will be even more met by those countries which do not invoke compulsory licensing: in practice, by the markets of the more wealthy nations.

It is also significant that a middle income country like Thailand – rather than an impoverished country – has invoked compulsory licensing. It is rumoured that other such countries – for example Brazil, India, and Malaysia – are also considering the mechanism. Some of these countries – in particular India – have their own blossoming drugs industries, including investment in research into new drugs: it will be very interesting to observe how a strengthening domestic industry in such a country can be reconciled with compulsory licensing.

Back to the software industry. I found it interesting to consider what if compulsory licensing under TRIPS were to be used in the software industry as well as the pharmaceutical industry ?

If this were the case, a national government might invoke TRIPS compulsory licensing of one or more software patents, in the national interest. This would probably be primarily as a result of economic and/or social, rather than health, concerns. Compulsory licensing might be seen as a legitimate response by a government to punitive action threatened by an aggrieved patent holder against users of a patented technology, whether those users be in nationally strategic industries, the civil service itself and/or the national education system.

The technical consequence of compulsory licensing of a software patent is clearly not equivalent to compulsory licensing of a pharmaceutical drug. As I noted above, a generic drug can quickly be derived as a bio-equivalent of a patented drug. It is not nearly as easy to produce a software program which is equivalent in all respects to another program which is built using one or more patents, assuming that the source code of the patented work is unavailable. That is, there is no direct software analogy of generic drugs. Nevertheless, compulsory licensing of a software patent would remove the ability of the patent holder to impose punitive licensing terms on infringing software, including in particular infringing open source software.

If there were no intellectual property protection, would there be innovation ? Some open source protagonists would claim ‘absolutely, of course there can be’. I personally think that although there can be innovation in software without intellectual property, nevertheless so far, innovative and intellectual property free open source software is unfortunately rare. More frequently, open source software is a replacement for well established main stream technology: Linux, JBOSS and MySQL are all examples.

So, if there were compulsory licensing of software, would commercial software organisations become disenchanted with investing in innovation ? I started this blog entry by musing what should be the justification for software patents ? In my view, the pharmaceutical industry points the way for us in the software industry.

Consider. In the pharmaceutical industry, a new drug has to be extensively proven in trials, before the national regulator will permit that drug be sold. The resultant product is thus reasonably expected to be safe and to address the medical problem for which it is claimed. In return for this investment and careful procedure, the drug inventor can be awarded a patent.

By analogy then, should therefore a software patent only be awarded once the software products which exploit it, are carefully proven to be safe and effective, via documented testing and trial use ? Should there be national Software Administration Agencies, to which a prospective software patent holder should apply, providing extensive evidence of testing and trials under an auditable procedure to verify that use of the technology described by the prospective patent is effective and safe ?

As I think about testing software, I recall a comment to me by Andrew O’Sullivan (the VP at IONA responsible for professional services) last week. The willingness of enterprise customers to accept even a single bug in a software product today is substantially less than during the late 90s and the frantic dotcom era. Today, software is fully expected to work first time, and every time: any bug which comes to light seriously adversely reflects on the vendor concerned.

So: maybe software patents should only be awarded to verified high quality software, in the same way in which patented drugs have to first prove themselves in trials.

If this situation were ever put in place, what of the role of compulsory licensing ? Could a software patent be overturned by a compulsory license issued by a national government for national social and economic reasons, despite the investment made by the patent holder in proving that the software concerned was safe ?

In the pharmaceutical world, the equivalent is happening today to patented drugs. However in the software world, we would not obtain the same result. If a software patent is compulsory licensed, the associated software program(s) exploiting the software patent would not in general be as readily reverse engineered as is a patented drug to a generic drug. Instead, compulsory licensing would inhibit litigation potentially taken by a software patent holder against alleged infringements by other software programs (including open source). But these other software programs would not be identical in effect as the patent protected works – unlike a generic drug which is bio-equivalent to its patented original. In particular, these other software programs would not, by virtue of the compulsory licensing alone, be implicitly as verifiably safe as the regulated products directly using the patents.

In summary, there are some interesting similarities but critical differences between software and pharmaceuticals. It appears to me that there is merit in only awarding software patents to verifiably tested, safe and effective cases. It also appears that there could be an argument for compulsory licensing of software patents. Unlike the pharmaceutical industry and generic drugs, a compulsory licensed software patent would not enable an exact equivalent to be produced. Thus compulsory licensing would simply remove the threat of litigation against infringements. The patented software would be verifiably “safe”: the infringing software would not necessarily be “safe” since it would not necessarily have been subject to the full rigor of regulation. In my view, the outcome would be that commercial enterprises would remain incented, perhaps even more so, to produce patented products, and to ensure that these are safe and fault-free.

It is an interesting time for the world of “Software As A Service”.

At some sort of cerebral level, Dell has been an inspiration for those contemplating a SaaS go-to-market strategy. Dell was renowned in the PC industry for largely avoiding the cost of enterprise sales and retail distribution channels, by instead connecting directly to end purchasers – whether domestic, small/medium business, or enterprise – as much as possible. It is very interesting thus that last week Dell announced, for the first time in 15 years, a retail deal: this time, with Wal-Mart to put some of its low end products directly onto the retailer’s shelves, as its “first step” into a retail channel. Dell apparently needs a distribution platform – and a retailer which 90% of American shoppers use is more attractive than most other retailers – through which to advertise some of its products.

Also this week, Ray Ozzie of Microsoft has stated that it is no longer about “Software As A Service” but “Software And A Service”! He was speaking at the Mix07 developers conference, and primarily promoting the Silverlight technology for Rich Internet Applications. Silverlight will be a runtime for .NET in various browsers – IE, Firefox and Safari – and compete with Flash, AJAX and Javascript to – in Microsoft’s view – provide a much richer video and interactive graphics experience for end users. Ozzie noted that (“fat”) client software not only supports offline usage, but also offers “privacy, empowerment, anonymity and freedom” compared to the “monitoring, auditing and creepy behaviour” of some online services. I guess this was a swipe in particular at Eric Schmidt at Google who is currently promoting substantially enhanced search experiences for end-users, albeit with the consequence of maintaining (private) information about each user.

An interesting part of Ozzie’s presentation was his announcement that Microsoft Live is offering a Silverlight Streaming service providing 4Gbytes of free storage per Silverlight developer, so as to encourage the development and hosting of Silverlight applications. So, if you are a S(as/and)aS developer or independent software vendor (ISV), Microsoft is potentially offering you a rapid way to scale up to address a massive online audience, based on MSN and now not just IE but other browsers as well: up to 1 million unique end users can access your application for free (above that, its 25c per unique user). It will be interesting to see how Google responds..

IMHO we will continue to see a mix of pure software-as-a-service applications (with thin clients); online services with companion client applications (including rich internet access), and fat clients accessing remote services from time to time. There will continue to be a spectrum of configurations.

Regardless, I believe that a critical aspect of S(as/and)aS applications is the ability to scale self-service. Whether you use Silverlight Streaming, Google, Salesforce.com’s Apex or even Wal-Mart (as Dell is doing) to reach a potential audience of millions, I believe that a S(as/and)aS application will be unsuccessful if scaling of its adoption requires manual intervention for every transaction.

Self-service is key to S(as/and)aS – whilst at the same time ensuring that the customer’s experience is happy and helpful. Dell’s appearance in Wal-Mart may in part be due to reports of poor customer service with a purely online self-service store.

One example of online software self-service is of course the open source community. What could be more self-service than downloading source code, and playing and building it yourself ? A common open source business model is to extend self-service with technical support and training. But in turn, this customer support will best be implemented by at least some degree of self-service: witness IONA’s various support offerings for its Celtix family of open source products, including a self-service knowledge base alongside telephone and email support.

LeCayla’s self-service philosophy goes further. In providing SaaS metering and billing, LeCayla’s technology has to address two audiences. The first is end-users of SaaS offerings: LeCayla measures usage, and generates bills and invoices according to actual usage, and in accordance with specific business rules defined by a particular SaaS ISV or application software provider. Naturally, it is desirable that each end-user may use a self-service interface: eg to check her usage, or to change billing information such as a credit card number.

The second audience for LeCayla is the ISVs who want to use LeCayla to meter and bill for use of their software products. Each such ISV registers business rules (eg pricing information, usage tiers, etc) into LeCayla. Furthermore, each such ISV may wish to subsequently change its own business rules at any time – for example for a pricing promotion of a particular product within a particular geography. Naturally it is desirable that not only should end-users have self service to their own usage and billing information; but also that each ISV should also likewise have self-service to its own business rules, as well as to its market adoption metrics and usage information.

For Cloudsmith – the third software company in which I am involved – self-service is also key. As I noted in a previous posting, “sometimes creative developers have different configurations that they seek, or want to define, share and publish to the world. Can interesting new virtual distributions be rapidly defined, communicated and materialized ?”. Cloudsmith will enable developers to self-service find and use interesting software configurations, each frequently materialised from different software repositories (and sometimes using widely different repository technologies and build/make systems). Equally, publishing a new configuration, either to the entire world or to a private community of collaborating developers, will be a self-service activity.

Self-service seems to be intrinsic to scaling software services offered over the internet. Self-serviced services must naturally be scaleable: poor customer support and dissatisfaction will otherwise result. In a self-service, service oriented world, multiple business models are IMHO possible: for example, free access with optional paid-for support and consultancy (IONA’s approach with Celtix as per above); metered usage (LeCayla’s approach); or community based (Cloudsmith’s). I believe that scalable self-service underpins any viable service oriented business model.

Not all S(and/as)aS transactions should be self-service. But unless your S(and/as)aS business model facilitates self-service, then you may be scaleably challenged!

I was the Chairperson of the Irish Management Institute a few years back, which was a little strange because I have no formal background whatsoever in business management, economics or finance! One of the raging discussions we had at the board level of the IMI was what should be the future of executive education in Ireland, including the relevancy or not of business school teaching to the needs of modern entrepreneurship and global business development. I found The Economist article thus particularly interesting, since it alluded to discussions about whether international business schools have lost their way and value.

Then, by coincidence, Monday’s Financial Times had a supplement on Business Education, including its international ranking of the top global executive education schools. It carried several very interesting articles suggesting that the top schools have changed their product from business education to business advice, and almost to management consulting. Customisation of curricula and classes lead to faculty not so much teaching, but instead providing insight in a discussion about specifically how to address issues within a client company, and/or specifically how to apply a particular idea or theory within a client company.

One of the things I had asked myself during my years at the IMI was whether there can be such a thing as a management profession. A profession, by definition, implies some core knowledge, which may be expanded and refined over time by appropriate research and in the light of experience; a way of asserting that an individual has attained a particular level of competence in that knowledge, and therefore can be admitted to the profession; and a code of ethics particularly as to service to the public, including appropriate disciplinary actions if these should be broken (The Economist article makes similar comments). As a professional engineer in Ireland, I am comfortable that Engineers Ireland operates our national engineering profession accordingly. The medical and legal professions are of course similar examples.

But can there be a management or business profession ? Is there a body of knowledge, an admissions procedure, a code of ethics and a disciplinary mechanism ? Can there be a guardian organization for the profession ? In fact should there not be one, so as to protect the public and including shareholders and investors ? However would such an organized profession stifle innovation and entrepreneurship ? As The Economist observes, Bill Gates dropped out of university and would presumably never have made the grade to become a “professional business manager”.

Hmmm. So what is executive education all about ? Can business management ever become a profession ?

I hesitate to comment further in general for all industries, but I do have some views more specifically as applies to the software industry.

In the mid 90s I had the sincere pleasure of having John Cullinane on the board of directors of IONA. John, as I am sure you know, founded and ran the first software company to file an IPO, the first billion dollar software company, and the first company to do a Super-Bowl ad! His company Cullinet was well known during the 1970s and 1980s. John has written an excellent summary of some of his lessons from those years, which I believe are as applicable today to software companies as they were then, in his book “The Entrepreneurs Survival Guide: 101 Tips for Managing in Good Times and Bad”.

One of the things John said to me early on as a board member at IONA was “You know Chris, managing a software company is actually easy”. I did a double-take when he said this to me, but he explained what he meant and I now basically believe he is right. Certainly compared to companies with manufacturing operations, managing a pure play software company would appear easier. I personally believe – and I sure some may wish to disagree with me – that the key operations of a software company (in no particular order) - engineering and software development processes; distribution channels and sales management, including compensation structures and channel conflict resolution; market segmentation analysis and product marketing; product management; professional services fulfillment; pre-sales technical support; after-sales support; product maintenance and upgrades; financial management, including financial planning and administration; internal IT systems; HR management, staff compensation, and gaining staff commitment; corporate marketing and PR; corporate governance; board procedures; management metrics and key performance indicator analysis; customer care and stratification; even M&A post-integration – in summary, all the functions of a modern software company are now reasonably well understood. There is – arguably – a body of knowledge out there which I suspect many of us in the industry would agree represents best practice in the industry, accumulated over the several decades of the pure play software industry since Cullinet. Listening and participating in the year long Leadership for Growth Programme here at Stanford has re-enforced my view. Perhaps somebody should write a book some time to capture this current body of practical knowledge – how to run a software company.

I guess if what I suggest above is true, then in principle two rival companies with very similar product offerings, and very similar strategies, and of very similar sizes, in principle should be unable to out-execute each other. That is a controversial claim, since execution is key to the success of any software company: but I do believe that a professional experienced software CEO is unlikely to make mistakes in execution, since what is needed in execution is actually now reasonably understood across the industry.

Competitive advantage then in the software industry is increasingly unlikely to come from execution alone. Instead, in my view, advantage comes from strategic insight and analysis, from new products and new business models. Advantage comes from understanding the current state within a particular segment of the industry, and leveraging that to introduce new products and services, perhaps in new ways, and which add sufficient value to motivate the market to invest and customers to buy.

“Success is 10 per cent inspiration and 90 per cent perspiration” said Edison. I think that the 10 per cent inspiration to conceive of a new idea is perhaps right; the 90 per cent comes not from actual execution, but from analysis and consideration of whether that new idea is actually worth executing upon – building a strategic plan and getting comfortable with it. If the strategic plan is worth executing on, then the steps to actually execute, given the body of knowledge about modern software company operations, are reasonably straight forward to identify: it should be reasonably obvious what needs to be done, and it becomes a matter of trying to actually do it.

An accepted body of knowledge will not, in my view, stifle innovation. Bill Gates would not have suffocated had such a pragmatic tome been available to him.

Perhaps I’m just representing a personal bias. I get excited by discussions on the state and direction of the industry, and where the current leverage points and opportunities are. I get less excited by discussions about operational issues, which of course are important and critical, but reasonably obvious in what needs to be done. Innovation in the industry creates competitive advantage; sheer execution is increasingly unlikely to do so.

I’m open to counter-persuasion. Flame suit on. What do you think ?

There’s an interesting interview with Niall McCullough, architect, yesterday in the Irish Times weekend magazine, about the new version of his book “Dublin: An Urban History” (unfortunately the Irish Times online is only premium paid-for content so I can only give you this url to the article). There’s also an interesting web site, giving additional histories of Dublin and the patterns which have shaped it at www.reflectingcity.com.

One of the things which I had not realized about Georgian Dublin is that the buildings, which of course are a part of our heritage, were apparently in general not built to last! The article says: “Based on a land-lease system, the terraces and squares were designed to stand for the lifetime of the lease, usually between 40 and 100 years, whereupon they would be torn down and built again.” Perhaps this is one reason why the Georgian Society has had so many challenges in trying to preserve the best of Georgian Dublin for us and for future generations.

Earlier in the last week, I was in Liaoning province in north east China, for Sli Siar, for discussions relating to the “Five Points, One Line” strategy to re-invigorate one of the old industrial parts of China. As you probably know, Chinese government policy (until recently) is that land is only available for lease, and is owned by the State. The lengths of leases are set by national law, and vary between 40 and 70 years, depending on the land use: residential, commercial, industrial etc. In fact, China has been through various land reform policy changes: the 1946 reform in which land was expropriated from the landlords and equitably distributed to individual households in rural villages; the collectivisation period during the Great Leap Forward in the 1950s in which land was grouped into shared communes; and the current system introduced in the late1970s during Deng Xiaoping’s reforms. I say “the current system”, because in fact just last month, the National People’s Congress passed a new property law, after many years of deliberations, which recognizes the status of private property including land. In my own experience, urban planners and developers today in modern China in general expect their buildings and developments to survive the length of leases of the land on which they are built.

Then on Friday, having traveled back to Europe the previous day, I was with some folks from IONA, visiting one of our customers in the financial services sector, in Zurich. The meeting was with their senior architect – let me call him Tom. Tom is responsible for their group-wide, global IT architecture, and the meeting was to discuss SOA strategy. One of the very interesting points he and I discussed was that there is a sense in the enterprise IT industry, that at long last, we collectively in the enterprise software industry are “building to last”.

As an aside, I do wonder whether “architect” is the appropriate title for somebody like Tom. I tend to think of civil architects as professionals who design buildings. Rather somebody like Tom is really an “urban planner” – he presides over the current and future infrastructure of an entire software city, on which individual applications – buildings – are built.

Anyway. With previous middleware technologies – DCE, DCOM, CORBA, J2EE, etc – and with all due respect to those thousands of technologists world-wide who worked to create these technologies, I think there was always an expectation amongst senior architects (urban planners ?) and IT visionaries, that each of these technologies would fade in time. Sure, each might be strong enough to last for a decade or so, but business logic and applications that were built to exploit any one of these technologies were constructed in the expectation that a more modern, better middleware technology, would emerge within at most a decade. It was perhaps like the relatively short land leases of Georgian Dublin I mentioned above: build your artifacts in the expectation of re-building them a few years later. And so the middleware world proved to be,

Tom postulated that, at long last, enterprise software architects (urban planners ?) can be like the Victorians of over a century ago: laying down infrastructure – whether it be urban water supply, underground and metro train networks, or even sewage pipe networks (what is the best analogy for middleware ? – I leave it to your personal prejudice!) – that will last for a hundred years or so. Is SOA the end of middleware as we know it ? Isn’t SOA good enough to give us a stable infrastructure for at least a hundred years ?

Well, my view is yes, I agree that it is but with one proviso: one has to construct a SOA based (urban-like, city) environment in the expectation that middleware technologies will in fact continue to evolve and change. SOA may mark the end of middleware as we know it, yes Tom, but its chief contribution in this context is its meta-level. In the same way that metadata in a database allows one to reason and manipulate the underlying data, so should a SOA system enable one to reason and manipulate the underlying middleware.

SOA capabilities in frameworks like Artix and its open source companion Celtix allow a de-coupling between business logic and services, and the underlying middleware. In particular, future middleware technologies can be inserted into such frameworks. The meta-level capabilities enable dynamic re-configuration, including for example interface versioning, data versioning, retooling and end-point guardianship.

With SOA, we have indeed reached the end of middleware as we know it, and can now enable enterprise applications which can be built to last.

Fans of Roddy Doyle will know that one of his novels is “The Van” in which Jimmy Rabbitte sells cheap grub – fish and chips - to the hungry in Dublin, whilst trying to stay one step ahead of the city health officials. If you haven’t heard of Roddy Doyle, then perhaps you might nevertheless have seen the movie or heard the music from “The Commitments”, which is based on one of his other books, and is the story of a new soul band born in Dublin city.

“The Van”, or “Van the Man”, are also nicknames for the great Belfast musician and singer Van Morrison, one of my personal favorites.

Anyway. “The Van” is kind-of well-established in Dublin culture!

For the next two weeks, a new “Van” is hitting the streets of Dublin. It is white, marked prominently with “CTVR” and has various antennae on the roof. In fact, it will be making history: in conjunction with two major international wireless conferences being hosted back to back in Dublin – IEEE DySpan and IEEE VTC – the first civilian trials (I believe in the world..) will be taking place in live dynamic spectrum, ultra-wideband antennae and software radio.

The unique trials are being undertaken by international researchers attending either or both conferences, and the research team in the Centre for Telecommunications Value Chain Research (CTVR), for which Prof. Donal O’Mahony is the Centre Director; Dr. Linda Doyle of TCD leads the software radio activities; Dr. Ronan O’Farrell of NUI Maynooth leads radio frequency hardware research; and for which I am the current chairperson.

Raw data and the results of the live experiments are being made available to the attendees of the two conferences, for follow up study and research. Some leading companies and researchers worldwide have brought their own equipment and research tools to Dublin to be able, for the very first time, to conduct their own live experiments, during the two conferences.

Our national Commission for Communications Regulation (ComReg) granted CTVR a special trial license for the research, which enables live experimentation in dynamic spectrum management. The work has global impact, since in general the electromagnetic spectrum worldwide is increasingly crowded. Currently, broadcasters (mobile phone operators, TV stations, radio stations, emergency services, satellite communications, navigation frequencies, etc) are statically allocated frequency ranges by each jurisdiction. In many cases however, the spectrum at specific frequencies and at a particular location or region may be actually currently idle – for example a TV station might be currently off-air, or current traffic on a mobile phone network relatively light. Dynamic spectrum techniques change the entire model: frequencies can be allocated on demand as actually needed rather than statically pre-allocated; used, and then released. They even can be traded on demand, opening up entire new business models..

Ireland’s own use of the electromagnetic spectrum is not as crowded as many other jurisdictions, in part as a consequence of not having a large military requirement for frequency allocations. ComReg has been remarkably fore-sighted in permitting (I believe, the world’s first civilian) live experimental use of a large swathe of frequencies, including for CTVR. One major possible use of dynamic frequency techniques and ultra-wideband antennae is for IPTV transmissions. Equally, software radios potentially enable miniaturisation of the current portfolio of antennae ‘stacks” – such as in “tri-band” cell and mobile phones, and other mobile devices and sensors – into a single, dynamically-tuneable, antenna driven by software.

If you’re in Dublin city over the next two weeks, watch out for the CTVR Van!! And if you’re interested in dynamic spectrum, software radio or ultra wide-band antennae, then get along to the conferences, in the Burlington hotel.

How do you change an entire nation ?

It’s a topical and fascinating discussion to have over a coffee, and clearly is preoccupying a number of people right now. You may be aware elsewhere from this blog that I have been a frequent visitor to China since 2000: the incredible social shepherding of this enormous nation must be one of human history’s extraordinary moments. I found George Packer’s book on the American administration’s work in Iraq both entirely credible and frightening. My trip to KwaZulu Natal province in South Africa last November with UNICEF brought home to me the frustration of a nation challenged to put its wealth and talent to work in rebuilding after a brutal regime. Closer to home, it is intriguing to watch the recent developments in Northern Ireland as Ian Paisley of the DUP and Gerry Adams of Sinn Fein sit down together to form a devolved government.

Changing an entire enterprise IT infrastructure should not be as demanding as changing an entire nation, but sometimes I’m sure some of us wonder. The introduction of a Service Oriented Architecture, and the management of a Service Oriented Architecture, at enterprise scale, and almost certainly globally, gives justifiable cause for reflection.

As you may have seen if you follow IONA, we announced our first product in the SOA repository and registry sector last week. While some observers expressed strong interest, nevertheless certain others believed that IONA is entering a somewhat crowded space, with various other existing pure play and bundled repository/registry products already out there.

The essential difference, IMHO, between a SOA repository and a SOA registry is in fact largely historical, and most vendors in the space – including now IONA – offer a combination. A SOA registry is (traditionally) used to register WSDL interface definitions and to catalogue available services which implement particular interfaces. It is particularly useful at development time to guide software engineers to discover and re-use existing definitions. A SOA repository is (again, traditionally) a runtime store in which certain meta-data about WSDL interfaces and services, and certain governance policies, are recorded, and made available for interrogation by applications and by the underlying middleware substrate.

In a SOA environment, the distinction between a development time phase and a runtime phase is arguably a little artificial – and as a result, the industry is moving to the combination of repository and registry functions within the same products. A new service is evolved over its lifetime within the SOA, and must both be designed and maintained within the context of other operational services. Certainly, a new service must be deployed with care, adequate testing, and appropriate “sand-boxing” so that it does not disrupt the operations of other services; but equally it cannot be developed completely in isolation to the operational effectiveness of the current system. SOA systems are inherently loosely coupled, and thus full testing of the interdependency between services usually ultimately happens carefully in an operational setting.

The governance of SOA systems is a key theme of the vendors – again, including IONA – in this space. Combined registry and repository products are positioned as assisting the judicious management of both the development and operation of a SOA. No doubt “SOA governance” has been chosen carefully as a catchphrase by the SOA industry, resonating as it does in some business executives’ minds against the backdrop of Sarbanes-Oxley and other recent corporate legislation worldwide.

The pragmatic challenge for any SOA architect concerned about the governance of enterprise systems is of course that governance policy mechanisms are almost certainly already widely fragmented across the entire software system. Some policy mechanisms may already be embedded in application code and business logic. Some are in stored procedures, relating to the probity of particular databases and their data management applications. Some are described by business processes, and orchestrated by business process engines. And now, SOA registry/repository vendors come along and pitch “SOA governance” using their respective products.

In a SOA system, how do you implement policy ? How do you affect changes in policy ?

Let’s return for just a second to the analogy of governing a sovereign state. There is both the integrity of the state, and strategic management of it, to consider. By integrity, I mean both a legal framework by which the state operates, including an appropriate set of laws, perhaps set against the framework of a constitution; and an appropriate enforcement mechanism by which the state and its citizens can reasonably assured that laws are obeyed. By strategic management, I mean the set of policies – laws but also fiscal and other incentives - which the state chooses to adopt to, for example, grow its economy, educate its children and its citizens, and care for the health of its population. However, strategic management cannot occur unless the fundamental integrity of the state is assured; equally, an assurance of integrity alone does not necessarily lead to the long term economic and social success of a nation.

From this analogy, I believe it may be useful to draw a distinction between the integrity of a SOA system, and the business policies and processes chosen to be implemented using it. I believe that integrity should be defined and enforced using a “SOA Guardian” – I deliberately introduce a new term – whilst business policy implementation is rightly the domain of business process engines and orchestration.

Interestingly, business process mechanization and SOA service orchestration has probably been given more attention, priority and emphasis, by the SOA industry at large than SOA integrity issues. BPEL and WS-CDL are probably the best known business process mechanization initiatives, for which a number of process engines exist, including in open source form. Indeed, orchestrating business services defined using standardized interfaces is one of the key selling points of SOA, if not the very essence of SOA for some protagonists. Perhaps business process orchestration and choreography has had more attention than SOA integrity, since there may be a perception amongst SOA practitioners that line of business managers, and corporate executives, can relate most to corporate business process enhancements, rather than the more complex holistic concept of SOA.

But “salus populi suprema est lex”: Cicero said that the ultimate law is the welfare of the people. If the people are unwell, how they can they be governed ? If an enterprise system is impaired, what benefit is business process orchestration ?

“SOA Governance”, if it denotes anything at all, should encompass both SOA integrity and strategic management of business services orchestration: I believe that that is in fact what line of business managers, and corporate executives, expect from the SOA industry.

SOA integrity is a critical prerequisite to leveraging a SOA for business process orchestration. The boundary between the two is naturally dithered to produce effects which are actually not really of substance: business process orchestration can be overloaded to attempt to define and enforce integrity; integrity functions can be strained to implement business policy rules. In the spirit of lean software services, I argue however for a separation of concerns: SOA integrity should be focused as a complete baseline from which business policies and procedures can be easily defined, rapidly deployed, and safely evolved.

A SOA Guardian should be driven by rules relating to the integrity and unimpaired operation of the entire system. It certainly includes security concerns, and the authentication and authorization of access from principals to SOA hosted services, based for example on LDAP directories. However it also includes performance concerns, such as load management and brisk responsiveness. It knows the configuration of every service, with technical details such as the size of the allocated thread pools, binding and addressing information, runtimes and containers across the (almost certainly, highly heterogeneous) SOA deployment: it can be used to re-boot any failed service or even ultimately the entire enterprise. It includes transactional integrity, fault and outage management, so that the temporary loss of one or more SOA hosted services does not cause catastrophic failure. It includes management of change, including management of schema and version changes of services and interfaces. In particular, it includes the planning and execution of technology change, so that old technologies and services can be phased out, rationalized and consolidated, without adversely affecting operations.

It is clear that a SOA Guardian has both – forgive me folks, I’m an engineer by background! – sensors and actuators. That is, it collects and presents operational information relating to the integrity of the system. Equally, it is the mechanism for implementing and enforcing changes to the integral operation of the system. It is clear that the Guardian itself needs to be sound and cohesive: a Guardian system will itself likely be federated and fault-resilient. Because of the heterogeneous nature of most SOA environments, a SOA Guardian may well use combined repository and registry products from other vendors in order to administer details of certain proprietary environments. A SOA Guardian is thus much more than the emerging generation of combined repositories and registries.

Having a repository to record decisions and rules relating to the integrity of the system is certainly useful: the library of a parliament records the laws made therein. Having a console from which operational metrics can be gathered is also important: laws should be made in the context of the society they influence, and it is the role of elected representatives to reflect the views of the populace and the current state of society. But a SOA Guardian also includes the enforcement mechanisms to impose change on a system. Some “SOA Governance” products, surprisingly, apparently are weak or even non-existent in this regard.

For a SOA Guardian to enforce a change, it should clearly be desirable that the entire SOA system not be brought to a halt. Changes in security integrity are already routinely dynamically enforceable in most systems. Changes in configuration to improve performance can sometimes be dynamically implemented in some systems. Changes in fault avoidance and outage management can likewise be dynamically enforced in some systems. Changes in schema and interface versions likewise. Changes in technology are perhaps the most difficult to dynamically implement.

A SOA Guardian, given the correct meshing with the middleware substrate, should nevertheless be able to dynamically deploy all such changes to the integrity of an operational SOA, including changes not hitherto envisaged or previously planned. There should nevertheless be no need to update application business logic or business orchestration in making changes to the integrity of the substrate.

Provisioning changes in telecommunications infrastructures is both a science and an art, based on operational experience. Vendors with experience of such realtime provisioning may emerge to become one source of what I have called SOA Guardians.

How do you change an entire nation ? How do you successfully effect evolution of an entire system ? My view is “carefully”, using small incremental and rapidly evaluated steps, along with a strong separation of concerns. The integrity of a SOA implementation is different from the orchestration of business services to exploit a SOA deployment.

“SOA governance” tools may (perhaps, for some vendors even deliberately) confuse the issue. I encourage the industry to instead separate the concept of SOA guardianship from SOA orchestration. A combined repository/registry tool is a step towards a SOA guardian: dynamic binding, late decision, immediate execution and enterprise wide deployment, is also needed for complete integrity and agility.