Thursday, November 11, 2004

Feedburner, More Advertising Feedback. Over at his site, Jeremy gives Searchblog his opinion on the Feedburner implementation. Elsewhere, I've gotten comments on the AdBrite ads running on the right and below the permalink pages. Jeremy says: My thoughts on this: • The ads are irrelevant--unrelated to the content of the post. Unlike AdSense, they don't fit in with the context at all. • The ads are pretty big. • That space is not well used. Instead of Amazon.com branding, why not show an album cover there? That might get me interested. Maybe. I have to agree, as does Dick Costolo, the CEO of Feedburner. But I think this issue will be solved shortly, in a matter of months. There will be more choices and more flexibility in RSS advertising, and I sense that given Yahoo's deep interest in RSS, we will be seeing movement from the big guys soon. Amazon may never solve the contextual problem for sites like mine, which are not really focused on products, but that's most likely a problem not worth solving. In any case, when I have a moment, I'll turn off the Amazon ads. I'll try more stuff in RSS when it comes available. As for the AdBrite system, I agree that the ads which show up on my site are mostly crap. A few of them, however, have been endemic or nearly endemic, and that's because someone made the decision to actually buy an ad, as opposed to the network stuff that runs most of the time. Problem: when someone buys an ad, they look just like the network ads, which is not good - an endemic sponsor should look endemic! I'll be working on that with the AdBrite folks. Generally, they have a way to go yet. More to come as the experiment continues...... [John Battelle's Searchblog] 10:47:45 PM    comment []

Bloor Research -- Is the WebSphere family unnecessarily complex?. Is the IBM WebSphere product family unnecessarily complex? If you listen to the competitors the answer is a resounding yes. But the reasons for this complexity and the impact on users are less clea... [Ed Brill] 10:46:24 PM    comment []

[Jamie Lewis]
10:44:11 PM    comment []

MetaSMB: The Self-Organizing, Loosely Coupled Directory. There's a good article on the New York Times site on Dan Bricklin, and his efforts to help small businesses get on line. One of his more interesting ideas in this effort is SMBmeta (small- and medium-sized business metadata). For some folks, SMBmeta is old news. But I talked with Dan about it at PC Forum in March, and it got me thinking about how directories should work, as opposed to how they actually work. And I think there are some lessons we can learn from Dan's work.   Essentially, SMBmeta is a very simple set of XML tags that allow a business to describe itself. Using the tags, a Web site can provide a structured XML document that includes basic information like the business' name, address, phone number, industry type, and so on. The structured XML document, which is very short and simple, lives a the root of the Web server, which makes it easy to find, parse, and process. Bricklin, who came up with the idea as a way to create value-added services for small businesses in his hosting business, thought that search engines could pick up the SMBmeta data, building a directory simply by retrieving and indexing the SMBmeta data.   In other words, SMBmeta is a self-organizing directory. In contrast with X.500 and its descendants, SMBmeta is very decentralized, pushing responsibility and data ownership all the way out to the edge. It makes data aggregation a loosely coupled operation that anyone can perform. Pretty cool.   The Ecosystem   More recently, Bricklin has fleshed out the idea, proposing what he calls the "SMBmeta Ecosystem." The ecosystem consists of Directories, which aggregate and provide SMBmeta data, and Applications, which can consume SMBmeta data. In turn, Directories and Applications rely on the following infrastructure components: the SMBmeta Registry, the SMBmeta Proxy, and the SMBmeta Affirmation Authority.   The SMBmeta Registry makes it easier for applications to find domains with SMBmeta data. Applications can query it for a list of domains and the URLs for the SMBmeta data for those domains, for example, preventing applications from having to crawl the entire web every time they want to get some information. The SMBmeta Proxy publishes SMBmeta data on behalf of multiple Web sites; an ISP could, for example, provide a proxy and publish the information on behalf of all its Web hosting customers. The SMBmeta Affirmation Authority is a server that allows applications and directories to determine the voracity of the SMBmeta data for a given Web site. Essentially, an authority vets the data a site submits to a registry. A directory or application could verify the domain's data by querying the Authority, for example. Alternatively, authorities can use optional digital signature features to sign SMBmeta documents, allowing directories and confirm the authenticity of the metadata by using the Authority's public key to verify the signature.   What Will it Take?   For SMBmeta to work, it has to gain critical mass, and it's hard to tell how much traction SMBmeta is getting at this point. But the SMBmeta infrastructure has some very interesting qualities, not the least of which is its self-organizing, and loosely coupled nature. Since the specification is completely open, any number of registries, proxies, or authorities can operate within the infrastructure. Whether they use each other or not is up to them. There is no forced hierarchy or dependent relationship. Anyone can pick up and aggregate the data, so anyone can provide a directory. Service providers could combine multiple functions, such as the proxy and affirmation authority.   Trust is an obvious and big issue; without reliable authorities, the system won't work, and companies need a good business reason to become an authority. But there are several candidates for that kind of business, including today's domain registration authorities (like Tucows and Network Solutions), phone companies, and yellow pages providers. Instead of being the data aggregator, for example, companies that have traditionally provided the Yellow Pages could be Affirmation Authorities. Domain registration authorities already are authoritative sources for domain names, so it's not a huge leap to see them moving in this direction. And Web hosting companies can, as Bricklin correctly surmised, provide a value-add by helping companies publish their SMBmeta data via proxies. It's another one of those simple ideas whose power seems to increase the more you think about it.   Loosely Coupled Systems Rule   Bricklin also deserves kudos for making the specification open, allowing any Web hosting company to leverage the spec; there's no proprietary advantage for Trellix or InterLand (which bought Trellix). And the loosely coupled, lightweight nature of the system makes it more likely that both small businesses and service providers will adopt and use it.   SMBmeta is also the kind of thing we on the enterprise side of the business equation can learn from. It's loosely coupled, self-organizing assertion model is very consistent with much of what's going on in Web services, federation, and other infrastructure evolution. And my gut tells me that it's these self-organizing systems that will have a big impact on identity in general, and the recognition systems that seem the more natural way to solve the spam problem.   What About UDDI?   Many folks will automatically ask how SMBmeta compares to UDDI, but it's clear that they're very different things. UDDI was first positioned as a public registry for Web services. But if failed to meet that goal because no large enterprise wants to publish so much information about how their software systems work. There's also a huge issue around the trusting and vetting of the  information in a public UDDI registry; the business case simply isn't clear for taking the time and spending the resources necessary to make UDDI work in a public context. Instead, UDDI is finding a role as an internal software catalog. The business case there is clearer; enterprises can get a better return on their software investments increasing reuse through the publication of the catalog within the company.   So SMBmeta and UDDI really aren't competitors at all. In fact, SMBmeta has an interesting take on building a directory on the public side that could catch on. (If I'm not mistaken, some of the folks on the original UDDI team wanted to take things in the direction that SMBmeta has taken.) A self-organizing directory that the Web generates, with some notion of affirmation authorities. It's a good idea. Now let's see if it takes hold.

