Parallax : Calculating Technology's Future

Why Enterprise Software is Not Dead

This is part 1 of a multi-part series on the virtualization revolutions no one is really talking about. If you enjoy my longer blarticles, make a cup of coffee; you won't be disappointed by this one.

And They Wonder Why They Go Bankrupt

Every once and a while you get a pretty good glimpse why certain airlines seem like they file Chapter 11 more than they file 10-K's. Here's a great one from today. I was trying to book a one way from from SFO to BOS on January 11th. I accidentally asked for a round trip on Expedia the first time I did my search. Realizing my mistake I went back and did the exact same route (SFO to BOS), conditions (non-stop) and date (Jan 11th, 2008 outbound) but only one way. Guess what, the plane ticket was substantively MORE for a one way. I can understand it being substantively more than 1/2 a complete roundtrip but more than the total roundtrip? I seriously wish Expedia would let me book a double or triple round trip fare. I am pretty sure I could get this puppy down to a buck or two using that pricing logic. I even took screen shots lest you skeptics not believe me. Screen shots taken within 10 seconds of each other.

One way (above) - $792.00.

Roundtrip - $628.00 (above).

If anyone actually understands this pricing logic from an airline perspective I would absolutely like some education on it (leave a comment please).

2008 (well at least 364 days of it) Predictions

I decided to gain a slight statistical advantage over my other Enterprise Irregular bloggers by hedging a few days into the New Year to publish my 2008 predictions. Fortunately (and to many chagrins, I am sure), waiting a mere two days has revalidated the premise of one of my predictions: 100 dollars a barrel anyone? Its gonna be a year to remember.

As a side note, and somewhat true to form, I have a number of posts related to these topics in the workshop, sitting on the easel, one coat of paint away from publishing. I would promise to try and get some regular pace to this mess in 2008 but why make a resolution you’re bound to break (I have not gone to gym yet either folks).

Lastly – I apologize that so many of these things are interconnected – I can’t help it as we’re in a major phase shift right now – a sort of tech will follow the dollars will follow the tech kind of Mobius strip.

Newmerix Crosses the Chasm

When I first started Newmerix in 2002, I had a few initial premises for why the business could be very large and a would end up being a "must have" and not just a "nice to have":

• #1 - Packaged applications were not going away anytime soon and, in fact, would become the central
  platform for IT because of their back office nature (as opposed to web sites or Exchange infrastructure).
• #2 - While customers who bought PeopleSoft, Oracle EBS, SAP, etc.. thought they were moving away from custom development, they were in fact just exchanging traditional custom development for a new kind of customization development on those platforms.
• #3 - Packaged applications, while different, had all evolved to have the same basic architecture; one based on metadata and the classic MVC design model. As a class they were more similar than they were different.
• #4 - Managing a packaged application was a change-centric activity while traditional development was a build centric activity.

