Chasa Ursa Major

CH-7550 Scuol
Switzerland

SAP Business One

Simple, Affordable,
Productive ERP for SMBs?

White Paper
Version 1.0
May 2006
Helmuth Gmbel - Managing Partner
Strategy Partners International
Chasa Ursa Major
CH-7550 Scuol
[email protected]

Text and illustrations were compiled with utmost care. However, the author will not take
responsibility or be held liable for any possible remaining incorrect information and the resulting
consequences thereof. Readers of this document are urged to reevaluate all statements against their
own particular situation as circumstances may vary considerably.
This piece of work is protected through copyright. All rights concerning the translation, reprinting,
the use of illustrations, radio broadcasting, the reproduction through photographic or any other
means, as well the storage in data processing facilities, even if only excerpts are utilized, are
therefore reserved.
SAP, R/3, mySAP, Business One, SAP All in One and NetWeaver are brands and trademarks of
SAP. Microsoft Business Solutions is a brand of Microsoft.
All other product and company names mentioned herein are trademarks of their respective owners.

Strategy Partners International

Table of Contents

Why You Need to Read This..........................................................................................1

Expectations....................................................................................................................2
SAP Business One The Architecture ...........................................................................4
User Friendliness ............................................................................................................7
Functionality...................................................................................................................8
Integration.....................................................................................................................12
Longevity......................................................................................................................16
Quality ..........................................................................................................................17
Investment Protection ...................................................................................................17
Upgrade Path ................................................................................................................18
Bottom Line..................................................................................................................20
Table of Figures............................................................................................................22
Abbreviations................................................................................................................23

STRATEGY PARTNERS INTERNATIONAL COPYRIGHT 2006

Strategy Partners International

Why You Need to Read This

This paper is intended to supply CEOs and CIOs with the information needed to
critically assess their future investments in SAP Business One.
SAP has been successful with its high end enterprise application software.
However, SAP has been trying to replicate this success in the lower end ERP
market for more than 10 years with mixed achievement. The first attempts all
focused on solving this task by repackaging the R/3 suite of products. The results,
today visible in the form of mySAP All-in-One, were less than convincing: ease of
use and simplicity were not more than a thin layer of marketing veneer. As soon as
customers were demanding more sophisticated functions, they lapsed back to the
complex enterprise product they had been trying to avoid.
Conscious of this apparent impossibility to scale the enterprise product to the
needs of SMBs, SAP sought a much different solution that was bred from very
different architectural stock. To a large extent, this move was motivated by
Microsofts ability to successfully deploy its Navision (now Micorsoft
Dynamics NAV) solution in enterprises using SAP R/3 as a corporate hub. If
Microsoft was successful with a different architecture, why should SAP not try
diverting from its own architectural paradigm? With NetWeaver promising almost
unlimited and universal integration possibilities and R/3 (also known as mySAP)
needing a remake anyway why not leave the trodden paths and try something
refreshingly new?
In this paper, we analyze the main architecture of Business One, the consequences
for key features such as scalability and adaptability for users and partners, the
future of the product, and the background that future developments will occur
against. This background is formed mainly by SAP having to redo its whole
product set in the next five years. SAP needs to reinvent its business and address
its two most critical issues: 1) free customers from their current cost and
complexity and 2) deliver a new architecture to carry them into the future.
SAP is restructuring its product set around a new service oriented architecture
based on NetWeaver. This will finally also affect Business One, although SAPs
main focus for this product continues to be the removal of the key functional

STRATEGY PARTNERS INTERNATIONAL COPYRIGHT 2006

Strategy Partners International

deficiencies. NetWeaver and Enterprise Service Architecture are, if at all, topics

for the more distant future of Business One.
With the announcement of Business One at CeBit 2002, SAP admitted tacitly that
the architectural heritage of R/3 is more of a burden than an advantage when it
comes to creating an ERP offering for the SMB market. Here, we shed some light
on how SAPs Business One addresses the need for simple, affordable, and
productive ERP capabilities for the SMB market. We will also discuss how SAP
Business One fits into the SAP family of ERP products and how upgrades to
mySAP might work.
Expectations

