SAP Weaves Microsoft .NET And IBM WebSphere Into Its ESA Tapestry Part Two: Market Impact

SAP AG (NYSE: SAP) announced its Enterprise Services Architecture (ESA), the blueprint for complete, services-based architecture business solutions, which should eventually allow companies to drive additional business value from existing increasingly legacy-status technology investments, and enabling, possibly for the first time, enterprise-scale usage of Web services. The announcement included a new product SAP NetWeaver, the first enabler of the Enterprise Services Architecture. SAP NetWeaver is an immediately available, services-oriented platform for all SAP solutions, which should allow organizations to integrate people, information, and business processes across technologies and organizations. (See Part One for details).

Having embarked on a long (and likely a never-ending) journey to keep abreast of cutting-edge enterprise infrastructure platform requirements, while, at the same time, not leaving technologically laggard customers in the lurch, SAP continues to slowly but surely simplify its overwhelmingly piled up maze of tools, frameworks, methodologies, applications, and what not, with ever-changing naming conventions. SAP has been incrementally executing what it committed to way back at SAPPHIRE 2001 when it first unveiled product architecture as the modern technical underpinnings of its broadly functional applications (see SAP - A Humble Giant From The Reality Land?).

If those announcements sounded grandstanding and bedazzling at that time, then the latest announcements, although still slightly mind-numbing, would be the next iterative fleshing out of the vision. Having the largest market share and the broadest offering among enterprise application providers inevitably represents a double-edged sword, as it also brings with it a major challenge of new technology introduction and new application deployment, while ensuring that it spare existing customers from any shock-therapy-like changes. SAP indeed seems to have been dedicated to it, with some initial signs of a success.

While some may jump to the criticism that NetWeaver is a spruced up and more astutely renamed (i.e., now having a real product association) collection of long-existing technology tidbits that was previously less-compellingly marketed as mySAP Technology, the true importance lies in the fact that SAP might have finally seen the light at the end of the awfully long tunnel of developing its future platform upon which all new modules will be built. As seen in the Event Summary, NetWeaver features SAP Enterprise Portal, SAP Business Intelligence (BI), SAP Business Information Warehouse (BW), SAP Exchange Infrastructure (XI), and SAP Web Application Server (WAS), which have all also been outlined within mySAP Technology at the end of 2001.

This is Part Two of a three-part note.

Part One detailed the SAP announcement.

Part Three will cover Challenges and make User Recommendations.

SAP Web Application Server

The SAP Web Application Server (WAS) still provides Web services through platform-independent, maintainable business Web applications and technologies, which encompass J2EE and ABAP, and newly embraced connectivity with other unavoidable technologies such as .NET. In addition, with Web Dynpro, the WAS provides a Web development tool and runtime environment via a presentation layer technology that should allow device-independent user interfaces (UIs) to be rendered in either Java or ABAP environments, and again, with the future support for .NET environments. The product uses smart' forms to replace SAP original scripts, by which SAP hopes to greatly reduce nearly 2,000 less-compellingly looking forms in its applications.

The portal infrastructure still provides user-centric collaboration based on data unification and role management capabilities that deliver relevant information to users, easing navigation and allowing people to work smarter. With a common, seamless point of entry across disparate systems and information sources including any back-end system the user will be presented with only relevant personalized information and should therefore make the best decisions based on previously invisible informational relationships.

Last but not least, the exchange infrastructure provides process-centric collaboration based on shared business knowledge for designing, configuring, changing and executing collaborative business processes. Its realm of operation is in tying together processes across multiple applications.

SAP has since spent time enhancing these former mySAP Technology products, by delivering the 5.0 version of its portal, the 3.0 version of BW, and the 1.0 version of the XI. The products have even reportedly gained momentum in the market, with SAP reporting over 500 new portal customers in the last year.

