Nick Gall's Weblog

Saturday, April 02, 2005

Goodbye META, hello Gartner. I haven't written much about my life at META Group, Inc. in this blog, because I like to keep my avocation (Information Technology, Philosophy, Evolution) separate from my vocation (IT Industry Analyst). I make an exception today to commemorate my nine years with META (April 15th would have been my 9th anniversary) and to announce that I have accepted a position at Gartner as part of its acquisition of META Group. I will continue to blog as always, with one restriction. In light of Gartner's brand-management policies, other than this posting, I will not discuss Gartner or my activities at Gartner. As an ex-attorney, I appreciate bright lines. 3:59:00 AM

Thursday, March 31, 2005

My other blog. While I may not post an entry to my home page everday, I do post interesting web resources that I run across to Furl (my online bookmark service) virtually every day. You can see my latest Furl postings in the Navigation box on the right of my home page: Also, if you are interested in some of the same issues that I am (mass innovation, SOA, modularity, Web services, Evolution, Philosophy, etc.) I urge you to subscribe to the RSS feed for my Furl bookmarks. You will then receive a steady stream of link to interesting resources (with my brief descriptions). Simply click on this Subscribe to my Furl Archive link, or the one directly beneath my list of Furled pages in the Navigation box. 4:30:10 AM

Wednesday, March 30, 2005

The dark side of flickr: N reasons why you shouldn't post your picture on the Internet. Check out these pictures of someone who made the mistake of posting his photo to the web. Hilarious. Each picture gets better and better. 1:23:00 PM

The mysterious crystal ball knows all. An anonymous friend turned me onto this cool game . It's uncanny. How does it read my mind with such unerring accuracy? Try it and be amazed.<grin> 12:37:03 AM

Tuesday, March 29, 2005

Fun examples of mass innovation. Here's a great example of an emergent use of a web service: spelling words with a font composed of letter pictures from flickr! This was generated by spell with flickr. The HTML in this post actually queries flickr for photos of individual letters. You've got to play with it. Here's my name in pict-o-glyphs: Or check out another emergent use, this time of Amazon. It's called Amaztype and it will amaze you. Click on the image below to go to the page running the flash. When you click on a letter, it will magnify and you will see that each letter is composed of book jackets containing the word philosophy in the title! Click on a book jacket to go to its Amazon page. Amazing. Here is the word philosophy: Or check out mappr (maps flickr photos to US Map based on tags). While none of these has a business model, they show the incredible ferment of experimentation of...what to call it...emergent applications, composite content, web content services? Whatever you call it, it signals the birth of new directions in the Web's information space. 1:42:15 AM

Monday, March 28, 2005

SOA insight: interoperability enables evolvability. As I mentioning in a previous post, I've been doing a lot of deep thinking about Service-Oriented Architecture recently. Over the past couple of years, I've been relentlessly positioning SOA as essentially a set of architectural principles for interoperability. One of the most important interoperability principles is the internetwork principle, which SOA inherited from the Internet: an interoperable network must be designed as a network of (heterogeneous) networks. But in working with organizations implementing SOA (and its preferred SO- technology, Web services), I've noticed that while they achieved dramatic improvements in basic interoperability, as advertised, they failed to achieve dramatic improvements in extensibility. This is ironic, given the central importance of XML, the eXtensible Markup Language, in SO- technologies. So I've spent the last six months really thinking hard about extensibility specifically and evolvability generally (or course I'm always thinking about evolvability). I've come up with what I think is a pretty profound insight: interoperability enables evolvability. In fact, to push the point, I'd argue that they are two sides of the same coin. Both are very slippery terms, so let's get specific. Interoperability deals with how different systems interact to form a unified system. Often, the concept is centered on the interaction between offerings from two or more different vendors. For example, if modems from several vendors can interact to communicate, we say they are interoperable. Interoperability is enabled by a common protocol implemented by multiple vendors. But now think about a product from a single vendor as it evolves from version to version. If the versions need to interact (e.g., communicate directly by some protocol or indirectly by sharing files), then we have what is commonly know as a compatibility issue (specifically forward and backward compatibility). The crux of my insight is that compatibility and interoperability are merely different aspects of fundamentally the same concept: interaction. Interoperability is focused on the interaction among vendors' products implementing a specific protocol version, while compatibility is focused on the interaction among one vendor's products implementing different protocol versions (which includes file or document versions). But in both cases we are really dealing with variations (versions) of a common protocol. In both cases, a vendor is modifying its implementation of a protocol to add new behavior, remove old behavior, or change current behavior. If products implementing different versions of a protocol can successfully interact then they are said to be interoperable, when the products are from different vendors, or compatible if the products are from one vendor. But despite the different labels, it's the same concept underlying them. To put it succinctly: Compatibility is simply interoperability between old, current, and new versions. Accordingly, the better an SOA enables interoperability, the better it should enable compatibility. Of course, the concept of a spanning layer (the narrow waist of the hourglass) is key to compatibility as well. If a spanning layer can be used to unify heterogeneous resources in the bottom of the hourglass, such resources can be different because they are from different vendors or because they are different versions from one vendor. Viewed this way, a rolling upgrade (whose formal definition I cannot seem to find on the web) is simply a federation across old, current, and new versions--in principle no different from a federation across systems from different vendors. I'll have a lot more to say about interoperability and compatibility; but for now, just think about it. 11:34:11 PM