When the leading vendor of enterprise applications launches a new product,

customers and partners expect leading quality.
Architecture
Customers expect an architecture that is good enough for at least a decade,
allowing them to amortize their investments and to embrace and leverage
upcoming technologies and trends.
User friendliness
SMB users cannot invest heavily into end user training. The classic SAP product
line always was subject to criticism in this area. Users expect that it will be
significantly easier to work with an entry level product.
Functionality
With the R/3 and mySAP products, SAP more often than not leads the
competition in functionality by a significant margin. Customers and partners
expect to have a similar situation when SAP launches an SMB product.
Integration
Customers and partners expect better than average integration with SAPs other
products and popular third party products as well as legacy and custom programs.
Longevity
From a vendor like SAP, customers expect a predictable product cycle, transparent
roadmaps and standard maintenance for at least five years.
STRATEGY PARTNERS INTERNATIONAL COPYRIGHT 2006

Strategy Partners International

Quality
Over decades, SAP has built an image of a quality software vendor by providing
the corporate world with dependable products.
Investment protection
Customers and partners alike want to be able to use their investments in the
product for as long as possible. When the vendor improves and upgrades the
product, customers and partners want to be minimally affected and, if unavoidable,
be able to easily locate any areas requiring adaptation.
Upgrade path
SAP customers expect to be able to upgrade easily within SAPs product portfolio.
In this research, we will analyze to what extent Business One delivers on these
customer expectations.

STRATEGY PARTNERS INTERNATIONAL COPYRIGHT 2006

Strategy Partners International

SAP Business One The Architecture

The architecture of Business One is the classical, proverbial fat client architecture.
This architecture uses the presentation server (or client) to run the application logic
and relies on a shared database server for data storage.
The original idea behind this concept was to use the processing power available on
the client personal computers (PCs). With PC processing power being consistently
cheaper than server MIPS and clients typically running at 5% CPU utilization or
lower, this concept appeared to be very tempting when it came out more than 10
years ago.
A number of vendors embarked on this concept, and some are still using it today.
SAP, however, decided to opt for a different architecture in the early 1990s when
it laid the ground for its successful R/3 product suite. The two-tier architecture was
discarded for a number of good reasons:
When the number of users exceeds 100, performance begins to deteriorate. This
limitation is a result of the server maintaining a connection via keep-alive
messages with each client, even when no work is being done.1
A second limitation of the two-tier architecture is that implementation of
processing management services using vendor proprietary database procedures
restricts flexibility and choice of DBMS for applications.2
Current implementations of the two tier architecture provide limited flexibility in
moving (repartitioning) program functionality from one server to another without
manually regenerating procedural code.3
The two-tier client server architecture is not well suited to balance load and
memory requirements between users. This results in over-configuration because

See Carnegie Mellon University http://www.sei.cmu.edu/str/descriptions/clientserver_body.html

Ibid.

3
Ibid. See also Schussel, George. Client/Server Past, Present, and Future and Edelstein, Herb. "Unraveling Client/Server
Architecture."

STRATEGY PARTNERS INTERNATIONAL COPYRIGHT 2006

Strategy Partners International

you cannot steal idle capacity from other clients. In a shared application server
environment, the operating system would provide mechanisms for load balancing.
Similarly, all reconfiguration possibilities available in modern cluster architecture
are absent in the application part of the two-tier architecture. They are simply too
expensive for client PCs.
Different from servers, client PCs cannot be utilized on high CPU-load levels. The
client is primarily a user interaction device, and users quickly get angry about
sticky keyboards a feeling that quickly arises when clients are used at load
levels above 30%. Hence, the speculation on cheap MIPS is largely an illusion.

Figure 1 Business One uses a fat client architecture (Source: SAP)