One of the more exciting products preceding NetWeaver (i.e., its MDM part) was the Collaborative Master Data Management (CMDM), which ties the notion of cleansing all of the data in many dispersed systems of record. This means not only having one unified copy of the customer, supplier, employee, or item master (rather than dozens), but also understanding the context in which, e.g., items are linked to products, stock item or spare parts record. The fact that SAP has been developing this initiative with several prominent corporate customers, including Dow, Motorola, and Nokia, might give some vindication to Oracle's long-touted notion of a single database with a single data model underlying all business applications, creating a so-called "single version of the truth" for all enterprise data (see Stalled Oracle Fumbling For A Jump-Start Kit).

Competitive Strategy

While SAP has not been known for speed, its holistic and meticulous approach to new product delivery this time again may give customers some breathing space between adopting new software standards and solutions, while at the same time upgrading and maintaining custom legacy environments. Oracle, J.D. Edwards and PeopleSoft, on the other hand, while gaining market shares with their respective groundbreaking technologies a few years ago, have felt the displeasure of client bases that were far from being ready to make a significant technological leap. As a result, these vendors had to backpedal and rethink their older product releases discontinuation strategies.

We believe that with NetWeaver and ESA, customers should benefit from both the strong heritage of SAP and its recent acceptance of the open integration reality, since its traditional strengths of scalability, broad functionality and mission-critical performance are now extended to both J2EE and .NET. Like its predecessor mySAP Technology, NetWeaver is envisioned to reduce the pain of abrupt, disruptive shifts in technology with continuous, evolutionary improvement.

As a result of this evolutionary approach, customers should be able to modify, enhance and adapt individual Web services without changing other services, mitigating the need for the huge technology platform shifts and upgrades of the past disruptive technology advents. This should in principle allow companies to protect existing investments and add new functionality that can be reasonably easily designed, built, deployed, accessed and combined with existing Web services and syndicated across division, company and geographic boundaries.

The NetWeaver platform should eventually give SAP a strong foundation for bridging its existing predominantly ABAP-written applications and the rapidly expanding collection of Web standard-based applications. Without having to rewrite its existing applications in Java or .NET, SAP users should now be able to play in both worlds. Once they have deployed the new application server to run their SAP applications, users will be able to develop their own custom applications in more pervasive programming languages and Web services without necessarily having to purchase, deploy, or maintain an application-independent proprietary third-party application server.

SAP hereby maintains its focus on solving down-to-earth' business problems and on positioning itself as a strategic partner to its customers. Particularly during these times of risk-averse customers, SAP's aura of a stalwart vendor and its prudent approaches to solving customers' business problems have become even more attractive and assuring both to its huge customer base and to new prospects. SAP's current posture is also the result of several years of a painstaking effort to radically change its business philosophy, to reinvent itself into a more nimble setup, and to reverse bad market perception.

The company has by and large made the right strategic decisions it has embarked on making its proverbially unwieldy R/3 product more granular and open, and it has delivered attractive ERP-adjacent components that harness its latest technology foundations, given the demand has been moving from the center to the outskirts of any enterprise, and interest in solutions that promote collaborative communication throughout the entire value chain is ever-rising.

SAP has to that end been pursuing the right avenues to technologically keep its product abreast of the latest market trends. Its recently unveiled Internet-based product architecture roadmap that includes Web services, portals, exchanges, BI, BPM and Web Application Server (WAS) bundled with its knowledge of business processes should bode well for promoting it into one of a few vendors that will be able to provide applications infrastructure foundation (an enterprise-level equivalent of operational systems upon which other applications would be able to be grafted). SAP is by no means the only vendor trying to oblige enterprises in their mindset of increasingly seeking business process-oriented interoperable applications.

Competitive Analysis

Oracle with its 9i Applications Server (9iAS) Enterprise Edition, PeopleSoft with its AppConnect, J.D. Edwards with its eXternal Process Integration (XPI)/eXternal Business Process (XBP), Invensys/Baan with its ArchestrA/OpenWorldX, IFS with its IFS Connect (see IFS To Be At Customers' (Web) Service) and Siebel Systems with its Universal Applications Network (UAN) (see Siebel Rallies Its Integration Alliance Troops) have all laid out pieces of their enterprise platform roadmaps. However, hardly any of the above can, at this stage, claim the content and multi-layer comprehensiveness of NetWeaver/ESA, nor the ability to wholeheartedly embrace both .NET and J2EE frameworks at all the above levels of integration.

The battle for ownership of the collaborative infrastructure platform has been raging for some time now (see The Application Server War Escalates), with increasingly blurred demarcation lines between network, database, middleware and application components. SAP's introduction of its WAS back in 2001 was a noteworthy move, as it had long been the remaining major piece of the puzzle for its integration platform offering (given it has conceded Microsoft's supremacy on the desktop, and Oracle's/IBM's supremacy in the database realm).