Thoughts on CA's Acquisition of Netegrity. Computer Associates (CA) recently posted a letter to customers describing its long-term intentions with regard to its pending acquisition of Netegrity. Posting the letter was a good idea; we've been getting a lot of questions from Netegrity customers about what the acquisition means. They're nervous, and that's understandable. CA has a reputation for acquiring companies and then taking advantage of long-term support contracts while providing little in the way of product innovation and development. And many of Netegrity's competitors are trying to take advantage of the inevitably confusing period between the announcement and closing of the acquisition. The requisite "Forward-Looking Statements" disclaimer at the end notwithstanding, however, CA's letter outlines intentions that are both appropriate and good. Our identity management analysts have had quite a bit of direct interaction with CA's identity management team over the past few years. These are sharp people. They understand the identity management market. And none of us here believes that CA spent $430 million on Netegrity just to milk the installed base dry, kill the product, and make a whole new group of customers angry. To the contrary, CA sees identity management as a strategic direction and is committed to seeing things through, consistent with the directions the company outlined in the letter. Consequently, existing Netegrity customers shouldn't panic and rip out SiteMinder. Having said that, however, there are always risks in an acquisition, and customers have to consider both the upside and downside risk in any strategic product investment. CA's acquisition of Netegrity is no different, and it's as good a time as any to consider the ramifications. It's About Market Share One can reasonably argue that the acquisition has as much (or more) to do with market share than it does with products and technology, for example. While there's a small overlap in terms of the CA and Netegrity customer base, there is a substantial overlap in terms of product functionality. With the exception of Transaction Minder, CA has offerings in most of the areas in which Netegrity has products: Web access management, provisioning, and other user management functions (such as self-service and delegated administration). But CA doesn't have the customer footprint that Netegrity does. CA claims a large number of customers for eTrust Access Control, its Web-based access management product. While the company's all-you-can-eat buffet style of product licensing ensures that a large number of customers have the bits, however, many of those customers aren't necessarily using all of the products. SiteMinder has a much larger installed base in production, and CA saw the acquisition as a way to gain significant market share instantly. Nothing wrong with that, per se. In fact, it's a great move for CA if it wants to be a major player in the identity management market. The question is, then, is it a good move for Netegrity's customers? Clearly, Netegrity is suffering the limitations that any smaller company experiences when competing with the likes of IBM, Microsoft, and Sun. It simply can't match the development, marketing, and sales resources that these larger companies can muster. So Netegrity gets some deeper pockets that can, hopefully, accelerate things a bit. Still, I'll have to admit that the acquisition seems a bit anticlimactic. I always expected Netegrity - the vendor that essentially defined the Web access management space-to end up with a platform company company. But does that mean it's bad for the customer? The short-term answer to that question depends on how much you like CA's product licensing and business models. The long-term answer to that question depends on how well CA does in fulfilling the promises it makes it its letter. The onus is on CA to make the acquisition work. SiteMinder and TransactionMinder From a product perspective, for example, CA makes the obligatory commitment in the letter to maintain support for the Netegrity products that it's acquiring. But the parallel product lines the letter describes are, obviously, impractical to maintain over the long term. In fact, the letter states that the company plans "to deliver a superset of both products that combines and capitalizes on their respective strengths. While it can't do so in the period before the acquisition closes, then, CA should describe a more detailed product road map as soon after the closing as possible. In the meantime, it's left to folks like me to speculate what might happen, so here goes. SiteMinder seems to be the most obvious candidate to survive the acquisition as a whole product. With around 800 customers and a large number of production deployments, SiteMinder has a much bigger installed base than CA's eTrust Access Control, as I said earlier. So, as Mike Neuenschwander, associate research director of our Identity and Privacy Strategies service said, SiteMinder seems like "a shoe-in." CA would be crazy to kill that product. At the other end of the market share spectrum, TransactionMinder started out as a tool for applying policy at the transaction level, and was at least partially a reaction to the Transindigo product RSA acquired a few years ago. More recently, Netegrity has attempted to reposition TransactionMinder as a Web services management tool. While it doesn't provide the functionality of the Confluent products that Oblix bought, TransactionMinder is something that can, and probably will, move over into CA's management product line (which the letter implies). But given the fact that TransactionMinder has a very small installed base (and that Netegrity was still trying to figure out what to do with it) you can bet it's not why CA is buying Netegrity. And it's unlikely that TransactionMinder will cause angst amongst large numbers of customers as they contemplate the impact of the acquisition. IdentityMinder's the Rub It's with IdentityMinder that things will get interesting. Netegrity's Identity Minder has three basic components: provisioning (which Netegrity got when it bought Business Layers), user management (self-service and delegated administration), and workflow to support those functions. Netegrity has positioned IdentityMinder as the primary console, the tool for driving policy-based identity management. In theory, that's good positioning. Provisioning systems are logically the best user management interface, driving the basic functions necessary to create, maintain, and terminate identities, accounts, and privileges. In practice, however, Netegrity still has a ways to go in fully delivering on that promise. While Netegrity completed its acquisition of Business Layers long ago, the integration between IdentityMinder (which existed before the BL acquisition) and the BL provisioning product is far from complete. And now the technology has been acquired a second time, this time by CA. More to the point, CA has its own provisioning product, eTrust Admin, which the company clearly thinks very highly of. Acquiring Business Layers allowed Netegrity-at least to some degree-to address the "fear of a small company" problem that plagued all of the "pure play" provisioning companies. But the Business Layers installed base was, and still is, very small. So it's safe to say that CA didn't buy Netegrity for the Business Layers installed base. One way or the other, CA has to converge these two provisioning products, integrate the result with SiteMinder and IdentityMinder's other functions, and address the directory synchronization issue in an integrated fashion. (The latter being a point on which Waveset, now owned by Sun, makes hay in the market.) In other words, provisioning is the area customers should be concerned about the most. While SiteMinder remains the safest bet in the acquisition, the twice-acquired Business Layers technology CA gets via Netegrity seems the highest risk. The number of Business Layers developers that stayed with Netegrity is relatively low. And some of the Netegrity folks won't hang around CA for too long. So the development chain on the BL product doesn't look as strong as most customers would like. (It would be ironic if the CA folks end up luring some of the old Business Layers developers in Israel back to work on the product, however.) Licensing Models This is also a point at which the CA product licensing model will have an impact. There are customers who really like that model. And for the Netegrity customers in that camp, the acquisition clearly isn't a bad thing; in fact, the licensing model may help them with the transition CA must manage in its provisioning product line. On the other hand, however, there are customers who simply don't like CA's product licensing model, and don't want to buy products from CA. For the Netegrity customers in that camp, then, the acquisition was not good news. And provisioning is the area in which such customers are most likely to pull back from a commitment to the Netegrity product line due to the CA acquisition, at least in the short term. We've already talked to a few customers who have decided to halt a planned IdentityMinder provisioning deployment because they aren't CA customers now, and they don't want to open the door to site licensing discussions any more than they have to. The Long Term View If you're a Netegrity customer, regardless of which camp you're in, there's absolutely no need to panic and rip out SiteMinder. Like all mature products, SiteMinder has product-specific features and functions. If you're using those functions in your applications, ripping out SiteMinder will cause substantial pain for little or no gain. And CA will maintain that product. As I said earlier, CA is serious about its intentions to be a major identity management player. And if you're deeply committed to SiteMinder, then it's a good idea to hear what they have to say before you make any rash decisions. It is wise, however, to watch the developments around the provisioning product line carefully, and to make sure you're comfortable with their plans. In the long term, CA's acquision of Netegrity is simply another sign of a maturing market. There are now fewer vendors to choose from, but there will not be just one. While some customers will find CA's identity management suite and product licensing model to their liking, some will not. Some of Netegrity's existing customers, especially in the provisioning space, will likely defect as a result. Over the long term, some SiteMinder customers will probably defect as the identity management suites sort themselves out. But CA has a strong identity management team, one that intends to be a major player in the market for the long term. So, barring some unexpected legal consequence, CA should be able to make a success of the Netegrity acquisition, with the customers that like its product licensing model. The presence of several strong players, each with its own advantages and disadvantages, is a clear sign of a strong market, one capable of serving many different customer needs. And that's good for customers. (Note: In the "credit where credit's due department, much of this posting came from a conversation Mike Neuenschwander and I had about the acquisition, and so many of his good ideas ended up in the posting. Thanks Mike.) [Jamie Lewis] 10:43:43 PM    comment []