Worse, there are real architectural penalties. Since the application has to run on
each client, it has to be either installed and maintained de-centrally or it must be
distributed centrally. Ideally, it would be dynamically invoked from the common
database server, but that limits the amount of code that can be loaded. To some
part, this can be overcome with sophisticated caching algorithms, but they are
rarely used.
Fat clients and the Internet do not go together very well. The application code on
the fat client cannot be distributed over the Internet, and the presentation part of
the application is usually too intertwined with the application to allow it to be split
off: Citrix has made a business out of this calamity. Users can install Citrix
terminal servers or similar functionality from Tarantella to get almost any nonInternet compatible software to be used over the Internet. This, however, means to
STRATEGY PARTNERS INTERNATIONAL COPYRIGHT 2006

Strategy Partners International

introduce another architectural layer in a rather inefficient way. Hence, such

solutions are rather justified when it comes to enabling legacy applications for the
Internet. In a modern product, they have no place. In a time when Software as a
Service (SaaS) is starting to appear on the agenda, fat clients are an anachronism.
Administrating fat clients is more difficult and laborious. They need frequent
upgrade,s and they are more vulnerable in terms of security.
All this made SAP refrain from using the two-tier client/server architecture.
Ultimately, even PeopleSoft had to re-architect its whole application suite in
admission that the two-tier approach was not scaleable enough. Many will recall
PeopleSoft CEO Craig Conways slogan No code on the client when he finally
announced the re-architected PeopleSoft 8.
With all this, it should have been clear for a mature vendor like SAP that the twotier client/server is not the right architecture. When SAP announced Business One,
the surprise could not have been greater when it became clear that Business One
had a two-tier client/server architecture.
Even within the obvious limitations of the two-tier architecture, Business One
appears to be restricted. At this writing, only a 32-bit architecture is supported and,
after initially relying on Microsoft SQL Server alone, database support has been
extended to IBM DB2 Express and Sybase. Linux is only available for the
database server in the south-east Asia market. On demand offerings, gaining in
popularity, are costly to implement as they require additional hardware. The
scalability limitations do not allow for large, cost-effective implementations.
There are, however, architectural issues well beyond client/server. Throughout the
middleware and application software industry, Service Oriented Architecture (or,
as SAP calls it, Enterprise Service Architecture) has become a new paradigm.
Service Oriented Architecture (SOA) can decouple and integrate software services
through its standardized interfaces, making the details of their respective
implementation (at least in theory) irrelevant. Thus, SOA can contribute to the
flexible creation of heterogeneous application landscapes. However, applications
need to be structured as complete and stand-alone services that are clearly defined
and can operate independently of the status and the context of other services.

STRATEGY PARTNERS INTERNATIONAL COPYRIGHT 2006

Strategy Partners International

Business One can use some of the basic constructs of SOA, largely, because it can
leverage Microsofts .NET architecture. This allows programmers to integrate
Business One using SOA constructs the same way as it is possible with thousands
of other applications. Inside Business One, there is really nothing that makes it
SOA or ESA compliant.

This is the second major inconsistency in SAPs

architectural blueprint for Business One.

User Friendliness

SAP was intrigued by the simplicity and the user interface of the original Top
Manage software, as Business One was called originally by Top Manage
(previously Menachel), the company that developed Business One. Top Manage
was owned by Reuben Agassi, father of Shai Agassi. Shai Agassi is a member of
SAPs executive board.
Top Manage had sold a few hundred copies of the product in countries including
Brazil, Poland and Israel and did not have the full range of languages and
regulatory support features required at the time of the $10 million (USD)
transaction.
Today, after many changes to the product, users are more critical about the user
interface of Business One. While they largely agree that it is less complex than the
R/3 or mySAP GUIs, they criticize a number of enhancements that SAP made to
the usability of Business One. For a product that is sold as being extremely user
friendly, some of these enhancements are quite surprising since they have been
standard on many competing products. Such enhancements included:

Adapting font sizes on screens

Including print preview capabilities

Replacing cryptic error messages with informative and actionable hints