The company had thereby made a major shift from providing points of integration' solutions through its data access engine called Business Applications Programming Interfaces (BAPIs) running over a proprietary remote procedure call (RPC) protocol called RFC (Remote Function Call). SAP WAS would consequently provide a strategic integration platform for its customers, allowing SAP to more elegantly offer possibly a complete collaborative solution even when some of the component applications are not natively provided by SAP (that was possible via multiple BAPIs though, but in quite a cumbersome way).

Furthermore, its Exchange Integration superseded SAP's proprietary enterprise applications integration (EAI) architecture called Application Link Enabling (ALE) that was mainly suited for asynchronous transaction process needs, as a triggering mechanism to set again proprietary SAP IDocs (Intermediate Documents) in motion as a means of data flow between SAP modules and/or to third-party modules. Consequently, at first sight, NetWeaver addresses the major infrastructure requirements of an exchange platform, including internal integration within a single company and external between companies, business process workflow across applications, identity/role management, and content management. The power users' (rather than programmers' per se) ability to dynamically write business process rules and to share them internally and externally, might give other vendors pause and force them to come up with their equivalent solutions.

Given the leadership position and the consequent influence, SAP's decision on any technology carries significant specific weight. To that end, having a company with the stature of SAP supporting componentized Web Services technology is likely to increase the concept's awareness and speed up its still fledgling adoption. SAP's endorsement of Web Services technology might help it make up for its latency of endorsing the component (object oriented) technology several years ago. Web Servicces have a potential of becoming the latest evolution of application integration technology and/or a revolutionary new application design model by enabling developers to create or enhance applications by connecting granular components that are accessed via platform-independent Web protocols. With SAP NetWeaver and the Enterprise Services Architecture, SAP will have delivered the blueprint for turning Web services from a concept into business reality of uniting hardware, information, and software platforms & applications.

While Web services leverage the aged concept of objects' reusability, they may finally offer that extra mile by adherence to standards that are taking hold (see The SOAP Opera Progresses - Helping XML to Rule the World). Further, they tend to be simpler in their nature, partly owing to the above collaborative Internet standards, and they also tend to be higher-level abstractions, which implies more likely platform independence and "mixing and matching" opportunity by developers. Furthermore, the strategy will help SAP further open and/or componentize its product, as standards like eXtensible Markup Language (XML) and eXtensible Stylesheet Language (XSL) make it possible to share data and have a common look-and-feel across an application, without necessarily dreadfully digging in the source code.

SAP's decision to support more open standards from popular programming languages like Java, Visual Basic for Applications (VBA) and C++/C# to its support for evolving standards such as XML, Universal Description, Discovery, and Integration (UDDI), Web Services Description Language (WSDL), and Simple Object Access Protocol (SOAP) should give some homework to many enterprise application vendors. Moreover, SAP's initial open preference for Java over the Microsoft's .NET counterpart, and a consequent strained relationship between SAP and Microsoft of late might have been hereby defused. Still, although SAP WAS remains Java-centric (i.e., J2EE will be supported natively, while .NET will have to settle only for a support through a number of adapters/connectors), Microsoft gains some vindication via SAP's investment to integrate NetWeaver with .NET at the levels of development tools, integration platforms, office components, content management and portal. This should be a good enough endorsement for Microsoft to live with (given IBM WebSpehere's similar treatment) and abandon any more open hostility towards SAP.

While it is also not very likely SAP will use this technology outline to aggressively pursue application server or EAI markets, it will certainly make the respective niche vendors' jobs of selling into fertile SAP client base very difficult down the track. SAP might have conceded to the fact that its customers might not necessarily accept the one-size-fits-all mantra when it comes to its functional applications, but SAP hopes they may likely opt for that approach when it comes to the enterprise integration and infrastructure.

Nevertheless, given the nascence of the offering, in the short term, it will not affect nor lessen the value proposition of independent EAI vendors such as SeeBeyond, Tibco Software, Vitria, Mercator or webMethods, or vendors that provide generic application servers, such as IBM, Sun Microsystems, Oracle, Microsoft and BEA Systems. In the long term, however, these will have to devise an answer to SAP's superior business process level of integration and modeling within NetWeaver, in addition to their EAI offerings' mere immaculate transactional performance. Given that SAP expects its users to not only run SAP applications on NetWeaver, but to also be able to run third-party applications and custom applications on it, one might expect to see the commoditization of the infrastructure market down the track. Although integration servers may reduce the disparate applications integration complexity to a degree because all the applications plug into a central hub, the EAI servers themselves tend to be proprietary and non-standard.

xApps

Customers are increasingly desiring to do away with point-to-point integration approaches at that data level (with extensive lists of custom Application Programming Interfaces (APIs) and connectors/adapters) and to replace it with more inter-enterprise ranging integrations, based on business processes that extend beyond the traditional definitional boundaries of a single application suite. NetWeaver seems to fit the description at least within SAP shops, owing to a number of envisioned built-in connections (hooks) in xApps for accessing various legacy databases, drawings, documents or so, and thereby avoid the need for unwieldy point-to-point connections.

The importance of NetWeaver might particularly lie in the fact that it enables SAP and its partners to create the cross-applications from a variety of existing SAP and external systems leveraging SAP's newly delivered tools, frameworks, rules and methodologies. SAP might thereby be able to extend the reach of its core ERP functional modules with a series of xApps, a new combined middleware-application layer that can either sit atop of a heterogeneous applications' concoction or simply be used to overlay and extend an existing SAP infrastructure. They will supposedly feature the following characteristics: 1) being cross-functional, 2) being collaborative, 3) being built with reusable components, and 4) will use SAP's NetWeaver technology stack.