There are clear examples of these items coming true (#1 - NetWeaver/Fusion/Dynamics, #2 - the patch nightmare of owning a packaged application, #3 - PeopleTools/ABAP Workbench/Oracle Forms and OAF, #4 - SOX compliance , patch and customization management, and ITIL). That said, the subtlety (especially built into #2 above) was that Newmerix could build a business (and product) in stages, where each successive expansion became cheaper and easier to build than the prior stage, while the overall value of what we were building would grow non-linearly to the customer.

Today we announced our complete suite of products for the SAP and Oracle EBS platforms. Not only am I proud of the amazing engineering, sales and field work that has gone into getting us here, when I look at the milestone timeline of the business, it confirms much of this subtle original premise. To business school aficionados this will strike you as a textbook case study in “Crossing the Chasm”. Here's the quick timeline to illustrate our growing expansion momentum:

2002

• Business started

2003

• PeopleSoft testing product (Automate!Test for PeopleSoft) developed and first version GA

2004

• Centralized change request management product (Automate!Control) developed and GA

2005

• PeopleSoft change management product (Automate!Change for PeopleSoft) developed and first version GA

2006

• Acquired Object Manager which became Automate!Change for SAP
• Extended Automate!Control to integrate with Automate!Change for SAP
• Extended Automate!Control to integrate with Automate!Test for PeopleSoft
• Added Business Process Documentation to Automate!Test for PeopleSoft

2007

• Extended Automate!Control to integrate with both Automate!Change for SAP and      Automate!Change for PeopleSoft for customers who owned both and wanted to centrally manage them
• Launched Automate!Test for SAP including Business Process Documentation
• Developed and launched Automate!Change for Oracle
• Developed and launched Automate!Test for Oracle including Business Process Documentation

2008

• (coming soon) Extending Automate!Control to integrate with SAP, PeopleSoft and EBS in one central location for cross-ISV change and lifecycle management
• (coming soon) Extending Automate!Control to integrate with all the Automate!Test products for one central location to manage all business process testing
• (and much more…)

Note that while the size of our engineer team has only grown a little bit over this time, we’ve been able to launch complete new products and ISVs built on the foundation of our other products in a fraction of the time our first versions took to build. The side effect of this (taking Automate!Change for EBS as the example) is that the first versions of our new products are really the third generation of our existing products and thus are extremely feature rich.

From the customers perspective, the more we deliver in our roadmap, the more they have been able to integrate all activities across the packaged application change lifecycle into one location (Automate!Control). In addition, many (I’d say 50%) of the customers we serve own more than one packaged application due to history, acquisitions, etc.. Being able to come to one vendor and buy the same product set for all your ISV management needs is incredibly valuable. We’ve already closed a number of multi-ISV customers and we’re seeing our pipeline fill up with people who have SAP and Oracle, PeopleSoft and EBS, and even all three.

We are now the only company in the world to support the complete lifecycle of change in PeopleSoft, Oracle EBS, and SAP, let alone integrate them all together in case you have more than one. That's a pretty amazing statement given this was nothing but a PowerPoint less than 5 years ago.

It’s exciting times around the office. Congratulations to the whole team at Newmerix who have worked very hard for a long time to get us here!

Click here for the complete Newmerix Automate!SAP and Automate!Oracle press release.

Do Programming Languages Matter Anymore

Not to long ago, SAP did something they had omitted to do for the last, say, 30 years or so. They appointed a CTO (Chief Technology Officer). Having been a CTO most of my professional life, I was pretty excited by this prospect and looked forward to eventually meeting the person who could break the 30 years of non-CTO-having SAP tradition. A few weeks ago at SAP TechEd, I had the privilege of finally talking with SAP’s new CTO, Vishal Sikka.

I was very intrigued to meet Vishal because when people talk about him his name is usually clustered up in the sentence pretty close to all those adjectives that most people would call compliments. Also, Vishal is not only the first CTO of SAP, but the most visible promotion of a technical figure after the departure of Shai Agassi (who I have written about numerous times). Like it or not, Vishal can not escape comparison with his closest predecessor and this leaves him some pretty big shoes to fill and a long way to run in them.

As a side note, over the last 10 years I have taken pride in crafting the role of the business technologist or as I sometimes refer to it, “external” CTO. This role is really a fusion of marketing and product management with a strong (some would say dangerous) amount of participation in engineering. And when Vishal starting seamlessly talking up the stack to business and down the stack to technology, I knew he was cut from this cloth too. 

What makes Vishal a very capable successor to Shai it that his logic is almost always coherent as he moves conversationally between the layers of the stack. He clearly spends a lot of time talking to the market, customers, and his internal engineering teams to craft the right story continuum. He is also actually able (or willing) to go the opposite direction in the stack too (in a way that Shai was not or did not want to) and actually dig deep into the technology with you. As the true litmus test, James Governor, my favorite new Enterprise Irregular press room curmudgeon, tried for 45 minutes to stump him with a notpron of technical TLAs, and only once had to step in and offer him a clue. The most fun and most challenging thing about talking to someone like this is that if you’re not listening closely, you can miss tons of tiny nuggets of wisdom or even full fledge projections into the future of SAP’s architecture (or architectures and now they have about 4 different platforms).

Okay, all CTO to CTO gushing aside, I was actually listening very carefully to what Vishal was saying in both the SAP TechEd executive press conference as well as our dedicated Enterprise Irregulars’ session. I have learned over time as a conference blogger that press rooms are not the place to spark debate or incite ideological riot. While it’s tempting to have the whole executive team on stage in front of the press, analysts, God (or your equivalent), and a few straight-to-YouTube cameras, you basically have to restrain yourself to opening salvos for the conversational battles you’d like to fight later. Sometimes you have time to pick up the topic and sometimes you move on. With this dynamic, there was one question that Vishal answered that I still am not sure I agree with and never got a chance to follow up on in depth. I especially listened to this specific answer because it was in response to a question from me. Here was my question: 

“What is the adoption curve of Java developers on the NetWeaver platform? How do you measure it and do you have any internal goals like 50% of new code development by 2010 will be in Java”.

My question stems from the fact that SAP’s new NetWeaver platform is a relatively new hybrid between Java and ABAP, SAP’s old proprietary language that has approximately 17 trillion lines of aggregated customer code out there in the field. While the use of Java is probably most prevalent today in SAP Portal and XI, SAP’s intergration framework, it is also slowly becoming a viable alternative for core SAP business logic customization. The opening salvo part of my question to Vishal was not really about the popularity of one language (ABAP) or another (Java), but about the real cost of retooling and retraining an SAP customer’s organization from an ABAP skill set to a Java skill set.

Just like mainframe COBOL programmers, ABAP programmers are still in business, hanging around making changes and modifications to SAP systems on a daily basis. Even though they are few and far between and quite expensive to hire, a SAP system simply can’t run without them. So if a SAP customer really wants to move towards the future of NetWeaver, not only do they have to adopt Java as a core development language along the way (and train everyone in the process), they need to consider the cost of upgrading (or abandoning) the existing legacy ABAP code base they have. This makes my analogy to COBOL even more ironic as many companies simply tossed out their COBOL code during the Y2K scare and moved over to SAP as the alternative instead. Now neither I nor SAP is recommending you dump your investment in ABAP – in fact their unique (as compared to Oracle’s Fusion) co-residency approach tells quite the opposite story. And here, with perhaps a better backdrop for you as to why I think my question is quite important, let’s pick back up on Vishal’s answer. 

Vishal basically said, “We don’t measure it [Java adoption] and we don’t care. We are not putting all of our eggs in the Java basket, that’s just what we’re offering for the time being.” And then the most interesting part, “Languages tend to have 10 year timelines - and then they are always outmoded by a new language. So in 10 years we won’t be talking about Java, we’ll be supporting something else.” If you step back and think about it, on the eve of asking a majority of the SAP customer base to embrace Java with open arms, saying in 10 years SAP won’t care (author’s choice of words) about Java anymore is a pretty interesting and ballsy statement. Again, these are paraphrases meant to capture the spirit of his answer (do not take them as verbatim quotes) - please keep reading for a bit more insight into what I think Vishal meant and why this is an important discussion.

The optimist in me hears Vishal’s answer and says, “Hurray!” Finally SAP is moving away from a proprietary-only framework (ABAP) towards a much more open language approach. Java is clearly the most open of the contemporary language choices and hopefully it’s just the first step in a longer string of language support. While this is good news, clearly it is going to take some time for SAP to fit another language comprehensively into their software stack.  

For example, SAP developers can only now, with CTS+ (which I think according to the new naming scheme is called NetWeaver 7.0 Stack 12), move both Java custom objects and ABAP objects at the same time as part of the a transport. With that said, many holes exist in SAP’s tools for the deployment and management of heterogeneous language environments. That’s why Newmerix is about to GA an extension to our very successful SAP change management suite to fill all of the existing holes that the ABAP/TMS/CTS tools and process have as well as all the new ones being introduced by moving Java around as well. To stay an optimist for a second here, while it may take a long time to do this, not locking yourself into another long term language choice is a strong decision.

That said, the pessimist in me says that I don’t believe Vishal’s implications for a second if you look at the realities of SAP’s history. Lets first verify that Vishal’s basic premise is correct, that languages, in general, emerge every decade or so. As a side note, I love Wikipedia. I just Googled “programming language timeline” and viola – everything I needed to know on a page called, surprise, “Timeline of Programming Languages”. I swear if I had to choose one, sometimes I’d take only Wikipedia over the whole internet!

Let’s start by looking at the emergence of some of the most notable and relevant business languages (e.g. code people build their own business applications with or code that is used to customize others’ business applications): 

• COBOL (1959)
• BASIC (1964)
• C (1972)
• SQL (1978)
• C++ (1983)
• ABAP (1983)
• Perl (1987)
• Visual Basic (1991)
• Java (1995)
• C# (2000)

While I am sure some will split hairs on minutia like the difference between when a language emerged and the notable year it attained mass adoption for use in enterprise software development, I think we’re actually looking at a shorter timeline than Vishal’s 10 year horizon. Across most data points it looks like 5-7 years is the average time between major advances in the field. This actually does not surprise me because, in general, IT cycles are almost always around 7 years long. What did surprise me was the consistency of this pace for almost 60 years now! And what is interesting is that the closest data point to Vishal’s estimate is the time between ABAP’s adoption and the start of Java. 

Whether it be 5, 7, or 10 years, here is my problem with Vishal’s logic and the implications he was making (that SAP doesn’t care about the adoption of one language or another as they all fade away). While programming languages come into fashion and then are inevitably replaced by newer and sexier ones, code bases are not subjected to the same popularity contest. In fact, it’s quite the contrary. The long tail of programming languages is actually not the classic Chris Anderson/Zipf power distribution graph. It’s actually quite the opposite with the total lines of code accumulating over time more quickly than they are being replaced. You can argue that new languages are adopted much faster and there are more programmers, but this, I would say simply increases the slope of the lead line and not the total accumulation.

Take for example various reports that triangulate that between 200 and 500 Billion (yes, that’s a “B”) lines of COBOL code are still running in production today [1, 2, 3]. As I mentioned above, the Y2K scare/phenomenon did a painful job of reminding us how true this was. Was the main surprise that 2 digits could bring down the computing world as we know it? No, it was how much frigging COBOL code was actually running the financial and transactive underbelly of the United States and the globe’s economy. And this long tail of computing is hard to fix because there is an inverse relationship between the number of knowledgeable programmers in a language and how many years ago it happened to emerge. In 1997, companies with massive mainframes were finding it pretty hard to find a COBOL programmer who, to Vishal’s point, right around 1972 had not picked up K&R and moved on to greener programming pastures.

Now let’s take the second and probably more poignant example of the long half life of a code base. According to our contributing friends at Wikipedia, ABAP was introduced in 1983. Counting on my fingers and toes (and yes, running out), its now about 24 years old. One more year and its going to be SAP and ABAPs silver anniversary. I for one will send them a lovely chaffing dish. But the real question is after so many fantastic years together, how many lines of ABAP code are running around in the customer base. Well, while I was being glib about 17 trillion lines before, let’s do a one of those McKinsey-interview-question quick calculations (like “How many haircuts are given each year in the US?”). If there are 35,000 SAP customers, and about 2.3 production instances per customer (I got this number a couple of years ago from SAP), that’s about 80,000 instances. Let’s ignore that each landscape has multiple systems and just focus on the production system. Let’s estimate that, on average, an SAP customer has owned SAP for 7 years (R/3 4.0 was release in 1998). Let’s also estimate that 100,000 net new lines of ABAP code are written per year per customer. So doing the math we get: 

80,000 x 7 x 100,000 = 56 Billion lines of SAP code

Okay – even if I am effectively off by an order of magnitude on net new code generated per year, that’s still 5.6 Billion lines of code in the customer base. Holy legacy code base, Batman! And that does not include the millions of lines of ABAP code that SAP has written, deploys, and still writes into their vanilla code base. This shipped code still gets poured over, integrated with (ABAP APIs) and modified by customers. My basic point here is that the 10 year cycle is not a flush and restart cycle as Vishal would sort of imply, it’s a compounding cycle that only gets more expensive to maintain over time. 

So, you might be sitting there asking yourself, “So what?” Well the problem is that you have a mismatch between the inherent desire of programmers to use what is new and the need to integrate the new in with the old. Over time this gap widens to a point where, as we saw in 1997, people literally make $100M reinvestments to start from scratch. How does SAP and their customers avoid this? Well, I’ll offer my readers the same idea that I offered Vishal. And lest anyone think I am picking on just SAP for this problem, our friends in Redwood Shores are facing the exact same challenge with Fusion. That said, my solution is one that either SAP or Oravcle could employ, but for various reasons you’ll see, SAP is much more likely to consider.

Let me first broaden the conversation slightly. I think there are realistically three pieces of the puzzle that are important when introducing a new language into an architecture like NetWeaver: tools, training and transports. The later (for those unfamiliar with SAPese) really means the process of deploying changes to the actual production infrastructure of the code base. In more general terms, how does your Java code get from development to production while taking a scenic drive through testingville?  

My proposal to Vishal actually covers all three of these with one fell swoop. It’s simple; integrate a CLR runtime engine native in the application server (or at least have a three legged stool of ABAP, Java, and CLR-based runtime). For those unfamiliar with the CLR (common language runtime), this is just Microsoft’s .NET equivalent of a Java virtual machine. When you program something in C# (or any other .NET language – more on this in a second), it gets compiled down into the rough equivalent of byte code (called IL – intermediate language in Microsoft terms). The IL is actually what the CLR then runs.

On another side note, I used to have this argument with Shai all the time. He’d say, “We do support .NET applications.” But what he really meant was you can run a parallel Microsoft application server and build services in .NET languages and connect them all with SAP through BPEL. While that’s architecturally a technical solution, the whole point here with NetWeaver is to drive all of your development (SAP and custom built apps) onto one platform over time. That’s the composite application strategy and stack that SAP and Oracle are currently battling for ownership of in the Global 5000 IT department. If you have any doubt, note Oracle’s current bid for BEA as indication that owning the application server is a key part of the strategy.

So why add yet another programming language execution engine to the stack? Well it has to do with the difference between Microsoft’s approach to .NET and Sun’s original approach to Java. Java came first, pioneering a renewed concept of the virtual machine and cross-platform independence. They built in network security, generic user interface harnesses across platforms, etc.. Part of this was visionary brilliance, part of it was because Sun original though Java would live primarily in the browser, and also because Sun was not dominant in owning the OS and thus the interface around it (e.g. Windows). When Microsoft’s showed up, they took all the best things from Java and added some game changing pieces of the puzzle. The main invention (in my humble opinion) with the CLR is not OS neutrality, its language neutrality. Any.NET programming language gets compiled down to the same IL and can be run by the same CLR. Rather than move neutrality to the end point (running the app) they moved it backwards to the starting point (writing the app). That means programmers using Visual Basic.NET and C# can co-mingle their code bases and use the right programming language for the right task.  

Let’s face it - part of why languages evolve over time is that the underlying tasks people are trying to accomplish change. Relational databases drove the need for SQL, the massive number of UNIX platforms in the 80s and 90s created the need for OS portability (which is why ANSI C emerged), code reuse brought C++ and modularity, and the list goes on. One language simply does not fit them all. More contemporarily, check out the emergence of Flash in the browser and now on the desktop with AIR (another post on this coming soon) showing the need for a language designed for lightweight mixed media presentation. Microsoft realized this fact when they were designing .NET I suspect because of their long relationship with developers.

Unlike Java, Microsoft has aggressively supported language designers in porting their design time language syntaxes to runtime CLR compatibility. Now there are over 40 languages supported in the .NET world. When a new language comes out, whatever that will be and for whatever reason, a .NET version of it could be made available and no infrastructure change would be needed to run it.

Let’s review our three legs of the language platform stool again. First is training. Well there are two sides to this coin. While I agree with Vishal that as time and necessity marches on, new languages will emerge, we cannot discount that people (developers and others) need to be trained. What’s beautiful about the language-neutral CLR approach is that it allows companies to harness all the existing resources in their organization that might know any .NET supported language to come over and work on the SAP system. If you have an army of Visual Basic form designers and you need some work done on the SAP portal, let them come over, use VisualBasic.NET (which is only a small learning curve from classic VB) and start developing interfaces and code for your SAP team. 

The second item is tools. While Microsoft has done wonders in supporting many languages in their Team Studio environment, the bigger problem is being solved by the open source community. Whether Borland likes it or not, unless you’re doing solely Microsoft development, everyone is s moving to Eclipse as the standard framework for IDE based code creation. While people tend to think of this as a Java programmers environment, it is quickly outstripping those perceptive chains and becoming a world class environment for developing in most languages. For example, C# plugins exists and it would not surprise me if an ABAP plugin was in the works somewhere.

The third item, transports, is simple. If you have the CLR deployed (and you keep it up to date with the right .NET framework upgrades), then you can run whatever language comes along. As long as the framework upgrades are backwards compatible (which they generally have been to date through three releases) - 5 year cycles, 10 year cycles, or whatever, it doesn’t matter at all. In this world, the older code bases which seem never to die do not become deprecated and the new code base can be supported on the same system. It’s a win-win all around. 

I think the lynch pin to the potential success of my proposal to Vishal is based on the fact that SAP seems to be getting very cozy with Microsoft right now. With their continued work on Duet and the new OBA integrations with SAP, this seems like the right time and the right partner to solve a very long term problem they have. Let’s face it, Microsoft needs this as much as SAP. They are slowly loosing their dominance in terms of enterprise software development. Less code means fewer developers, and as I have written about repeatedly, the long term battle always has been and always will be about owning the hearts and minds of developers. While I think Vishal usually gets it spot on, perhaps he will realize the blessing and the curse of his programming language timeline theory and put a framework, not a language, into the stack that will stand the test of time.

Adsonomies

(Or why Yahoo needs to put me on retainer, Part Duex)

I will caveat this whole post by taking my ego off the table as my opening ante. For all I know, the good folks at Yahoo are already working on this, have built it, are ready to go to beta, are projecting record revenue, etc.. With that said, I have not heard about it yet so lets continue.

Some time ago I wrote a post about Yahoo’s potential (perhaps unintentional) brilliance in buying del.icio.us You can read the whole post here, but the simple summary is a follows. Del.icio.us is now widely regarded as an amazing source of classification of web pages. Using the concept of folksonomies (user generated taxonomies – or classifications), del.icio.us has instigated the largest open source project on the net: categorizing the content of web pages. It’s sort of a reverse Wikipedia - to some extent taking advantage of the fact that a lot of content is about more than one thing or is specific angle on something (which Wikipedia by definition is not). When I want to learn about SAP transports, I don’t go to Wikipedia and search on “SAP transport”, I go to del.icio.us and see who has tagged web pages with “SAP” and “transports”. I can find some pretty good resources specifically when I am looking for targeted concepts. If you run this thought out a little you’ll see that Yahoo, perhaps without knowing it, bought (for a mere 40MM dollars) a whole new way of letting people search the vast expanse of the web. Rather than Google’s reference based page rank or the more common yet complicated lexical analysis done by most search sites (e.g. figuring out what a page is about by looking the content in it), Yahoo could simply match del.icio.us tags (classification) to search terms and introduce a whole new concept of searching. Granted you can do this yourself by going to del.icio.us and typing in search terms, but my point in that post was for Yahoo to integrate this information directly into search for the 90% of people that don’t yet know what del.icio.us is but still want to find party pictures of Paris Hilton’s private bits. In doing this, they could possibly siphon off 5-10% of the searches from Google by getting people to think of tag searching before they think of Googling something. Cracking idea Robertson!

Today I had a new epiphany around this concept. It all started a couple of days ago when I became interim VP or Marketing for Newmerix. This in and of itself is a long story but suffice to say I am now actually responsible for rocking our marketing out and not just talking about rocking it out. One of the first places I have focused my time is on what I call “self-service marketing”. Its all the activities that you set up and they just sort of run for you, letting people interested in PeopleSoft and SAP change management opt into our lead generation process. You could include our web site (passive marketing) as well as search engine optimization and marketing. And since I met Dennis Yu, I’m totally obsessed with the later.

Dennis was introduced to me by David Cohen (of Colorado Tech Stars and other claims to fame). Dennis used to run Yahoo’s Internet Marketing program. That means that Dennis got to play with Google AdWords and Yahoo Search Marketing with a multi-million dollar budget and Yahoo’s home page at his disposal. Nice toys! Let’s just say that Dennis has forgotten more about keyword and content network marketing than most people learn in a lifetime. And, to our Colorado entrepreneurial community’s benefit he also decided to moved here to Boulder recently. With a little help from Dennis I was able to increase our click through rate by 20x in 2 days without spending one additional dime.

One of the first things that Dennis recommended was that we shift our dollars heavily towards keyword based impressions and less towards the content network. For those that don’t know much about SEM (like me!) there are basically two places you can stick an ad. The most familiar would be on Google’s home page. When you type in “SAP transport management” you should see on the top or side a little text based ad from Newmerix enticing you to come to our site, say hello, download a whitepaper and in the process opt into our marketing program (standard tech startup “give us your info and we’ll give you some content of value”). There’s no real magic here other than knowing how to turn the nobs and experiment and run through all the permutations of campaigns, ad groups, keywords, bidding, ad variations, rotations, etc.. (piece of cake huh). For those that are obsessed with day trading, the high is sort of similar. Place some bets, watch the results, harvest, adjust. It’s very fulfilling as you get almost instantaneous feedback from Google (Yahoo is PAINFULLY slow to return results to you). The second type of impressions that you can place are those on what is referred to as the “content network”. Ever read a blog about tennis and seen an ad for “Wilson Tennis Rackets” on the side of the blog. This is content network advertising. Google matches the nature of the page (content) with the nature of your ad (content) and decides where to stick them. As this is a less exact science the click through rates are massively different (if you expect at least a 1% click through on a minimally well managed keyword campaign you can expect maybe 0.1% click through on the content network). That said, I am discovering that the content network actually has some value. As a side note, ads on keyword impressions that perform poorly might actually perform really well on the content network. A good example is an ad impression we have entitled “PeopleSoft Change Management”. It gets almost no click through on keyword impressions (even when someone types “PeopleSoft change management” directly into Google) but for some reason performs really well on the content network. This is fundamentally why SEM is addictive – it’s a constant minute by minute game and optimization.

Okay – lets get back to Yahoo. Well, let me start by saying that the results you get on Google and Yahoo can be vastly different. Keep in mind that I am marketing for PeopleSoft and SAP change management and not ring tones, so this comment will clearly not apply across the board. This has to do with the type of user that searches each site. Yahoo seems to be heavily consumer focused (ring tones) and Google captures the business audience much better. My results are something like 50x better on Google (keyword and content network) with exactly the same campaigns, ad groups, keywords, and ad variations. In other words, Google gets 5-10x more of my SEM budget on a daily basis than Yahoo does simply because the users are different.

That said, imagine if for a second there was a better way to KNOW (not guess) what a general web page was about (not a keyword search but something on the content network). Instead of matching lexical concepts between ads and web page content, if I could match some form of content network keywords to place my impressions I am sure that I could get a better click through rate than Google’s 0.1%. Well, and it should be no surprise where I am going with this, Yahoo actually has these keywords. They are called del.icio.us tags. The del.icio.us users have already done the work for Yahoo. If there is a web page about SAP transports, chances are some del.icio.us user has tagged it that way. Well imagine if that web page is also part of Yahoo’s content network (e.g. serves Yahoo ads up on that page). Why not let me do keyword matches against del.icio.us tags. So Yahoo, without any more fanfare I give you my best idea of the day – the third type of campaign network – the tag network (or adsonomy). Set it up just like a keyword campaign but cross reference del.icio.us tags with content partners and search keywords and viola. I would bet that the results would at least approach the half way mark between a keyword based click through rate and a content network click through rate. And, it might actually give Yahoo a leg up on Google (or at least an even footing) which it looks like they seriously need.

That’s now two game changing ideas for Yahoo - all for free. The third is gonna cost them.