Including tabs into the screen style guides

Providing integrated tool tips a form of improved help facility

Providing simple and consistent terminology

The key feature that intrigued SAP (so much so that it bought both TopTier and
TopManage) is the Drag-and-Relate feature that allows users to dynamically

STRATEGY PARTNERS INTERNATIONAL COPYRIGHT 2006

Strategy Partners International

visualize database relationships between Business One objects. This feature has
been much less of a silver bullet for usability than expected. Although patented,
there are, at least from the point of the end-user, comparable functions to be found
with competing products. The above list of recent changes to Business One
(Edition 2005) also indicates that users require a lot more than Drag-and-Relate
when it comes to usability. In this regard, SAP is in catch up mode, and the topic
will require more investments.
Functionality

Business One was designed having the concept of extensions by partners in mind.
In older versions, partners, customers, and even the vendor field organization
would modify the application source code, frequently creating severe upgrade
issues when migration to later versions was required.

Figure 2 Core functions, SAP supplied extensions, partner add-ons (as of 10/2005, later additions possible)

STRATEGY PARTNERS INTERNATIONAL COPYRIGHT 2006

Strategy Partners International

SAP tried to avoid this by separating the product into a core and extensions. SAP
strictly limits access to the core source code to its own Business One development
facilities.
Everybody outside of the Business One core development facilities (that also
includes SAP parts that are not directly related to Business One core development)
is forced to use the Business One SDK. The SDK has limited and well defined
access to the Business One functions. It is separated into three parts:
1. The user interface tool kit executing on the client
2. The data interface tool kit executing on the server
3. The integration toolkit (now superseded by Business One Integration)
While this gives the core developers some freedom to enhance their code without
too many considerations about hidden compatibility requirements, this strategy has
severe limitations. It limits the room for creativity for partners, and it has been
found to be painfully slow. The Business One SDK is not a suitable vehicle for
integrating throughput and data intensive solutions. Projects where this was
attempted, including the Intersport Retail project,, failed.4 Customers and partners
attempting to integrate data intensive extensions sometimes relied on direct
database access, thus bypassing the SDK. While this indeed can significantly
increase performance, it creates incalculable risks when upgrading to a newer
release or adding database fields.
The SDK and the associated philosophy of tightly guarding the source code of the
core are fundamental limitations when it comes to extending Business One. In a
world that is heading toward a Service Oriented Architecture (SOA), there are
clearly more modern and less limiting concepts for functional extensions. With
SAP itself selling its own version of SOA, called ESA, we fail to understand why
SAP has settled for a mediocre extension concept for a product that is in bitter
need of it. Business One is intended to be extended by many partners and to be

SAP has reimbursed the customer for his down payment and attempts now to solve the customers requirements with All-inOne, a product that has not even been integrated into SAPs NetWeaver strategy. SAP has communicated that All in One will
be subject to a major overhaul with projected availability late in 2006 . We, however, remain skeptic about this timing.

STRATEGY PARTNERS INTERNATIONAL COPYRIGHT 2006

Strategy Partners International

deployed often in distributed hub and spoke environments. In both areas, SOA is a
must for modern products.
When Business One was first released, it had significant functional deficits. In
Release 6.0, released in 2002, there was no support for manufacturing, restricted
multi currency support, bank payment support was restricted to support of the
interface of the Israeli Bank Hapoalim, and business partners could only have one
bank account. While this list is by no means exhaustive, it serves well to illustrate
the nature of the initial functional deficits of Business One.
SAP has made huge investments (we estimate that the total investment into
Business One has exceeded 100 Million by mid-2005) to overcome functional
deficits.
Key areas addressed to date include:

Figure 3 Business One roadmap (Source: SAP)

Support for additional languages. In 2002, Business One only supported

regulatory support for a few countries. In 2003, Business One grew to address the
needs of Austria, Cyprus, Denmark, Finland, Germany, Israel, Netherlands,
Norway, Panama, Poland, Singapore, Switzerland, and the United States of
America. In Business One 2005, SAP now supports many additional countries:

STRATEGY PARTNERS INTERNATIONAL COPYRIGHT 2006

10

Strategy Partners International

Australia, Belgium, Canada, Chile, China, Costa Rica, Czech Republic, France,
Guatemala, Hungary, Irish Republic, Italy, Japan, Mexico, Netherlands, New
Zealand, Norway, Portugal, Puerto Rico, Russia, Slovakia, South Africa, South
Korea, Spain, Sweden, and the United Kingdom.
Even now, the multi-language support is not on a level that users had on R/3.
There are restrictions in combining languages on the same machine (e.g. English
and Chinese cannot be combined). Additionally, there are no country versions for
India, Pakistan, or for Arab-speaking countries.5
While this shows SAPs determination to rapidly turn Business One into a global
product (which it was not at all five years ago), we expect that it will take
additional years to perfect this support and to make it stable and reliable.
Payment engine
Originally developed by Steeb, a midmarket specialist wholly owned by SAP, the
payment engine overcame most of the initial severe banking limitations of
Business One. After Steeb was forced out of the Business One market due to a
lack of profitability, SAP took over further development of the payment engine in
its Shanghai laboratories.
Manufacturing
Several partners such as SoftBrands (FourthShift and Demand Stream for discrete
manufacturers) and Softguide (BB.One) as well as W_Concept (EasyPlan) are
supplying extensions. Straton provides an extension for variant planning in the
textile industry. However, we believe that the limitations of the SDK do not allow
for high load and tight integration scenarios.
Retail
Although Steeb put significant resources into Retail One, it never came out. It was
initially built for Intersport, but due to architecturally imposed performance

Although Arab is also an official language in Israel, we do not count Israel as an Arab speaking country in this context.

STRATEGY PARTNERS INTERNATIONAL COPYRIGHT 2006

11

Strategy Partners International

problems, the project was considered to be too demanding for Business One. SAP
is still in search for a suitable solution for the retail market.
Outlook Integration
SAP put significant effort into Microsoft Office Outlook 2003 integration.
Demonstrations look nice, but customers still complain about speed and the level
of calendar integration.
Multi-language support limited
Multi-language support is still limited. It is currently not possible to have
languages such as German, English, and Chinese on the same system.
Integration

Most users would quite rightfully expect that SAP can integrate its products better
than any other vendor and that this integration is, wherever possible, uniform. At
any rate, it should be pre-configured and easy to implement.
When SAP released Business One, it did not meet any of the above expectations.
In fact, Business One did not integrate better with R/3 or mySAP than, for
example, Siebel or Microsoft Dynamics NAV. Integration was achieved on
three levels:

Figure 4 Business One integration with the SAP Enterprise Portal: no particular advantage (Source: SAP)

STRATEGY PARTNERS INTERNATIONAL COPYRIGHT 2006

12

Strategy Partners International

User Interface
You can integrate Business One with the other SAP products using a portal. SAP,
of course, recommends its Enterprise Portal which is part of NetWeaver.
However, any other portal will do the trick unless you need an iView, which only
executes on SAPs EP because it is proprietary portlet architecture. Any other
software can be integrated the same way. Business One has no real edge here.
Data
You can feed data into the SAP Business Warehouse (BW). SAP BW will gladly
accept data from any other application such as Microsoft Dynamics or any of
the Oracle business application products. Again, you could also use other data
warehouses from competing vendors they all integrate well.

Figure 5 Payroll service integration for Business One: no edge over competition (Source: SAP)

Processes
Business One uses SOAP and XML to transfer data into SAP XI (previously the
SAP Business Connector). This is nothing that could not be purchased from other
vendors, too.
Ideally, Business One and mySAP would share many concepts. The data and the
process models would be similar, development and administration would follow
STRATEGY PARTNERS INTERNATIONAL COPYRIGHT 2006

13

Strategy Partners International

