Recent advances in the theory of networks have shed some light on the operations of complex systems in business, society and biology. An article from strategy+business magazine, republished on CNET at the beginning of the year, helpfully summarizes some of the key concepts for business strategists. One of the most striking is derived from the work of mathematicians Duncan Watts and Steve Strogatz on what is known as small-world networking:
"By injecting just a few random connections into a complex network, [they found] they could make that network both more efficient and more effective. The right random links create small worlds from vast complexities. "
Another theory is derived from the notion of power laws, which disrupt the normal distribution patterns of probabilities with sudden, exponential thrusts of significance. Put the two together and you begin to sense the potential impact of unintended consequences that are such a feature of web services and similar loosely coupled systems. It means that forming just a few small and often apparently unconnected links will occasionally create hugely influential and powerful new meeting points within the network.
I only got around to reading this article today, but it chimes perfectly with the sentiments in my ASPnews column this week, in which I discussed the success factors behind companies like Google and eBay, and how present-day entrepreneurs have to focus on connection-minded innovations: "the big successes of the online world are the ones that catered to all the Web's small fry ... All of these successes have come through listening to and empowering participants in the network, instead of trying to hector and dominate them. The old dot-com model ... [has] been replaced by a new model that thrives by enabling connections."
The launch this week of DIY portal capabilities for Oracle's application server platform has not been welcomed in all quarters. According to Forrester analyst Nate Root, quoted in Internet Week, "Portal development isn't a business-user function. IT doesn't want it to be a business-user function ... The way to break the development bottleneck is to give IT better tools, not try to circumvent IT."
Yes, the way to resolve the IT development bottleneck is to throw more money at it. Imagine the anarchy that would result if users could actually get more out of IT without having to patiently wait in line for scarce development resources. Next thing you know, people will be wanting to access external web services on their own initiative, or installing their own desktop software, just so they can be more efficient at their jobs. How can people be so thoughtlessly selfish?
posted by Phil Wainewright 1:40 AM (GMT) | comments | link
Tuesday, January 21, 2003
Courting the unexpected
Innovations tend to come from unexpected directions, so any Web-based application that aims to encourage innovation has to leave itself open to the unpredictable. Many developers (and their paymasters) will probably find that a daunting thought. Conventional application design aims to pre-empt and capture all possible behaviours before rolling out any live deployments, while enterprise managers generally prefer to know what they're getting into before committing funds and resources to an application development project.
Fortunately, it is possible to cater for the unexpected while managing the risks. Adherents of agile software development understand this well, as do most entrepreneurs. With software, the trick is to select methodologies, tools and platforms that support iterative, evolutionary design approaches. In business, agility depends on constant alertness and a willingness to adapt and evolve in the face of new competitive challenges and opportunities.
Staying open to innovation does not have to demand huge investments of time or resources. Often the most innovation-friendly platforms are the simplest. In the spirit of encouraging unintended consequences, the Loosely Coupled glossary now boasts a separate RSS 2.0 file for every individual definition (eg "http://looselycoupled.com/glossary/BPEL4WS.rss"). It costs next to nothing to add a simple RSS file containing the title, link and definition for each glossary entry. My hope is that, by adding a machine-readable version of each entry, it will stimulate others to investigate using that information as a component in applications of their own.
I have no idea where this might lead (perhaps nowhere). It's a slightly odd use of RSS, but I think it's justified, since each glossary term is in effect a category heading in its own right, and keeping them in separate files means that applications can use as many or as few as they like. Of course, the glossary will also have a more conventional RSS file that acts as a feed of new or changed applications. But the individual feeds have gone live first because a) it was an easier programming job and b) I want to see what ideas they might generate. For now I'm making no decisions about what else might be included in each RSS feed, apart from the basic definition. One of the beauties of RSS 2.0 as a format is its effortless extensibility. I don't need to know what might happen next. All I need to do is wait, watch, and move forward when a path ahead presents itself.
posted by Phil Wainewright 1:08 PM (GMT) | comments | link
Monday, January 20, 2003
Glossary service now live
Loosely Coupled's glossary is now operational. For the next few days, think of this as a technology demonstration rather than as a comprehensive resource. The number of terms covered will increase rapidly over the next week or two, but I felt it was worth bringing it live as early as possible since it illustrates several points that have cropped up recently in postings here and elsewhere.
I believe it very effectively illustrates the dissolving boundaries between content and code, which Jon Udell recently observed upon in the context of his LibraryLookup project. It also follows his advice in an InfoWorld column on the same topic: "Support HTTP GET-style URLs .. Keep the URLs short, so people can easily understand, modify, and trade them." And it uses the bookmarklet concept that he found so useful. The result is a glossary that, rather being a document that you have to visit in a fixed location, becomes a service that you can consult without interrupting whatever you're doing. There are more features still to be added, which I'll be mentioning here as they emerge, so it is not only evolving as a body of content, but also as an application.
So is it content, or is it code, this glossary? I'd say it's a blend of both, and the best way to describe it is to call it a service.
posted by Phil Wainewright 12:59 PM (GMT) | comments | link
Assembling on-demand services to automate business, commerce, and the sharing of knowledge