Parallax : Calculating Technology's Future: 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.

Comments

Oh my god!!! This is so very incredibly amazing.
Couldn’t thought that something as interesting as this was still in the oblivion.
Your piece of work is just astounding.

Posted by: priligy | October 06, 2011 at 04:58 AM

I just logged in your blog. I don’t know how to express this to you.
I must say I am lucky that I find you so early. Many of my friends are looking for this info long for long time.
Let it be a secret to them for a while but they will find it from my bookmark account as I have already bookmarked it.
Thanks dude…thank you very much.

Posted by: australian rx | May 11, 2011 at 05:17 AM

Go matters to me. It matters to the dozens of Go programmers I've met personally, and the countless more out there who believe Go has something new to offer and are writing Go code right now.

Posted by: Buy flagyl | April 26, 2011 at 03:54 AM

It is very usefull information for every one..
http://www.gemsdrugstore.com/

Posted by: Account Deleted | December 09, 2010 at 05:25 AM

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.

Posted by: ugg sale | November 26, 2010 at 12:27 AM