the same principles. If this were the case, then SAP would have created a product
that really has an edge over functionally in equivalent products from competitors.
Since Business One does not provide payroll, integration with SAP HR is
important. Most Business One installations have to integrate with service
providers because running SAP HR is well above the scope of a typical SMB.
Here, SAP proposes to use the following integration scenario:
Again, there really is nothing special any other ERP application can be
integrated with mySAP HR the same way. Business One, of course, can be
integrated with other, non-SAP, HR packages as well.
Very recently, SAP developed a much improved integration package for Business
One called B1i. Initially developed in Germany, it now is being worked on in the
SAP Shanghai labs to reduce cost, a much needed measure for a product that still
is a heavy burden on SAPs financials.
B1i uses a very different technology (now called officially SAP Business One
integration for SAP NetWeaver 2005) that is not based on NetWeaver, as one
might expect. Instead, it uses a model based integration technique that cleanly
separates between technology and semantic aspects. Currently, it allows only
integration scenarios between Business One and R/3 4.6C as well as R/3
Enterprise. Given the fact that it is a brand new product in early states, this gives
an interesting insight. When it comes to selling Business One, SAP does not want
to face other impediments like making customers upgrade to mySAP or having
them install NetWeaver.

STRATEGY PARTNERS INTERNATIONAL COPYRIGHT 2006

14

Strategy Partners International

Figure 6 Basic scheme of new Business One Integration (Source: SAP)

SAP Business One Integration can, of course, be used in other integration

scenarios, once they are supported. Users and partners can define their own
scenarios of choice. Currently, only six so called Business Integration Units
covering the following areas are shipped:

Figure 7 Business One Integration architecture (Source: SAP)

1. Purchase Order form B1 to R/3 Sales Order

2. R/3 customer to Business Partner in B1
3. R/3 Delivery to Goods Receipt in B1
4. R/3 Invoice to B1 Invoice
5. R/3 Product to an Item in B1

STRATEGY PARTNERS INTERNATIONAL COPYRIGHT 2006

15

Strategy Partners International

6. R/3 Sales Order to B1 Purchase Order

These Business Integration Units can also be used in combination. SAPs new
Business One integration technology is currently in early release, and it is not well
known within SAP. While it is a significant improvement, it also raises new
doubts and questions as it parallels functions found in NetWeaver. Business One
Integration uses different and more modern technology, and it relies on OpenSource Apache Tomcat as the http application server is this the replacement for
NetWeaver XI? Is it an admission that NetWeaver XI is too complex for hub and
spoke scenarios?
The new Business Integration Units addressing individual integration scenarios are
currently limited to the most frequently used SAP R/3 versions. Other
applications, particularly non-SAP products, are not yet targeted, and there are no
announcements to this end as of yet. While functionally part of integration
orchestration complexes, SAP here again does not follow any standards. As of
now, SAP Business One Integration can only act as a proprietary hub in a
Business One to Business One/R/3-environment.
Longevity

SAP is following a five year mainstream maintenance practice for its mySAP
range of products. Business One, however, has a much shorter maintenance
schedule. Here, mainstream maintenance is only available for two years from
customer release.6 This forces customers to upgrade at least every two years, and it
may mean costly license upgrades like those customers experienced when
upgrading from R/3 to mySAP. The requirement to upgrade every two years
significantly reduces customers ability to predict their costs of ownership.
SAP significantly deviates from standard industry practice as all other significant
competitors offer much longer maintenance cycles.

More details can be found at http://service.sap.com/smb/solutions where you can find exhaustive material on SAPs release
strategy.

STRATEGY PARTNERS INTERNATIONAL COPYRIGHT 2006

16

Strategy Partners International

Quality

Customers and partners consistently complain about the product quality of