Since xApps will be built on SAP middleware technology, the underlying applications do not necessarily have to be SAP applications, since SAP XI can be used to integrate the different applications and their associated data, while the business process logic not found in existing applications can be incorporated into the xApp by developing on the SAP Web Application Server in either Java. .NET or ABAP.

Whereas the traditional ERP in 1990s superseded many planning, financials, and logistics software islands of information, xApps harness the users' crying need to leverage existing ERP and other legacy applications. Typical enterprise applications are built around functional lonely islands, such as financials/accounting, manufacturing, logistics or Human Resources (HR), and xApps are devised to let users tie together pieces of these different enterprise applications to support a complex business process. For example, a xApp could be built to support a field service customer relationship management (CRM) component that uses service workers' skill information stored in an HR system, parts inventory information stored in the inventory application, and service cars information stored in fleet management to coordinate the deployment of field workers and parts to a repair site.

Since there is not much enthusiasm for another round of excruciating big-bang ERP implementations, pulling existing functional applications together into new xApps should offer companies ways to incrementally improve business processes and fix some functional gaps in order management (or logistics, supply chain, product development/engineering, supplier management, or any other area for that matter). SAP on the other hand will gladly allocate its R&D funds to leverage its existing stacks with newer technologies rather than to develop brand new prepackaged applications. To that end, built into the SAP xApps infrastructure is also the ability to use business analytics and Key Performance Indicators (KPIs) to measure the impact of the newly automated business processes, which borders on BPM. xApps promises companies the ability to innovate and continually improve business processes, leveraging the applications they have long installed. This should sound like music to both sides' ears, as users want more functionality delivered through portals that tie disparate applications and functions together, in a visually seamless manner, whereas SAP certainly has the technical assets to oblige.

http://www.technologyevaluation.com/research/articles/sap-weaves-microsoft-.net-and-ibm-websphere-into-its-esa-tapestry-part-two-market-impact-16895/