SAP NetWeaver Background, Direction, and User Recommendations

NetWeaver Background

Back in 2003, SAP positioned NetWeaver as a tool to reduce the total cost of ownership (TCO), but it has now morphed into a tool to enable competitive advantage through business process innovation. To put it another way, the first components of NetWeaver in 2003 were mainly tools to bridge the gap between SAP and non-SAP applications. Nowadays, the idea is to have SAP applications that are broken down into ever smaller chunks and tied together with Web services, so that customers can cherry pick applications and even add them in chunks, even if they are provided by companies other than SAP.

On the one hand, this strategy should enable customers to create and modify applications faster and more economically. On the other hand, SAP's developers should now be able to develop new applications in bite-size pieces, which should speed delivery of new functions, instead of the tradition years-long wait between major software releases. Thus, as indicated in Multipurpose SAP NetWeaver, about half of SAP's over 9,000 development people have been working on the platform, while the other half have been developing application enhancements and bug fixes. Of the approximately 4,500 people working on NetWeaver, about two-thirds are devoted to infrastructure development and one third to either wrapping existing functionality as Web services or rewriting existing components.

In terms of the evolution of the platform from merely handling transactions, through integration, to applications composition and business processes, SAP has certainly reached the composition stage. For instance, in 2003, NetWeaver was mainly an integration platform, comprised of a portal, enterprise application integration (EAI) technology, and early SAP xApps (cross-applications), while, nowadays, its capabilities have been dramatically expanded to include capabilities like business process management (BPM) and master data management (MDM) (see SAP Bolsters NetWeaver's MDM Capabilities) .

In fact, SAP touts service oriented architecture (SOA) as essentially the fourth wave of information technology (IT), which enables "immediate change" capabilities (versus the "immediate processing" capabilities of the mainframe era in the 1980s, the "immediate reporting" capabilities of the client/server era in the early 1990s, and the "immediate trading" of the Internet era of the late 1990s). The vendor also claims that SAP is the only vendor that has been positioned in the forefront of every major change during the past decades. What is more, SAP is believed to be ahead of schedule with promised customer adoption objectives, and remains on track with all technology enhancement deliverables.

As a logical follow-up to SAP's NetWeaver progress during the past three years, this software giant wants to position itself at the hub of a thriving innovation ecosystem. This ecosystem would be comprised of a few "mega-brokers", along with customers, partners, and independent software vendors (ISV), that are engaged in dynamic working relationships to spark and foster innovation by leveraging the unique value of each participant (including SAP) and to ensure usage continuity. SAP NetWeaver projects are now reportedly generating approximately $1 billion (USD) per quarter in new services revenue for SAP and its partners, and there are currently 5,000 to 6,000 NetWeaver projects completed or underway.

The vendor professes to understand that customer focus bundled with partner friendliness should result in winning solutions and that there is a huge opportunity for the many willing participants in the estimated over $30 billion (USD) enterprise applications market. The accompanying service revenues create a win-win, non-zero-sum situation for partners, where SAP pledges to be a clear, open, fair, and efficient broker.

This is Part Two of a two-part note. Part One detailed SAP's NetWeaver strategy.

Addressing the Need for Standards

SAP is making an effort to address concerns about the current lack of agreement in defined standards for connectivity and interoperability (see Enterprise Resource Planning Giants Eye the Shop Floor). To that end, over a year ago, the giant created the Production to Business (P2B) Interoperability Initiative to address customer interest in furthering the adoption of P2B standards, and concurrently created the SAP Interoperability Certification Initiative to address business-to-business (B2B) and application-to-application (A2A) standards. Recently, SAP has combined both initiatives within the SAP Independent Vendor Network (IVN) for Business Collaboration Initiative, whose scope includes all standards-based interoperability so as to cover both external and internal integration, and to create value networks for business collaboration and the exchange of master data. The initiative entails SAP's support for standards within NetWeaver, SAP's participation in the standards community, and the creation of the IVN partner ecosystem.

In fact, the pent-up demand for solving the interoperability problem may create an opportunity for SAP to not only benefit its customers, but to benefit itself by promoting SAP NetWeaver as a solution to this problem. For more information, see Enterprise Resource Planning Giants Eye the Shop Floor.

The selection of staunchly supported standards will be driven by customer demand, in which regard SAP has pledged to maintain standard integration elements from these organizations in the SAP repository where partners and customers can use them. In addition, the IVN should create a partner ecosystem where partners can collaborate with SAP and other partners while creating, certifying, and delivering pre-built business value. The partner ecosystem should also have various partner-specific packages that will include everything needed beyond mere standards to complete integrations (e.g., they could include industry-specific business processes or scenarios, which might be tuned for specific customer needs). There are few standardized business processes now, and additional standardization would mean less customized work for partners and customers, and more content in the SAP registry. Under the above-mentioned SAP IVN initiative, SAP is stepping up its involvement in selected standards development, as all initiative-related activities will revolve around industry standards, such as Chemical Industry Data Exchange (CIDX); RosettaNet; Open Application Group Inc. (OAGi); Instrumentation, Systems, and Automation Society (ISA)-95, Machinery Information Management Open Systems Alliance (MIMOSA), OPC Foundation, etc.

Leveraging NetWeaver for the Shop Floor

It is no secret that SAP has been attempting to extend its reach onto the shop floor, through both its "adaptive manufacturing" and "adaptive business networks (ABN)" themes and its 2004 introduction of the SAP Plant Manager Dashboard. This last leverages NetWeaver in order aggregate and present information to users, empowering them to manage and improve manufacturing performance. For more information, see Enterprise Resource Planning Giants Eye the Shop Floor.

When it comes to SAP's leverage of ISA-95, the standard-based mappings are all going to be built into SAP NetWeaver's Exchange Infrastructure (XI) component (i.e., the XI Business Package that will be available as part of SAP xApp Manufacturing Integration and Intelligence [SAP xMII]), and there are going to be some rules (e.g., when do the messages go out, when does one hold back a message, what is the sequence and grouping of messages, etc.) that will also exist in NetWeaver. So when the user company gets NetWeaver, it will also get the mappings from SAP, and the rules about messages, which should all be one core NetWeaver-based part, allowing users to achieve interoperability without having to go out and buy the adapter from somebody else.

SAP has repeatedly stated that when its customers strongly demand it to incorporate new functionality into its product suite, it is possible for the vendor to make acquisitions to meet these needs. However, this approach conflicts with its xApp strategy to attract a vast ISV development community within the NetWeaver environment. This is especially the case with SAP's forays on the plant floor, where the company has long realized that it could not provide everything that customers from within the plethora of industries it targets were demanding. Dozens of shop-floor vendors, some of which have been quite noisy and visible in the SAP NetWeaver strategy and at several industry events, have thus been working with SAP to fill these gaps.

The Challenges of SAP's Strategy

SAP claims to basically not be interested in the specific industry functionality that most ISVs provide (since it is very good at cross-industry functionality, but typically does not enter industry-specific development areas). However, recent SAP acquisitions might be sending the conflicting messages that partners are not equal (which is likely true in any real world case), and that building a composite application that gains market strength might result in yet another acquisition. Even so, this is a better scenario than having SAP develop the solution internally (and clandestinely), only to cannibalize the partner's business.

In pursuing such a strategy, SAP inevitably risks somewhat diminishing NetWeaver's appeal to ISVs that are looking to remain independent, and thereby limits the benefits to prospective users of the xApp strategy. This may be music to other enterprise software suppliers' ears, as the likes of Oracle, SSA Global, IBM, Intentia, IFS, and Infor Global Solutions have vested interests in plants within both the discrete and process industries, not to mention the fact that this may create an opportunity for them to provide their platforms to ISVs in place of SAP's platform.

On the other hand, it is quite clear that SAP is dedicating a significant amount of resources to the NetWeaver concept, since what drives SAP is the desire to sell NetWeaver licenses, its portal, and integration technology. If the SAP Plant Manager Dashboard is to become the desktop access point for the likes of manufacturing managers, then SAP needs content, and that content will for some foreseeable future be provided by multiple production management, execution, and automation suppliers.

The giant's ability to create the aforementioned ecosystem remains chief among the challenges it faces. Moreover, NetWeaver has not so far contributed much to SAP's revenues (as it is mostly bundled for free into other mySAP and xApps components). However, if it catches on, SAP will have an opportunity to wield enormous clout and influence by creating an industry standard for new enterprise applications.

Through possibly thousands of ISVs, SAP could penetrate millions of new users whose businesses are too small or whose needs are too esoteric to even consider SAP's complex, one-size-fits-all packages, which can anecdotally cost a fortune and take years to implement. But, as previously mentioned, SAP's reputation as a partner is mixed and companies, ISVs in particular, will need to provide clearer proof that it is a trustworthy partner. This will require a cultural change within SAP that will not happen at once.

SAP will also need to simplify its pricing strategy for the various components that comprise NetWeaver. At this time, its pricing strategy remains a work in progress, creating a danger of customers buying less software from SAP per se and more from ISVs. While SAP has been discussing some pricing models, many are based on actual transaction volume. This may be fine for those companies that sell products in bulk, for example bulk chemicals, but for those companies that sell a multitude of low cost, high volume products, the transaction model could be cost prohibitive.

In addition, SAP will have to clarify fairly soon how its recently acquired Lighthammer technology will be integrated into the NetWeaver stack (beyond now being part of SAP xMII), how it will be licensed to other software vendors and SAP customers (i.e., whether it will be a central piece, or the independent business units can dictate their own rules), and how its lack of a persistent data model for multiple industries will be addressed down the track. In other words, the role of SAP xMII relative to SAP NetWeaver and its partners' solutions needs further clarification. Moreover, the standardization on the SAP end of the integration is also limited by the dearth of business process standards, which will force manufacturing user enterprises to use different solutions from different SAP partners and to have continuing custom work done.

Beyond the issue of integrating Lighthammer technology into NetWeaver , Lighthammer technology was meant to help SAP's enterprise services architecture (ESA) enable interoperability for manufacturing companies. SAP expects that by embracing ISA-95 and other open standards, together with leveraging the SAP NetWeaver's XI component for manufacturing interoperability, SAP XI and will be able to (it already has in some cases) connect internally to many appropriate modules, such as SAP Production Planning (PP), mySAP SCM, SAP Plant Maintenance (PM), and SAP Quality Management (QM) via remote functional calls (RFC) or intermediate documents (IDoc) to execute such tasks as "Control-Recipe-Download", "Create-Multiple-Process-Messages", "Maintenance-Request", or "Maintenance-Response". Externally, SAP XI can currently connect to other strategic integration platforms or plant floor systems, but standards-based interoperability will eventually allow business processes, or scenarios, to be fairly easily deployed across boundaries, thus supporting SAP's ABN vision.

The partner ecosystem includes support from SAP, such as knowledge transfer and fast track support, and a certification program to encourage high quality partner packages. For certification through the new "Powered by SAP NetWeaver" program, SAP requires that partners use NetWeaver XI and at least one standard in each package. The vendor reports that 125 companies have signed to become partners, create pre-build business value packages, and then work to get them certified.

User Recommendations

SAP NetWeaver and ESA, with its postulates of user productivity, embedded analytics and reports, applications composition, service-enablement, and software lifecycle management, is maturing to a level where broader adoption across the SAP customer base is possible. For those companies that have made the decision to source the majority of their enterprise software applications from SAP, this platform should be the leading contender for the foundation of their future SOA forays. They should begin seriously considering it (bearing in mind all pro et contras, see What's Wrong With Enterprise Applications, And What Are Vendors Doing About It?), since if they do not eventually deploy ESA, the expected benefits of using SAP will not be sustainable in the long run.

For companies that have a more heterogeneous mix of enterprise applications, coupled with a strong SAP ERP backbone, SAP ESA's support of numerous standards again makes it a strong candidate. The SAP Interoperability Certification Initiative is a positive step that should give manufacturing solutions a longer life and potentially better support. Although the industry's current level of interoperability is at a medium level of maturity at best, and is limited by current standards and techniques, the partner ecosystem provides a place for exploring the next level of interoperability as the supporting technologies and standards evolve. SAP users evaluating plant intelligence solutions, especially if they are comfortable with NetWeaver and are in process industries, should seriously consider SAP xMII.

However, generally speaking, although SOA is an innovative methodology for leveraging technology to improve business processes, although SOA migration should be gradual rather than big-bang-like and less hardware-driven than previous computing waves, and although users typically benefit when a few large, deep-pocketed vendors compete to deliver applications that provide highly flexible business processes in an SOA environment, users should be aware of the many caveats and difficult transition decisions (even if this is a point of no return). Namely, owing to the piecemeal, multi-year, multi-phase renovation that is necessary in order to lessen migration issues, customers will have to have a series of multiple upgrades.

Moreover, as in highway construction, detours often cause hold ups, and the sum of all migration costs could ironically exceed the big-bang efforts of an earlier era. There will also be a lengthy transition from traditional product modules to SOA-based processes and applications, transition of user interfaces (UI), migration of data marts and warehouses, replacement of existing integration platforms, the management of potentially thousands of software components, decisions on their granularity, and so on. This pace of change, when bundled with the requirements for possibly rapid transformation, might leave many users feeling restricted by the vendor, rather than empowered.

After over more than thirty years of existence, enterprise applications leaders have lately added many advanced components. Yet the original application model has not had the major architectural overhaul required (see Rewrite or Wrap-Around Old Software?), resulting in newer enterprise applications suites that are more complex and far more expensive to operate than "younger" competing products with more recent architectures.

The restructuring of product sets around SOA might have sweeping consequences on the products. It might also result in the multiplication of product license and installation costs. As for the transition to next-generation suites, it is likely that leading vendors will charge for upgrading current licenses. In addition, many new-generation SOA-enabled business suites cannot operate on one single system or instance as their monolithic client/server counterparts could. Rather, they are a family of systems where each member is somewhat different, whereby many functions exist in several product variants. Consequently, their release cycles are often not synchronized and it has become increasingly difficult to manage this complexity, even if one forgets about the likely necessary extensive customization of current legacy systems.

Thus, while the size of the partner ecosystems should be watched, one should also observe which vendor achieves a fully SOA-based enterprise suite first, given that no vendor has yet completely rewritten all its functions into fine-grained services. For example, SAP has envisioned a scenario where, to fully benefit from the business objects, it may require as many as 30,000 enterprise services to meet all of the various unique vertical requirements. This is a colossal mission, despite SAP's attempts to define objects and services across only a single platform (as opposed to some competitors' distraction of trying to assimilate some major acquisitions).

The market is still a few years away from knowing even remotely how much it will cost and how long it will take for existing customers to move to SOA-based systems, and the same holds for performance, manageability, security, and other related issues. While the current set of products is complex and expensive to run, extend, and upgrade, newer technology, such as Web-based portals and Web services, are not native to the product set but are rather belated add-ons. Also, the next generation of SOA-based suites will feature a myriad of software components that will largely have to communicate asynchronously (i.e., whenever the other component is able to respond), making it hard to determine the exact time a business process will take to complete.