In January 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).
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. (See Part Two for details).
However, building xApps has not been an easy feat as shown by only a few of them developed so far. Most of them are still a figment of someone's imagination and will require too much of custom work until becoming tried-and-true and reusable. Each individual cross-application will involve sophisticated process modeling and process-level, data-level, and UI integration, and often it will involve creating and supporting a system of record that comprises data from multiple systems (i.e., MDM). Even after all that effort beforehand, the wide variety of technologies and formats of various independent software vendors' legacy solutions one can encounter in any new application for some xApp, will inevitably mean some tweaking anew.
Most likely, therefore, SAP will develop integration capabilities internally only for selected most widespread alien' applications in the SAP-controlled environment, such as Siebel in CRM, i2 in supply chain management (SCM), Ariba in e-sourcing, Indus International in enterprise asset management (EAM), or PTC in product lifecycle management (PLM) areas. Although the new architecture blueprint provides SAP with a more open approach to integrating its applications with others, it is also reinforcing SAP's ability to maintain account control in these multi-products environments. That might feed some skeptics' belief that "a wolf may loose its teeth but not its nature" and their conviction in SAP's ulterior mode for developing these (i.e., to regain its exiled customer base by incrementally selling add-on functionality to, e.g., Siebel's or Manugistics' modules). By delivering xApps also as the bridge between mySAP Business Suite applications, e.g., linking order management module within mySAP CRM to SAP Advanced Planning and Optimization product (mySAP APO), for global Available-to-Promise (ATP) functionality, might alleviate the above doubts.
Then again, one has to be careful to prevent xApps from becoming an internal competitor with the core product suite development. At the moment, SAP is not clear about which mechanism will, for example, prevent the core CRM or PLM teams from developing functionality as part of its application suite that might compete, duplicate or even cancel out work done in a xApps delivered either by SAP or a SI/ISV partner. Although the concept is plausible, time will only tell how SAP will execute and whether it can promote the idea among partners and customers given some xAPPs developed by partners will be only higher level integrations while others will have to invest a great deal in re-implementing major product functions on NetWeaver, which are a business and risk consideration.
SAP's endeavor to encourage its partners will additionally require development of new business process modeling tools and software development kits, exposing additional application programming interfaces, and a lot of market education. Yet another challenge will be in managing relationships with each system integration 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 system integration 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.
SAP's NetWeaver/EAS approach will by no means become a real product easily and quickly, given it has taken several thousands developers only to lay down the concept. One should dare to do the math of a mere volume of the imminent work that is ahead of SAP and its partners to offer almost out-of-the-box' integrated functionality in shape of a pre-built library of business processes. Now, at least by the above mind boggling announcement and description of ESA, it may be clearer how complex, e.g., CRM integration is so that a client can obtain an enterprise wide view of customers and share it accurately across all channels and divisions. One should imagine how humongous the job of delivering plug-and-play packaged middleware components for a number of other disparate applications SAP will attempt to enshroud in its xApps will be. In practice, the drawbacks of heterogeneous environment will not be eliminated while communication between disparate applications will be eased, matching the business model across these remains the challenge and remains subject to individuals' business acumen.
The caveat also remains that in the guts of the applications much of SAP technology will continue to be implemented in its proprietary ABAP/4 technology, but 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 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 a proprietary unwieldy architecture.
It might be very likely that users will opt to exploit Java or .NET for presentation components and ABAP for data-centric components. Again, NetWeaver does not provide direct interoperability between J2EE and .NET, but rather only connections, which means SAP will continue to compete with these vendors on many fronts (including the application server), while the customers will remain bamboozled by the choices' nuances and will often have to customize the delicate fabric between separate platforms, with ESA and NetWeaver in between. 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, then users might prefer to entrust themselves to EAI/middleware vendors rather than to less experienced likes of SAP.
Marketing Challenges
SAP's challenge will also be the articulation of business benefits of its latest technological infrastructure. There is still lingering market confusion over mySAP Business Suite's (that very recently supplanted the mySAP.com moniker) value proposition to both existing and potential customers. As the market leader continues to evolve from functionally broad ERP-centric processes and closed monolithic architecture, to processes that encompass the entire value chain, with open architecture, it is of paramount importance for it not to fall in the trap of yet again confusing the market with a jumbled message.
In addition to an ongoing confusion due to frequent product renaming, complex licensing scenarios and module interdependencies, SAP's professional service personnel and its SI partners have lately been further aggravating the problem by referring to almost every product as xApps. While indisputably a compelling proposition, the ESA is based on still moving-target' technologies, with lesser market awareness. The terminology and message simplification for average customers still remains wide-open game.
Still, challenges notwithstanding, SAP has at least begun to tackle them, whereas its competitors will only be faced with these integration platform needlepoint' conundrums the fabric, the picture schema, and the strings colors some time in the future. The blueprint is a positive first step toward greater interoperability in a multi-vendor world. While the xApps concept might not have the complexity of quantum physics, the delivery of applicable products certainly has. SAP's competitors should moreover realize that devising a counterpart strategy will not happen that easily, or overnight, unless they want to risk it looking like an obvious me too' value proposition.
User Recommendations
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 and/or who need to exchange information with their business partners that are not SAP shops. Still, while SAP's new technology blueprint is impressive, the market has often in the past witnessed how long the road is between the vision and execution, SAP's huge resources notwithstanding.
Details about the services-oriented architecture are indeed still vague, but SAP seems poised to build all of its future products on the NetWeaver technology stack and have all future products comply with the architecture. SAP has not announced specific dates about when existing products will be moved to the ESA and NetWeaver technology stack, but mySAP CRM 3.2 and my SAP R/3 Enterprise run on pieces of NetWeaver today. Also, the newly released xApps and portals are built on the NetWeaver components.
Yet, the architecture will not benefit SAP customers until products built on it begin to appear en mass. Therefore, potential and current SAP customers with hefty integration requirements should not depart from their short-term IT investment strategies. They should also consider third-party EAI alternatives, particularly if the large corporation is looking to build integrating middleware standard corporate-wide and in the long term. Moreover, users should question SAP's delivery fulfillment of its strategy and appreciate that migrating older instances of SAP R/3 to R/3 Enterprise and/or integrating mySAP Business Suite components to other software will remain painstaking for some time to come, despite SAP's commendable initiative in easing that.
Participation in SAP's industry interest groups or so, as to provide ideas/feedback to xApps development is highly encouraged. NetWeaver should eventually provide for all the integration the enterprise might require with existing and emerging IT requirements, with full IBM WebSphere (i.e., J2EE) and Microsoft .NET interoperability.
Users anticipating projects only in a year time framework should examine the announced technologies bearing in mind the maturity factor. They should also comparison shop with other renowned available products.
Early adopters should observe the J2EE/.NET-based components performance compared to their ABAP-based counterparts. While the coexistence of Java, .NET and ABAP is comforting for existing users, they should consider the appropriate skill-sets of their developers. 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.
Further, although the widespread acceptance of Web services implementations will not happen any time soon, all enterprises should start learning the new protocols, standards and technologies in order to grasp the underlying business advantage of Web services, and to shift away from the software-centric mindset of largely outgoing client/server perspective. Since SAP ESA should become the standard for SAP's own solutions and, with the prospect of enterprise scale usage of Web services, that might be a sound roadmap for avant-garde SAP users.
SOURCE:http://www.technologyevaluation.com/research/articles/sap-weaves-microsoft-.net-and-ibm-websphere-into-its-esa-tapestry-part-three-challenges-and-user-recommendations-16896/
0 comments:
Post a Comment