ActiveX technologies are becoming mature enough to bring business-processing capabilities to intranets (see the sidebar "Future Intranet Development").
ERP implements and automates business rules and processes within and across core organizational areas such as manufacturing, distribution, finance, and human resources. Four of the top 10 ERP vendors are based in Europe. They represent 45 percent of the worldwide market, according to Advanced Manufacturing Research (Boston, MA, U.S.). The market leader is Germany-based SAP AG, which holds a 33 percent market share. Some other globally active European ERP vendors include Baan, JBA International, and Intentia International.
The worldwide ERP market expanded dramatically from $13.8 billion in 1996 to $17.7 billion last year. A recent study from IDC's European Sof
tware Expertise Center says that ERP software now accounts for more than half of the software licenses and maintenance revenues in Western Europe, growing twice as fast as the rate of the overall application market.
This remarkable expansion is being driven by the fact that Fortune 500 companies are taking an increasingly global approach to business. They are investing heavily in integrated enterprise-wide applications. Smaller manufacturers are looking for PC-based off-the-shelf software packages to track orders, material purchases, and production schedules.
In addition, many big manufacturing, pharmaceutical, and electronics companies are linking up with customers and suppliers via extranet-based electronic transactions. This move toward electronic commerce requires a close linkage between internal business processes and external transactions. It has encouraged ERP vendors not only to provide gateways to the Internet, but also to reengineer their packages to capitalize on Java and Distributed Compon
ent Object Model (DCOM) components.
Networked Business Objects
Many of the latest releases of ERP systems already work on the basis of networked business objects (NBOs) that constitute collaborative, flexible business-process elements to automate and improve key parts of the manufacturing and supply chain. In other words, after the "downsizing" of these systems to client/server architectures in the early 1990s, ERP systems are now undergoing another major change: the shift to components.
For example, SAP, Oracle, and Baan came up with the first componentized and Web-enabled application suites last year. The new releases -- SAP R/3 4.0 and BaanSeries (formerly called Baan V), expected to be available this spring -- will push the NBO concept a step further. Oracle started shipping its Java-based applications release 10.7ERP suite early this year. JBA and Intentia announced that new products based onNBOs will be released later this year.
The old idea of componentware that enables more effi
cient reuse of code and facilitates maintenance of applications has finally caught on in the enterprise software industry. However, because these ERP vendors have a large customer base with millions of dollars invested, they need to stay compatible with their legacy architectures. Therefore, they haven't completely redesigned applications. Rather, they've wrapped existing code so industry-standard component models such as Common Object Request Broker Architecture (CORBA) and DCOM can invoke it.
SAP, for example, started to release business APIs (BAPIs) in 1996 and went on publishing components piecemeal. R/34.0 now includes 14 business components (BCs), 45 Internet application components (IACs), 200 finer-grained business objects (BOs), and more than 400 BAPIs to access componentized business functionality. Says Peter Graf, SAP's technology marketing manager, "Because we introduce new technologies in an evolutionary way, there is no need for our customers to migrate along a disruptive path."
Enterpris
e software was traditionally either purchased as a complete standard package or developed and maintained in-house. The challenge is now to combine the two alternatives. "I believe that at least 50 percent of in-house development can be replaced by standard applications, provided that these applications prove to work in combination with the remaining legacy architectures and show enough flexibility to adjust to individual needs," says Andries Bottema, chief ambassador of Baan.
With NBOs and standard APIs implemented, ERP users can better combine standard modules with selected business functionality of other modules, even if these modules do not belong to the same release. (For more information on the benefits of componentized business frameworks, see the sidebar "Benefits of Componentized ERP".)
Naturally, the new generation of enterprise business software continues to perform the same order-processing functions. The big difference with BO frameworks is that order processing can now be performed by a J
ava applet running on the Internet or via DCOM from a Visual Basic program.
At the same time, the key players in the market, such as SAP and Baan, are providing open access to the new BOs via APIs. This is also stimulating a new market of complementary third-party applications that directly access ERPbusiness functionality from the outside.
SAP Business Framework
In the R/3 business-framework architecture, for example, interaction between NBOs is based on a joint business concept called the R/3 reference model. It describes basic business functionality and provides the semantic layer for applications running on different systems at different sites.
Thus, because NBOs share a common business background, they "understand" each other across the extended value chain. Companies can now combine components such as consolidation and availability-to-promise across individual R/3 modules, even if these components do not belong to the same release.
The architecture of the new R/3 business fram
ework comprises five major ingredients:
BCs:
Release 4.0 makes the R/3 functionality available in the form of 14 BCs. A component of this type has its own development, implementation, and maintenance cycle. Examples include human resources, availability-to-promise, product data management, consolidation, and pricing. SAP is working on componentizing additional R/3 functionality and says it will continuously publish new business functionality wrapped into BCs.
BOs:
BCs are built out of BOs. BOs represent business entities such as an order and supply a dedicated, encapsulated business functionality via BAPIs (see the figure
"SAP's Business Framework"
).
BAPIs:
A way for BOs to communicate with other programs is via BAPIs. BAPIs are methods of BOs that you can invoke from different programming languages. BAPIs combine object-oriented technology such as encapsulation and information hiding with the R/3 business logic, independent o
f the language and the method invocation and component model in use. As SAP's Graf says, "BAPIs separate the how from the what."
ALE:
SAP uses application link enabling (ALE) to integrate BOs. This permits cross-component mapping of business processes and means that, from a business point of view, it makes no difference whether a process is handled in a single R/3 system or by a number of cooperating BOs. ALE, which has been part of R/3 since release 3.0, is a message-based, asynchronous communications protocol. It provides semantic synchronization between BOs and includes a distribution model for BOs.
ALE is independent of the underlying database and lets companies aggregate data from various geographically dispersed databases. For example, a company could use it to select, map, and store data in several databases locally on a server to increase the performance of product availability checks. In addition, ALE lets BAPIs be invoked asynchronously.
ABAP objects
:
This is an object-oriented extension of SAP's ABAP/4 language and run-time engine. It delivers a new extended virtual machine (VM) capable of running both new applications implemented using ABAP objects and all existing ABAP/4 applications. It helps programmers develop BOs capitalizing on a single inheritance object model including encapsulation and polymorphism.
Along with release 4.0 come several tools, such as the Interface Adviser, which helps developers model business processes via BOs and BAPIs; IDES, a training tool that simulates different implementation scenarios; and Web Studio, an HTML tool that includes a series of templates to design the interface of applications that access R/3 from the Web.
In addition, third-party tools such as IBM's VisualAge for Java and Borland's Delphi/Connect for SAP integrate with BAPIs, so that developers can build Java or client/server applications that enhance R/3 without leaving their standard development environment.
The SAP business framework
integrates with Java, JavaBeans, CORBA, and DCOM. Integration of different languages and component models is possible via the SAP automation programming interface. SAP automation, in contrast to the SAP business framework that describes the semantics of a business transaction, defines the technical details of method invocation.
Remote function calls (RFCs) offer an alternative way to access R/3 business logic on a more fine-grained level. Developers usually use RFCs where BAPIs are not available. The problem with RFCs, however, is that, unlike BAPIs, later releases of R/3 may not support all RFCs.
BaanSeries Architecture
Similar to SAP, the componentization of the Baan ERP suite will be delivered in incremental stages, with the first BaanSeries components delivered this spring. Over time, the company will upgrade these components.
The BaanSeries architecture consists of several componentized layers:
FCs:
BaanSeries will be packaged into discrete functional compo
nents (FCs), such as finance, warehousing, and configurator. FCs can run across disparate releases to simplify the disruptive process of upgrading multiple sites.
BOCS:
In contrast to, for example, SAP's BOs, business object component sets (BOCS) not only perform distinct business functions, they may also maintain persistent data or monitor business transactions. In other words, a BOCS is a set of related business and data services that works as an autonomous logical and physical unit. Baan says that eventually all FCs will be distributed as BOCS made out of small business functions. Currently, only some parts of the software are implemented as BOCS.
BOIs:
The Baan components communicate with each other using business object interfaces (BOIs). They control the granularity and content of the information that flows within the system. A BOI has access to data, applets, and transactions. At the data level, BOIs comprise more complex business methods (e.g., update-
order) and finer-grained data access methods (e.g., update-purchase-price).
At an applet level, BOIs can control the deployment of DLLs written in Baan's fourth-generation language (4GL). Baan's architecture also permits BOIs to access transactions between applications, work flows, and entire FCs.
DAL:
The data abstraction layer (DAL) contains the system's data-consistency rules. By abstracting out all the data-consistency rules of the Baan ERP database, the DAL both simplifies application development in Baan's 4GL and makes it practical to use mainstream rapid application development (RAD) tools such as Delphi or Visual Basic. It is the developers' interface to the Baan database.
DEM:
Through dynamic enterprise modeling (DEM), developers begin an implementation by first creating graphical models of their organization. Because the Baan BO configuration environment links functional components directly to these models, complete applications can be r
apidly reconfigured as business requirements change. DEM stores the business logic in an underlying repository and automatically keeps application logic in sync with data-model specifications.
XMA:
While BOIs facilitate the message content or semantic aspect of the integration of BOs, the extended middleware architecture (XMA) defines the technical plumbing of objects. The XMA acts as a buffer between the work flow and the middleware layer, thus enabling communication through DCOM or CORBA in a distributed environment. The XMA supports synchronous or asynchronous communications across multiple objects.
The Baan ERP architecture can most efficiently be described as a framework of business functions that have different degrees of granularity and linkage. Business functions can be isolated BOCS, predefined and even industry-specific work flows, or complete business processes.
Logically, the architecture consists of several abstraction layers that can encapsulate legacy code,
facilitate 3GL and 4GLscripting, and include component libraries, business-function-oriented sessions, work flows, complete business processes, and functional components (see the figure
"The BaanSeries Architecture"
).
From a technical point of view, the glue that links all these layers is the XMA framework architecture. To make sure developers put together the components in a way that makes business sense, the DEM provides the business models based on a reference model catalog.
Virtual Machines
Baan applications operate in a VM environment called Baan Virtual Machine. This is a bytecode kernel that uses the same concepts as the Java VM and runs on several Unix flavors, OS/390, OS/400, and Windows NT. (JavaSoft even licenses some VM technology from Baan.)
In this environment, a Java- or ActiveX-enabled browser works as just another user interface to the Baan system. "In our system, there is a one-to-one correspondence between user-interface fields, Java applets, or
ActiveX controls and logic events within the system. Whether a logic event executes as a DLL in an application server or as an applet in a browser does not really affect the logic of that application," says John Fanning, senior research consultant at the Baan Institute.
In this hypertier architecture, the boundaries between client and server are irrelevant. "It's kind of a best-of-both-worlds scenario [client-centric and server-centric] for remote presentation," notes Fanning. Baan also uses an integrated Internet push technology to refresh browser applets or controls as needed to reduce administration work load on the client.
JBA's Enterprise Vision
JBA says it will release the first componentized modules of its System 21 ERP application in November. This will include ActiveX- and browser-based thin-client technology, a tool for graphically assembling client and server components called Constructor, an enterprise modeling tool that extends Constructor on a business-process level, and sever
al functional components. The components will, however, be procedural code wrapped into JBA's own method-invocation mechanism and will not interface to standard component models.
However, in late 1999, JBA plans to come out with a redesigned architecture code named EnterpriseVision, with a much finer level of component granularity. This will be the foundation of a new purchasing, inventory, and order-processing system.
Intentia's Web Applications
Swedish ERP vendor Intentia launched its enterprise software Movex 10 late last year. It comes with Windows 95/NT client software and includes five Web applications: service order request, customer order entry, order inquiry, customer registration, and shipment advice and purchase order confirmation.
According to Bjorn Pettersson, R&D manager at Intentia, the Movex Web applications use CGI in, for example, the service order request and order inquiry modules to access the ERP database and Java for more interactive applications, such as custo
mer order entry. The Java-enabled applications open up their own communications channel with the Web server and are therefore not stateless, as are, for example, plain HTTP sessions.
Movex developers are also porting the server-based parts of the applications to Java with a more componentized architecture. Project head Mikael Ageras says the new architecture will consist of BOs and components. BOs comprise a complete business function (e.g., the customer order process) and are built of components.
You can invoke components via DCOM or JavaBeans. They represent simple business entities such as orders. Components are intended to be the main interface for third-party developers, although it is also possible to access Movex applications on a BO level. This next-generation version of Movex will run on OS/400 as well as NT and is slated to be released at the end of the year.
The componentizing of enterprise software makes it easier to access business functionality in a distributed and heterogeneous envi
ronment that has several installations. Because the division into BOs was done with Internet standards in mind, the new business frameworks closely integrate with the Web.
E-Commerce Platform
There are two basic approaches to Web-enabling an ERP system. Depending on the developers' experience and knowledge, they can use the ERP systems' 4GLs to define both the transaction flow and the HTML-based front end. This inside-out approach is primarily used when an ERP system needs simple interfacing to the Web. It has the benefit of maintaining all business logic and code inside the system.
In many cases, developers will want to use their common tools for Web development, authoring, and site management. This outside-in approach puts the logic that generates the Web application and the user interface outside the R/3 system and invokes BOs through the standardized APIs.
An advantage of the outside-in approach is that developers can interface the Web application with DLLs, DCOM controls, CORBA ob
jects, Java classes, or JavaBeans that sit on a Web application server outside the ERP system.
"This kind of loose coupling makes [outside-in] Web applications independent of the back-end system," says Karsten Schneider, a development project manager at Intershop Communications, who devised the interface between Intershop's on-line shopping system and R/3. Because an ERP system's duty cycle is often in sync with the usual 8-to-5 working day, an independent design of Web applications allows for unconstrained Web commerce sessions around the clock. On the other hand, developers need to replicate data stored inside the ERP database in the Web application.
For Web integration, Baan capitalizes heavily on its VM architecture, whereas SAP uses the integration components of its business framework. In addition, both vendors developed a number of tools to maintain and deliver Web-based interfaces and solutions.
SAP, for example, provides the SAP Web Basis Internet gateway (formerly known as Internet Transa
ction Server), the IACs (which comprise predefined R/3 system transactions), and SAP@Web Studio, an NT-based development tool that helps create and manage IACs. SAP@Web Studio also enables access to a variety of generic R/3 system services.
Typically, in an inside-out approach, R/3 developers use the SAP Web Basis to connect to the Web. To directly access R/3 in an outside-in approach, tools such as Haht Software's Hahtsite and Microsoft's Visual Interdev support BAPIs.
Several systems integrators are working on Web-commerce solutions. In March, Faber Castell Consulting (Nuremberg, Germany) released an R/3-Web application that's called S@P/link. It works on top of Allaire's ColdFusion extensible Web development system.
S@P/link's client/server architecture provides a few alternative access methods to the R/3 backbone, such as RFCs, COM/DCOM, and ALE. It can manage multiple R/3 sessions concurrently, hold data locally in an ODBC database, and may eventually interface to other systems such as Baan E
RP.
The E-Commerce Interface
BAPIs will eventually become SAP's primary interfaces to electronic commerce. (Although in many of the current installations, developers use RFCs because BAPIs do not comprise the complete R/3 functionality that's needed for complex electronic-commerce applications.)
Similar to Electronic Data Interchange (EDI), BAPIs contain the business semantics necessary to describe business concepts such as purchases or status requests. However, according to SAP's Graf, at the current stage, the SAP business framework doesn't aim primarily at EDI's long consistent transaction scheme and the corresponding longtime relationship between supplier and manufacturer. "BAPIs standardize business content and offer the opportunity to do business on the Internet in an ad hoc fashion. That is the main difference to EDI," says Graf.
In a business-to-business environment, large enterprises that already have implemented R/3 will therefore use BAPIs to interface with their smaller supp
liers. However, provided that SAP continues to play a dominant role in the market, BAPIs may eventually become a universal interface to electronic commerce. In a research note published last year, the GartnerGroup even suggests that after the year 2003, BAPIs may replace EDI.
Where to Find
Baan Nederland B.V.
Ede, The Netherlands
Phone: +31 318 691 691
Fax: +31 318 691 680
E-mail: jfanning@baan.nl
Internet: http://www.baan.com
Mission-Critical Components