Business One. SAP has established a high quality level for its mainstream R/3 and
mySAP products. Business One has not yet reached this level. Responsiveness of
SAPs support is lacking, and customers complain of errors that have been waiting
for a fix, in some cases, for more than a year. Some Business One partners are
unreliable and do not pass bug reports on to SAP. Customers do not agree with
SAPs positive customer satisfaction survey results; they perceive their situation as
being much less glorious than the picture SAP paints.
To fix problems, SAP, like any other software vendor, issues patches. As the patch
releases for Business One are frequent, many partners do not have enough
capacity to scrutinize their add-ons against the patch levels. Frequently, they keep
their customers at older patch levels to avoid upgrade efforts. Hence, many of the
quality improvements have not yet made it to customers.
Investment Protection

Users and partners alike require investment protection. On the average, midmarket users change their ERP system every seven years. Users buying now want
to have until 2013 to amortize their investment.
Midmarket users are primarily interested in functionality. The software must
support their business and if possible, do so straight out of the box. For them, a
mature, function rich, and easy to implement system with low costs of ownership
often is preferable over a young and sexy yet functionally immature product as it
is subject to many changes as it grows up. Changes are good for users who receive
them in time and can use them immediately. Other customers are burdened with
migration costs without profiting from these changes.
When partners decide to sell Business One and to provide extensions for it, they
enter an even stronger dependency. They invest in infrastructure, marketing,
training, and software development. First and foremost, they seek to profit from
SAPs branding.
While low functionality offers genuine opportunities for partners filling the gaps, it
also poses risks. Over time, SAP may (as proven with R/3) elect to endow the

STRATEGY PARTNERS INTERNATIONAL COPYRIGHT 2006

17

Strategy Partners International

product in its core and strengthen its competitive position with functions
previously provided by partners. This may invalidate the partners investments.
During SAP maturing and improving the product, partners may find themselves
confronted with unplanned development efforts resulting from adapting their addons. While the basic Business One architecture protects SAP from code changes
by partners and users, it does not shield partners and users from SAPs code
changes completely. As in real life, puberty and adolescence are stressful times for
both parents and children.
To date, SAP has not been able to sell Business One as often as it had planned. For
many countries such as Switzerland or Germany, far less than half of the projected
sales had happened by the end of 2005. Large Business One partners like TSystems, Steeb (a fully owned subsidiary of SAP), and RedIT in Switzerland
stopped the Business One partnership. Steeb once was planned as the German
central Business One service hub. SAP transferred the approximately 50 Steeb
customers and part of the staff to a small partner, Kirbis. RedIT became a
Microsoft partner.
Given the developmental character of Business One and its architectural
limitations, it does not seem likely that customers or partners can exploit a stable
utilization and amortization period of seven years. When engaging on Business
One, it rather appears to be advisable to allow for contingencies covering early
depreciation.
Upgrade Path

SAP Business One is, apart from the SAP logo, incompatible with the mySAP
range of products. It differs in:

Look and feel

Architecture

Implementation language

Data model

Process model

Functionality

STRATEGY PARTNERS INTERNATIONAL COPYRIGHT 2006

18

Strategy Partners International

Development platform

Software logistics

In short, it is a different product. It is as different as if it had come from an

unrelated vendorwhich, in fact, was initially the case. Yet, SAP is telling its
customers and prospects that there is an upgrade path to the mySAP line of
products. How is this going to work?
The approach is based on SAPs vision that users should manage their applications
purely on a process level, making the application software products and their
implementation details largely irrelevant. Processes that are implemented in a
service oriented architecture are called on by SAP Enterprise Services.
SAP, aided by IDS Scheer, is building an Enterprise Services Repository.
Currently, this repository, while not yet released, is embracing only services built
on the mySAP Business Process Platform which is neither able to accommodate
Business One nor All in One.
The first SAP product to use the Business Process Platform and the Enterprise
Services Repository will be All in One S7 which, per Henning Kagermann8, will
be announced and available in the second half of 2006. Given the magnitude of
this project, we have doubts about this date.
As of now, Business One is not even part of a similar endeavor. Notwithstanding,
SAP presents the vision (see Figure 8) that all SAP applications will be enabled to
be embraced by this repository. Today, it is totally unclear how and when SAP
will have decomposed Business One into a set of services that can be individually
configured. If SAP will succeed here, then it is likely to result into a product rearchitect with unknown compatibility.

