SAP NetWeaver, has become the main pillar of SAP AG's (NYSE: SAP) strategy to remake itself into a platform vendor. With this and mySAP Business Suite, the broadest suite of enterprise applications in the market, SAP will sell possibly everything from application servers via middleware to Web services (envisioned, in SAP's case, to orchestrate business processes by means of packaged composite applications across and/or atop existing systems). In mid July, SAP announced that it has acquired substantially all of A2i, Inc a Los Angeles, California-based (US), privately held software company, which, since 1993 develops and markets xCat, the platform for enterprise-wide product content management (PCM) and cross-media catalog publishing, but with the touted simplicity and accessibility of desktop applications.
The devil is always in details, such is the fact that xCat is not currently working on SAP NetWeaver. Moreover, the current integration is offered merely through iViews, which are SAP's brand of portlets, which A2i has already developed to work atop SAP Enterprise Portal (SAP EP), because of A2i's readiness to partner with many providers, including IBM. Hence, the integration might not be that daunting, since both vendors have embraced open systems, particularly A2i, given that its software by nature always had to integrate with several disparate data warehouses and applications or platform, including IBM WebSphere, SAP Web Application Server (SAP Web AS) and SAP EP.
Still, time only will tell whether the future SAP Global Data Synchronization (SAP GDS) product will be released as planned in late 2004, when one can discern how truly easy it is to integrate xCat. Further, SAP plans to integrate xCat functions like high-speed data normalization and taxonomy management more firmly into the SAP MDM component in the next two years or so. Things get somewhat more complicated there by the fact that SAP MDM remains the only SAP NetWeaver component that is not included in a synchronized release cycle—it remains on SAP Web AS 6.20, whereas all other 2004 release components are already on SAP Web AS 6.40, whose common technical foundation simplifies a wide range of infrastructure activities, including administration, monitoring, and user and security management. SAP is reassuring its current customers and prospects that it will stomach the burden of this migration.
This brings us to the fact that SAP, even with the A2i's expertise, will not soon become the leader in PCM, product information management (PIM) or GDS, particularly given that these areas have become A2i's focus only during last year or so. One threat comes from its competitive partner IBM, which, with Trigo's acquisition, has the wherewithal of a PIM/GDS tool nestled within a larger application platform. Trigo had long developed solutions that provide the missing link in the demand chain, as successful channel management requires an effective combination of content/catalog management, syndication, order processing, and enterprise class workflow security and infrastructure (see Trigo Helps Suppliers Connect).
Other notable competitors in the PIM/GDS space are GXS, Velosel and Sterling Commerce. The latter has recently acquired data synchronization vendor TR2, and the combined Sterling-TR2 product should provide a broad, reasonably priced application for CPG and retail companies that are just trying to comply with their retailer's GDS mandates and send data to UCCnet. With the highest number of live customers, the combined Sterling-TR2 entity is now the absolute leader in the number of customers on-boarded to UCCnet—nearly 600. Sterling now also provides a less expensive hosted option to simply deliver data to UCCnet. This is particularly attractive to mid-market manufacturers and retailers that do not necessarily require the sophistication of a content repository or a PIM system. Also, TR2 has thereby provided a nifty cleansing tool and a service that Sterling customers can use, given this is a mandatory, but still often overlooked part of synchronization initiatives. Moreover, the data cleansing effort to prepare for synchronization is often multiple times the work and cost of publishing that data, and most vendors do not offer much, if any assistance, leaving the burden on the manufacturer to gather, cleanse, and normalize the data.
Given this competition and the nascence of SAP MDM, which has so far mainly been used for data cleansing and synchronizing between applications, without the product data repository, it is no small wonder that at best 15 percent of SAP customers see the vendor as "the center of the universe" for their PIM and GDS needs. One should particularly bear in mind that IBM has a big chunk of SAP implementations, which will naturally be navigated towards the WebSphere-Trigo combination when it comes to PIM and GDS. Thus, while IBM has a strong services motivation in PIM/GDS, SAP's response naturally has to be a more rounded product. SAP believes A2i' differentiating trait against the competition is the scalability and the ability to cover many vertical sectors (other than CPG and retail), due to its well devised horizontal foundation and appeal.
Yet, predefining and pre-populating these solutions with a master data model specific to a given vertical will be crucial to make these solutions affordable, because, without these vertical data models, the cost of customization becomes prohibitively daunting. One should imagine the magnitude of the impending effort, given SAP's appetite in over twenty industries. Although SAP has had some practice spreading out vertically, developing these products in-house may prove to be too slow and expensive even for a vendor of this size, which may indicate further acquisitions.
Alternatively, SAP's endeavor to encourage its partners will additionally require development of new business process modeling tools and software development kits, exposing additional APIs, and a lot of market education. Yet another challenge, owing to the fact that any MDM vertical initiative will require much consulting on top of the out-of-the-box software solution, will be in managing relationships with each SI provider, given a broader SAP portfolio scope places many integration problems in SAP's camp, even when the domain knowledge resides in the partner's organization. To that end, SAP should promptly articulate how, for example, problem reporting and escalation will work and who will be in charge/owner of which part of the solution. Given a number of conceited competing firms in case, one should expect a contest for the most favored SI partner in this arrangement. In order to diffuse consternation and SI's attempts to embed their proprietary technology as to create dependency on their product (which would defeat the purpose of touted universality), SAP might want to select a preferred provider for each specified industry or a certain product line.
The xCat product, despite its undisputable strengths that were outlined earlier on, also has some weaknesses, such as the lack of browser-based administration and the fact that managing client-side applications can be done only in Microsoft Windows. Also, the product's focus is mainly on merchandising, marketing or data synchronization, whereas some other competitors like Enigma, provide much stronger offering for aftermarket activities. Maintenance manuals and illustrated parts catalogs are a large part of the daily grind of engineers, service, and warranty experts, and the rest of the aftermarket in general, where many SAP customers belong. Regular maintenance of catalogs is therefore essential, not just because of safety and regulatory requirements, but because the aftermarket is the demand medium for these manufacturers, and the catalog is the means by which they procure.
This is Part Five of a five-part note.
Parts One and Two detailed the event summary.
Part Three discussed the market impact.
Part Four looked at SAP and A2i.
Technology Integration is Key
A caveat also remains: in the guts of the applications much of SAP technology will continue to be implemented in its proprietary ABAP/4 technology. However, the provision of XML and Java interfaces and publishing applications as Web services should ease the integration effort for SAP customers notwithstanding. However, the litmus test of the SAP NetWeaver's collaborative innovativeness will be in whether users can integrate J2EE/.NET-based applications into their SAP environment without tweaking it again in ABAP. Otherwise, this will be regarded as yet another sugarcoating of proprietary unwieldy architecture.
Though other languages can be used with great results, particularly Java with its synchronous communications support, ABAP/4 still is unrivaled for flexibility and convenience in customizing SAP applications. To really excel at SAP application development, one needs to acquire the mindset behind SAP's structuring and accessing of data, and become familiar with its infrastructure and specific programming conventions, which ABAP certainly embodies the most.
It might be very likely that users will opt to exploit Java or .NET for presentation components and ABAP for data-centric components. In other words, if users want to do process changes, they will most likely have to use ABAP, while building new processes can be satisfied with Java. Again, SAP NetWeaver does not provide direct interoperability between J2EE and .NET, but rather only connections, which means SAP will continue to compete with these providing vendors on many fronts (including the application server), while the customers will remain overwhelmed by the choices' nuances and will often have to customize the delicate fabric between separate platforms, with SAP NetWeaver in between.
On the other hand, it might not be in SAP's interest to completely commoditize packaged applications either— should all systems be equally accessible and the same function is available from multiple different enterprise applications vendors, while the integration is basically the same. As a result, users might prefer to entrust themselves to EAI or middleware vendors rather than rely on less experienced ones like SAP. IBM's recent foray to round out a strong ECM offering also speaks volumes in that regard.
This is, by all means, good news for SAP's existing customers, particularly for the large corporations that need to integrate their internal applications with applications from other vendors or who need to exchange information with their business partners that are not necessarily SAP shops. The announcement may come in handy for SAP customers looking for a product catalog and PIM solution, while it should generate increased viability confidence for many A2i customers, who should immediately explore how the tight integration into the application stack via SAP NetWeaver and SAP MDM might benefit them. In the short term, the A2i proposition is still aimed directly at large companies who routinely use outdated, and very expensive, technology to build paper, CD-ROM, and web catalogs.
SAP customers waiting for MDM to address data synchronization initiatives can be confident that, in the long term, SAP will likely address consolidation of product data for more purposes than a mere compliance to retailers' mandates. Still, while SAP's new technology blueprint is impressive, the market in the past has often witnessed how long the road is between the vision and execution, SAP's huge resources notwithstanding. SAP customers in the consumer packaged goods (CPG) and retail value chain that are embarking on GDS/PIM should, therefore, wait until SAP makes SAP MDM generally available and fully integrates A2i into it, within next year or in a longer timeframe. Still, many Tier 1 SAP CPG and retail customers that have made other PIM/GDS commitments may be wise to revisit their decisions (and at least test the combined SAP-A2i offering with non-SAP data outside the enterprise), especially if their approach was a point solution or internally developed PIM solutions. That may particularly be the case for those using A2i/IBM, SAP/Trigo, and SAP/Requisite combinations, given these partnerships may now naturally stall and provide only few enhancements from here on.
On a more general note, firms considering PIM solutions should use evaluation criteria that cover vendor viability, product functionality, and other product-related criteria like pricing, openness, extensibility, and security. The complex enterprises with large numbers of items and GTINs should consider the likes of SAP and IBM that are soon to have PIM/GDS capabilities. Also, the finished goods' information (attributes and specifications) should be included in the NPDI process and treated in a same manner like other PLM information during its typical steps of create, edit, collaborate/share, release, retire, and archive. Only by doing so will PIM infomation be accurate, current, secure, and supportive of collaborative processes, which is not the case with current practices of managing the PIM info separately in isolated repositories of spreadsheets.