SAP Netweaver
Should SAP bet
its future growth on a grab-bag of products
connected by a catchy name?
Netweaver Overview
Netweaver is a group of infrastructure products that SAP plans
to make the foundation of a modernized application and business
architecture. The R/3 and New Directions suites were written for
a client-server architecture, but adapted for the web. Netweaver
will make the suites fully web capable and able to implement business
processes that would have been hard to support with the old architecture.
The products that make up
Netweaver are all familiar technologies.
They include a portal, an application server, a web server,
a data warehouse, and an integration platform. These
are each roughly
comparable to and meant to be competitive with
other products that do the same thing, from Apache
(web server) to Business Objects to
Epicentric to Tibco.
Netweaver is unique in two respects. First, it is a "stack" of
applications: the standard technologies are more or less integrated
with each other, and they use each other's capabilities, more or
less. Second, the individual products tend to be much stronger than
the average bear in areas that are of particular concern to large
corporations or SAP customers. The portal, just for example, has
more knowledge management and integration capabilities than most
portals and can support quite robust role-based security. The EAI
system has a data translation manager that is far more powerful
than what is generally available with EAI tools, and it can double
as an ETL tool for business intelligence.
Should we be excited? Modernization is usually a somewhat arid goal,
and there is little technical pizzazz to what is being done.
But it is clearly an important step for SAP.
In particular, Netweaver
is designed to:
- Help make good on the old SAP promise
of corporate integration
- Support the new mySAP applications, such as CRM and SRM, with
a modern interface and better, more modern access to information
sources that these applications typically need to integrate with.
- Support new kinds of applications, called
xApps, or "packaged composite applications."
As I pointed out in the last Short Take, the
stack
is also designed to justify a quite new
approach to customer revenue extraction, namely
getting people to pay for upgrades based on
the fact that
the upgrade is running on a "new" architecture.
The amount of revenue uptake is supposed to be substantial. Two-thirds
of the SAP customer base has yet to upgrade to mySAP.com (an expensive
proposition), and Netweaver is supposed to be the key driver that
pushes them to upgrade.
For SAP's sake, therefore, we had better be
excited. If Netweaver is just a pedestrian
collection of web technologies, how is
it supposed to confer the substantial
benefits that would not only justify the price of
a mySAP.com license, but also get people so excited
that it accelerates the upgrade cycle?
We SAP observers therefore can't just evaluate Netweaver the way
we would evaluate a new piece of functionality, like a new asset
management package. The stakes for Netweaver are too high. We have
to ask whether Netweaver assures the long-term growth of SAP. Is
there enough in Netweaver to justify a rapid drive to upgrade? Once
people upgrade, will Netweaver be a platform for innovation?
The Netweaver Enterprise
The somewhat bald tone of the previous
paragraphs might suggest that my answers are "No!!!"
and "No!!!!". Not at all.
But I do think that a skeptical tone is warranted.
You see, the whole idea of Netweaver is at
bottom quite
peculiar. Every component of Netweaver
is, as I've said, a familiar product for
which there is an established market. SAP's
offering in each of these markets comes
rather late in the product cycle. The offering, in
each case,
is unlikely to dominate the market, because
it is of little interest to non-SAP customers.
So just how do you generate urgency from a
warmed-over mix of technology products?
What is going to push people to
invest as much again as they already have (at least
in some cases) in order to get these technologies?
It's probably useful to remember that other ERP companies also
have had to provide products that do most of what Netweaver does.
You can't run a modern, 118% Internet application without them.
But those companies haven't treated their infrastructure products
with anywhere near the same bravura.
PeopleSoft, for instance, is not a company
that is shy about broadcasting even quite incremental
advances. They have had an
integration framework, a portal, and even an analytics
tool for some time. But these are not being sold
as new-infrastructure products that justify/require
new licensing schemes. They
are available for sale at quite moderate prices.
True,
PeopleSoft doesn't make its own web server;
it supports BEA or Websphere, but then again, does
one need one's own web server?
Even if there is something palpably new
and attractive here, one still has to be
skeptical about the time line.
Netweaver is still pretty new. Some of the
products, like the MDM (master data
manager), are new this year and have yet to be
tested in high-volume conditions. Some don't
even seem to exist, like many of the announced
x-Apps. And the products that are to be based on
Netweaver, like mySAP ERP, are still in pre-production;
the target now is 1st Quarter (maybe January) 2004 for
general availability.
"Knock, Knock."
"Who's there?
"SAP Marketing"
"Who?"
"Yes, we're everywhere. And we have something
to say."
"OK, what is it?"
"You're missing two things that
really make a difference.
- "First, the Netweaver stack runs
SAP applications in native mode. Netweaver
allows you to display web pages, write and
run integration messages, or create custom
Java applications within the new SAP
environment. Before Netweaver, to take just
one example,
if you wanted to create and run a web page
for customers, you would have to use a special
engine, the ITS or Internet Transaction Server,
which ran on its own machine and managed the
interface between the web and R/3.
- "The second is that the Netweaver
architecture is "services based."
This means that, in theory, any object or application
run within this infrastructure can be called
by any another object or application relatively simply.
It also means that it, too, can easily call on
external web services).
Theoretically, this capability should not only
make R/3 more open, but also
make it far easier for
both SAP and people outside SAP to develop innovations,
because they don't have to
rebuild the services that are already available.
"It is hard even for us to exaggerate the importance
of this last point. Theoretically, the services
architecture enables a new kind of corporate application
that (it appears only SAP will support. This
new kind of application, which we call a Packaged
Composite Application will become the
standard way for corporations to solve automation problems
that had been heretofore completely intractable.
"And, when PCAs come into wide use, our support for services will
leave our competition in the dust. Oracle Applications or PeopleSoft
8 will be to mySAP what Lotus 1-2-3 was to Microsoft Excel."
OK. Thanks. You've had you're say. But since this is my
column, let me go on. I'll try to take each point in
turn. The first point is, if I understand it, that
there is a special value to this technology because
it runs natively. The second point is that PCAs are and
will be a transformative technology that only SAP will
support. Right?
Let's take the first point first. We can test it trying to
understand the value that this group of applications
provides when it runs native.
Do I Need Netweaver?
Let's say you're an SAP customer. What value are
you likely to see in Netweaver or in products that
require Netweaver?
There is a class of SAP customers that reason as follows: "We want
a Netweaver appplication (portal, integration framework, business
warehouse). We are committed to SAP technology. We'll buy the application
engine and pay the mySAP license fee, even if there's a premium.
In the long run, it's the right thing to do.
These are the customers who are already buying Netweaver
components, and I'm happy to report
that a number of them are successful.
Portal. At the recent,
Sapphire, SAP trotted out two portal customers, both of them with
impressive stories to tell. Sasol (South African fuels provider)
and Rohm & Haas (coatings) were using the portal for a combination
of knowledge management, information sharing, reporting from SAP,
and self-service access to SAP.
Theirs are typical bleeding edge projects, of course,
from companies that are culturally committed to
the activities that portals support and are
willing to devote significant resources to making
those activities work better.
(A useful
factoid to help you gauge how really
advanced they are: one of the things that
Rohm & Haas's portal does is help its users
get access to the over 300,000 pages
on their Intranet. A company I work with frequently,
about 1/10 Rohm & Haas' size,
has well fewer than 3000 pages on its Intranet.) For them,
the portal
is a kind of corporate angioplasty,
valuable because everything flows more smoothly
once it's done.
What about the mainstream (everybody with 10,000 to
100,000 pages on their Intranet)? Clearly, they're not
there yet. According to SAP's figures, only 150 portals
are now live and another 1700 delivered,
but not yet in production. To help those 1700 make good,
innovative use of their portals,there is a new and welcome
organization, the Netweaver Advisory Office. Total number
of employees (to support all of Netweaver): 25.
This is early onset, no question about it. We may
get an avalanche of enthusiasm for advanced
portal technology eventually--as opposed to
the applet or portlet windows that Oracle
and PeopleSoft support--but so far, the
snow
has only travelled a few feet.
For other areas of Netweaver, there are similar stories.
EAI/MDM. Shell has committed to using
the integration framework (and the new Master Data Manager) in order
to get control of its worldwide spend on spare parts, but no results
are expected until the end of year, and full worldwide use won't
start until the end of 2004. This again is an SAP showpiece customer,
not just some odd example I dug up to make acceptance seem slow.
Shell, moreover, is an unusual customer in that it is committed to the idea,
is devoting significant
internal resources to the project, and has not waited for the
potential value to be proven by other customer's experience. It's
a good first step for them. But how many will follow--and when?
Obviously, I think it's going to be slow. In this environment, most
companies just aren't getting religion about anything. But there's an
even more important question. Is the experience with a Netweaver
component driving these committed companies to other components
in the Netweaver platform?
Not that I can see.
Shell is not upgrading its 18-odd SAP systems any time soon, I don't
believe. And Sasol Synfuels uses a quite different architecture
to integrate its SAP system with its production monitoring
devices.
If the early adopters on a component are not moving toward
the platform, what of the rest of SAP customers. Advantages there
are, as Yoda might say, but reason to think that they're compelling.
There are too many barriers.
One company might want an SAP portal or an EAI platform, but already uses
another one. Another company might be busy on other strategic projects. Yet
another will upgrade to mySAP ERP eventually, but is dissuaded by
the hardware cost and the fact that two upgrades are necessary.
Certainly SAP salespeople will do their best to give these
things urgency, and certainly the infrastructure does offer
advantages. But compelling?
Hardware Savings. Let
me give you another example of how uncertain the value can appear
to be. SAP has long claimed that Netweaver will allow people to
consolidate their applications and hardware and that effectively,
the money being paid to SAP is really their fair share of the savings.
An example I always give is the ITS (Internet Transaction Server)
mentioned above.
The ITS runs on a separate
box, and it's technically a bit of a kluge. With Netweaver,
the need for the ITS disappears. The same server that
serves SAP pages serves the web pages that the ITS used
to serve. This saves on hardware and on maintenance, and
it encourages people to build inside the SAP environment
the customizations or new
applications that they might have simply built elsewhere.
But despite savings on things like the ITS,
it appears that the upgrade to mySAP ERP still ends up costing money
for most customers. According to SAP's own figures, a substantial
number of them will need more hardware in order to run Netweaver.
Long run, the savings may be there, but there is no short-run cash
advantage; indeed, quite the reverse.
Interface/mySAP ERP. Are there other potentially compelling benefits? Well, there's
a new interface. The new mySAP-based versions of the old applications
will have a new interface, which looks better (somewhat) and exploits
the capabilities of the web. (From what I can tell, it is portal-based.)
It will embed the Business Intelligence product as a reporting and
analytics tool.
But is the new interface compelling? Well, there are issues. First
of all, it's not finished yet, always kind of a problem. And some
of the press about it is a little puzzling. What does it mean when
an OLAP tool (BI) is pressed into service as a reporting tool? But
even if all these are addressed, it's hard to see that existing
customers are going to flock to it. Interface changes for an existing
customer can be as much a curse (new training required!) as a benefit.
No one upgrades just to get a new interface.
Web Application Server. There is also the web application
server. One of the reasons that this is piece is so long delayed
is that I wanted to get a good look at it myself. I saw a demo,
but SAP also has a 60-day trial version. I got it, but I couldn't
get it to install.
So what I can tell you is fragmentary. Most analysts worry about whether
SAP is trying to compete with .NET or Websphere with this product. SAP tries
to pooh-pooh this by showing you a Power Point diagram that has the web application server
connecting to .NET and Websphere with little Power Point arrows. What those
arrows mean, of course, is not exactly clear.
What I really wanted to find out from having my own copy of the
web application server was how SAP was going to handle sessions.
Session management, you see, is the horrible unsolved problem that
the web interface presents to programmers. With transaction systems,
users need to perform a number of connected tasks (like entering
in the data for a sales order). But with a web interface, people
can jump into and out of transactions. So you need some strategy
for maintaining the session behind the scenes.
The Java folks came up with something called Enterprise Java Beans
(EJBs) for doing this. EJBs require Java 2.0 and adherence to various
"standards." Neither has really caught on. Apparently the web application
server does indeed use EJBs (the right thing). But this limits
the ability of Websphere or .NET developers to work with the SAP
web application server, unless they use EJBs. A lot of them don't.
The Total Value Prop. So what does this all add up to for
the SAP customer who wants to upgrade? All in all, it looks to me
a lot like the xP upgrade. xP really is an improvement,
but just look at your friends and neighbors. How many of them are
willing to pay the extra money, buy the extra hardware, suffer through
the reconfiguration, etc., etc., to get that improvement?
Not that many. In fact, Microsoft could only overcome the mass
disinclination to upgrade by resorting to a licensing policy so
aggressive that it still reminds me of the window-washers in New
York City, a policy that turned it into one of the most-disliked
technology companies. SAP is by no means resorting to force (though
upgrade deadlines loom). But they're also not having to beat customers
away.
Eventually, SAP customers will shrug their
shoulders, move to the new platform, and find some real
benefits. But so far, it seems to me that the movement will
be at best slow and at worst sullen.
The Long Term: PCAs
After they upgrade, then what happens? Well, the hope is that the
services-based SAP architecture (see SAP marketing's point two above)
will enable a new class of applications called PCAs, or packaged
composite applications. PCAs will benefit SAP in two ways. One,
SAP will make PCAs (the x-Apps), which they will sell. Two, the
existence of PCAs that SAP supports will make the applications more
attractive.
What are PCAs? Well, they are small programs with specialized
application that are made possible by the fact that they can
use services from other applications very cheaply.
The paradigm application (the one SAP uses to illustrate
the point) is a web application that allows customers to change
any of the features of the car they've ordered on the web,
self-service, at up to the last
possible moment before it's made. They can do this because
the application(s) that are managing the building of the car are
open to this little web application, and so (presumably) are
the order management applications, the pricing applications,
the credit applications, the component ordering applications,
and all the other applications that are affected when
somebody decides they want a grey interior, rather than
a blue interior.
There is always an "End World Hunger" stage in the development
of any software application. That's when people at the company start thinking
up really cool things that people might do with the idea they've
come up with, without regard for the practicalities of the situation.
The best of these ideas often end up on Power Point slides, at
least until there have been some customers who test the idea
more pragmatically.
In SAP's case, they haven't just put this on a Power Point slide.
They've written (or sponsored) a book. Published by
O'Reilly & Associates, which gives them instant cachet
and credibility among computer professionals, Packaged
Composite Applications describes a world
where all these applications have appeared and work. It is
a good world, full of kind people, who raise organic vegetables.
But it is not a world, I think, that will ever exist or can exist.
You get to the "End World Hunger" stage by doing a lot of
hand-waving around real and intractable problems. Those of
you who really follow the integration space can recognize these
problems immediately. They include what Hasso Plattner used to
call the "semantic integration" problem, the session management
problem (the problem that Enterprise Java Beans were supposed to
solve, but haven't so far), and so on, and so on.
What these problems all add up to is quite simple. That web app
that lets you change the interior color on your car just isn't going
to work the way it's presented. Changing that interior color doesn't
just require access to all those systems; it requires control. Say
you want that grey interior and at the moment you order it, the
knobs for your radio are being colored to order at the radio supplier's
supplier. To change the color, the web app needs to be able either
to take your car off the schedule or else order the paint machine
to stand down, be cleaned, and be loaded with a new paint color.
Who would ever let such a thing happen? Who could build such an
app if they did? Not to mention the performance problems.
The book that describes how these web applications will work
is a sad piece of piffle. The author seems to be
an earnest and enthusiastic fellow who thanks Shai Agassi
and Peter Graf profusely for their guidance. But in my view, he
does not seem
to understand these problems or their import, so
he comes off looking meretricious.
Shai and Peter, in all
probability, think that this book is simply one more stage
in articulating a vision that they're deeply committed to. If I were
in their place, I might not be too worried
if there are a few ethereal spots.
But sitting where I sit, I worry that things like this
take SAP down the wrong road. What if a book like this
is given to every new SAP employee? Boy will they
be confused.
The problems that Shai is trying to address
are important ones.
I think a market for solutiions
to those problems will eventually emerge. I think you
address these
needs, however, by attacking them head on, not by building
a technology stack that would be useful if the market develops
in a certain way.
The real test of this market, though, is the x-Apps, not Netweaver.
So far, the verdict isn't in on the x-Apps, though, as I've said,
the slow progress and the ever-changing roster are nervous-making.
If, as is most probable, the good x-Apps do find a small market
among SAP customers, but no market at all in the non-SAP world,
it just won't matter whether SAP is services-based or not.
What Shai and Peter are trying to do is evangelize
the idea of PCAs so that an ecosystem of PCA developers eventually
emerges. That may happen, but I think the development will be far
slower than they seem to expect and the market for PCAs will be
far smaller. I don't think they will make a substantial difference
to SAP's revenue for a very long time. And in that time, the technology
market may shift again in ways that leave even Netweaver looking
antiquated.
Half a Thumb Up
It is a fairly obvious fact that ERP as we now know it is a maturing
technology. With maturing technologies comes commoditization first,
obsolescence second. When I first started in this business, at the
beginning of the ERP cycle, the big names were ASK and Dun & Bradstreet.
At the time, those companies were valued as growth companies. A more
accurate valuation would have assumed that there would be an end to
the useful life of their technology and that the end was relatively near.
If you look at Netweaver as a way of infusing new life into an
aging SAP technology, it makes some sense. It's a good conception;
the components are good; the commitment by SAP is exemplary. The
value to the customer over the long run will be significant. And
in all probability, it's something SAP just has to do.
From this point of view, SAP is once again demonstrating market leadership.
Are Oracle or PeopleSoft figuring out ways of keeping their underlying
technology fresh? Not at all. Larry has been going around for the last two years
saying that if he started today, he'd be in biotech.
But from this point of view, Netweaver is mostly just a cost, like the
cost an upscale hotel runs to renovate its rooms every few years. A necessary
cost. An investment. But finally, a drag on earnings, not a multiplier of
earnings.
SAP, though, wants it both ways. They don't want Netweaver to be a cost. They
want it to be something that accelerates SAP's growth. And thus far, I don't see it.
I don't feel the tug personally. I don't get the value proposition that SAP claims.
And, even though some of the customer experiences so far are very promising indeed,
they don't look to be the sort of thing that will be rapidly adopted by the rest
of the cusotmer base.
We'll know more when mySAP ERP comes out, of course, and we'll
know more when or if the current pessimism about business applications
comes to the end of its natural life. I am waiting.
To see other recent Short
Takes, click for a listing.
|