In his CeBit press conference on March 9, 2006, SAP CEO Henning Kagermann used quotation marks when referring to the
next major makeover of All in One, which today is still an R/3-based product. We see this as an indication that the name may
not yet be final.
8

Press conference CeBit 2006

STRATEGY PARTNERS INTERNATIONAL COPYRIGHT 2006

19

Strategy Partners International

In the interim, any migration from Business One to mySAP or All-in-One is

technically like going to a different product from another vendor.

Figure 8 SAP's vision of application fusion using a proprietary Enterprise Services Repository (Source: SAP)

Bottom Line

Many of the problems and issues associated with Business One are reminiscent of
the difficulties of other industries to enter a lower market tier. Daimler-Chrysler
has ongoing difficulties with its Smart product unit, and premium airlines are still
trying to figure out how to run their no-frills or discount brands. SAPs
infrastructure is too expensive for a low-price product like Business One. The
consulting rates that go with this product are too low to allow for experienced,
high quality consultants.
SAP is trying its best to reduce costs. Transferring product development to lowcost countries is part of the equation. We doubt, however, that SAP will achieve
shipment volumes that permit margins in excess of 30% as it has projected for its
software in general. Looking at the numbers we have, we cannot see how SAP
makes money with Business One.
SAP has tried many times to scale R/3 down. All attempts to mask the complexity
and the resource requirements were unsuccessful. In its despair, SAP finally
resorted to a product that architecturally was in straight violation of its previously
expressed convictions.
SAP is selling Business One exclusively through its superb branding. Business
One, had it come from a previously unknown vendor, would have had very limited
STRATEGY PARTNERS INTERNATIONAL COPYRIGHT 2006

20

Strategy Partners International

market impact. Many prospects who looked at SAP Business One, attracted by the
SAP branding, have been disappointed and, seeing that they cannot combine a
low-end R/3 with high-end functions and low-end economics, have started
evaluating other vendors.
SAP may very well fix a good many of Business Ones problems, albeit at high
costs and further pushing out a break even point for its investment. Areas that
cannot be fixed easily are the architecture, the incompatibility with its other
products, and the economics.
Any attempt to address these areas will result in a new product and, hence,
increased uncertainty for anybody engaging now on Business One. On the other
hand, we do not feel that SAP has the luxury to ignore these issues. We would not
be surprised to see SAP taking some radical steps two years from now; if and
when SAP has proven that it can scale down a reworked All-in-One and comply
with its own architectural master plan.

STRATEGY PARTNERS INTERNATIONAL COPYRIGHT 2006

21

Strategy Partners International

Table of Figures
Figure 1 Business One uses a fat client architecture (Source: SAP)...........................................................5
Figure 2 Core functions, SAP supplied extensions, partner add-ons (as of 10/2005, later additions
possible) ................................................................................................................................................................8
Figure 3 Business One roadmap (Source: SAP)..........................................................................................10
Figure 5 Business One integration with the SAP Enterprise Portal: no particular advantage (Source:
SAP) ....................................................................................................................................................................12
Figure 6 Payroll service integration for Business One: no edge over competition (Source: SAP).......13
Figure 7 Basic scheme of new Business One Integration (Source: SAP) .................................................15
Figure 8 Business One Integration architecture (Source: SAP)................................................................15
Figure 9 SAP's vision of application fusion using a proprietary Enterprise Services Repository
(Source: SAP).....................................................................................................................................................20

STRATEGY PARTNERS INTERNATIONAL COPYRIGHT 2006

22

Strategy Partners International

Abbreviations
CPU

Central processing unit

DBMS

Database management system

MIPS

Million instructions per second

GUI

Graphical user interface

ESA

Enterprise service architecture (SAP)

SOA

Service-oriented architecture

STRATEGY PARTNERS INTERNATIONAL COPYRIGHT 2006

23