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.
