1. An a ly z ing the n e eds of c rea ting a SAP PI p la tf o rm in Sweden Department of Computer and Systems Sciences , Stockholm University & Royal Institute of Technology Alper Celik
2.
3.
4.
5. Unbundling and Future Nordic Energy Market ” Unbundling” : Seperation of sales and distribution data ” Nordic Energy Market Consolidation” : They will need more integration
19. Functi o nal Covarage Comparison SAP Microsoft MS Sharepoint NetWeaver Portal Portal Solution SOA on Basis of .NET and BizTalk Enterprise Service Oriented Architecture (eSOA) SOA Architecture paradigm MS .Net, Indigo Web Application Server Application Server MS BizTalk SAP PI Process Integration .Net and Microsoft Server Products NetWeaver Integration Platform
22. Market Share Comparison SAP PI MS BizTalk SAP, Oracle, Microsoft Dynamics, SSA Global Technologies and so on 9 9 % SAP customers Biggest customer segment: 8500 2000 Total number of active users: 10 years 7 years Available in market for:
23.
24. Pop-Up Q u iz What is the percentage of average ERP project b u d get spent on integration?
25. Pop-Up Q u iz 35-40 % of average ERP project budget is spent on integration (Gartner, AMR) Source: 'Cutting Implementation Costs by Application Integration', Gartner, February 2002
31. Analysis and Results A potential vendor lock-in situation with SAP The maturity of MS BizTalk An unclear roadmap of the development of SAP PI Insufficient human competence in SAP PI within and outside Vattenfall Results of Stakeholders Meetings and Analysis
32.
33.
34. 2- Product Roadmap (2) 1999 1992 1972 Year Heterogeneous business processes, lower TCO Scalable integrated business processes, lower TCO Real-time integrated business processes, lower TCO Customer Need mySAP.com, mySAP EP, SAP XI mySAP Technology (Internet architecture) SAP R/3, SAP APO, SAP BW R/3 Basis ( 3-tier Client/Server architecture ) R/1, R/2 ABAP (Mainframe architecture ) New Business Solution Enabling Technology 2003 Packaged composite business processes, lower TCO SAP xApps SAP NetWeaver (Enterprise Services Architecture)
35.
36. 3- Maturity of BizTalk and SAP PI (1) Operational Excellence Product Leadership Customer Intimacy
39. 3- Maturity of BizTalk and SAP PI (4) SAP PI MS BizTalk SAP, Oracle, Microsoft Dynamics, SSA Global Technologies and so on 9 9 % SAP customers Biggest customer segment: 8500 2000 Total number of active users: 10 years 7 years Available in market for:
40. 3- Maturity of BizTalk and SAP PI (5) 3 0 MS BizTalk SAP PI
41.
42.
43. SAP PI Best-Practices 1- midsize SAP clients : mySAP-centric organizations that hadn't selected a strategic integration platform tend to adopt XI as their primary integration platform. 2- large SAP clients : In the past, many of them selected an integration platform, but they're also aware that PI (XI) will be a necessary component of the SAP infrastructure for ESA. Therefore, they recognize that it's important to "understand" the product, so now they're introducing XI alongside their established integration platforms.
44.
45.
46. Marktplace (Internet) Business Partner SAP SAP SAP SAP Third- party Business Partner Final Decision Proposal (2) SAP PI BizTalk Other Systems Other Systems Firewall
47.
48.
49.
50.
51. With that... Thank you very much for your attention Alper Celik Alperc @kth.se
Notas do Editor
A grounded theory has been developed based on the observations and data. Variety of data sources were used, including quantitative data, review of records, interviews, observation and surveys. Also interviewer corroboration method was used in order to establish validity and dependability. In addition to this member check, also known as informant feedback or respondent validation is used in order to improve the credibility and validity. Separate reports were prepared and have been sent to every stakeholder in order to let them comment back on the results. This allowed stakeholders and external consultants to critically analyze the findings and comment on them. The participants [Appendix 7.5] affirm that the reports and findings reflect their views and experiences. Besides that, I have made several presentations to the stakeholders at Vattenfall in order to discuss my views and my final decision. The overall goal of this process was to provide valid and credible results. Moreover, I used a stakeholder analysis tool to examine the interviewer power and influence over the entire project as well as having an interest in using SAP PI. These methods and tools are used in order to have trustable results and to be sure that the findings are evaluated in the right way.
NetWeaver is SAP’s latest application platform suite and the foundation for all future SAP applications. As companies add new SAP applications or upgrade to mySAP ERP, the core components of NetWeaver will automatically be there. For example; Enterprise Portal, Process Integration, Master Data Management, Business Process Management, Business Intelligence. This means SAP PI will be part of SAP investments and it will already be there. Another important fact is that if a company purchases SAP applications such as, Customer Relationship Management, Supply Chain Management, Product Lifecycle Management SAP PI is the standard integration platform from R/3 and other applications to these new modules. Because all of these solutions are built on top of the NetWeaver platform and PI is the integration part of NetWeaver platform suite. So, all of the mySAP licensees have access to this tool set waiting unused on the shelf, if they decide not to use PI. All in all, for large SAP customers it is not a question of “if” it is a question of “when and how much” are they going to use SAP PI. But on the contrary, SAP XI (now called PI) is definitely a “closed” product. It runs on a SAP Web Application Server, which is a combination of a J2EE stack and ABAP stack (ABAP is the proprietary SAP programming language). The core parts of SAP PI run in this ABAP stack, in particular all the queuing and business processes (BPEL). Other parts such as connectivity and adapters runs in theJ2EE stack. Most software assets that are developed in PI are proprietary (maybe except for XSLT transformations). So software components from 3rd parties (such as iWay or Seeburger) need to be customized to run on/in PI. The architecture of SAP PI/XI is definitely closed and proprietary, but so are most integration solutions. On the other hand SAP does endorse a large number of standards: J2EE, HTTP(S), XML, XML Schema, SOAP, WSDL, WS-Security, . Like all the other integration vendors. PI comes out-of-the-box with adapters for JMS, File/FTP, JDBC, HTTP, SOAP and obviously the SAP specific IDoc and RFC adapters. The (XMB) protocol that PI uses internally to communicate between its different components (standalone adapter engines, proxies, other PI instances) is based on SOAP with Attachments (MIME), with proprietary extensions for security and reliability. From the experiences of other people, SAP PI works OK and is a good integration solution that more or less matches the offerings of other EAI vendors. But it is a rather complex product. Now, PI only makes sense if you have a large SAP installation and a major part of your applications are from SAP. In particular, your SAP team can leverage their knowledge to manage an integration solution that runs on the same base infrastructure. If SAP applications only play a minor role in your organization, you might still deploy PI for opening up your SAP applications and SAP-2-SAP interfacing, but you will most likely combine this with other integration solutions. So, because of all these problems and complexity, it is not recommended to use PI outside SAP world right now . But, SAP is investing time and money to make their product more open , simple and powerful . So, just wait and see how PI will penetrate into the main market.
Detailed info about How can we Use and Capitalize on each Strength? How can we Improve each Weakness? How can we Exploit and Benefit from each Opportunity? How can we Mitigate each Threat? Can be found in my reports
Detailed info about How can we Use and Capitalize on each Strength? How can we Improve each Weakness? How can we Exploit and Benefit from each Opportunity? How can we Mitigate each Threat? Can be found in my reports
1- PI will be 100% Java based product. It means, SAP will re-write the ABAP part or make an OEM agreement to replace ABAP with an already available solution in the market 2- Currently, PI is based on hub and spoke architecture. First development of XI (PI) started as a part of MySAP technology but right now SAP has NetWeaver which is more distributed, SOA oriented base technology. So, XI is not a perfect match since it does not support distributed architecture. Because of SAP’s ESOA strategy they need to make integration based on more distributed architecture. By doing that they can dramatically reduce the total cost of ownership and increase availability and performance. So, this will also cause a major change on product. These changes can be done in two ways; 1- SAP will outsource PI to some other middleware company but will continue to development of this product. Because they already sold PI or XI to 50% of their large SAP users and they cannot suddenly stop supporting the product. Also, PI is playing a centric role for SAP’s ESOA strategy. So that, if SAP wants to be successful on this, they have to pay more attention to integration since this is one of the most crucial part of ESOA mentality. 2- SAP will buy another middleware company or make an OEM agreement to add their solution to PI in order to make it 100% Java based and distributed architecture based more open product. So, it is important to keep all these in mind before making a buying decision. As mentioned before, a radical architectural change on PI, rather than an incremental evaluation, is expected. In order to mitigate the risks, it is recommended that to be careful where companies use PI. It is recommended to use PI within SAP landscape and for opportunistic applications, which means not mission critical projects. Also, make a good calculation about ROI. If it is 10 years, changing already established integration platform to PI is not recommended.
Organizations' attitudes toward SAP's integration technology vary. • mySAP-centric organizations that hadn't selected a strategic integration platform (these probably include most midsize mySAP clients) tend to adopt XI as their primary integration platform. They're attracted to its affinity with SAP applications. They don't need the most-sophisticated integration features, such as workflow, BAM or complex event processing, and they don't have very demanding performance and scalability requirements, so XI is adequate. • In the past, many large SAP customers selected an integration platform, but they're also aware that PI (and, in particular, XI) will be a necessary component of the SAP infrastructure for ESA. Therefore, they recognize that it's important to "understand" the product, so now they're introducing XI alongside their established integration products, typically to support medium-scale, mySAP-centric integration projects for internal application-to-application and B2B integration (often as a replacement for Business Connector — BC), where XI can be more cost-effective than third-party products. Although dealing with multiple integration platforms is the norm for this class of company, many plan to gradually align their integration strategies with SAP's. • XI is often used to support ESA early adoption projects, to provide the process flow layer required to implement composite services by orchestrating multiple calls into SAP or third-party (including custom) applications' business logic. Although probably sufficient for experimental SOA projects (that is, a few dozen services and tens of thousands of service calls per day), XI is far from being proven in the most-demanding scenarios (that is, hundreds of services, and hundreds of thousands to millions of service calls per day). By 2009, more than 50 percent of Global-2000-class SAP users will adopt SAP's integration offer primarily to support the most SAP-centric integration requirements (including ESA enablement), but they'll also continue to use one or more competing integration products for the most complex, non-SAP-centric requirements.
During the next 1-2 years Vattenfall should carefully monitor the development of SAP PI and the competence building around this product. If SAP PI becomes more mature, widely used in the market and has more clear vendor product strategy, Vattenfall might use SAP PI even for SAP-to-NonSAP and NonSAP-to-NonSAP scenarios. It is also crucial to understand the companies’ application landscape and then make a final decision to go for one integration platform. Because in fact, it is really difficult to say PI is definitely better than BizTalk or vice versa. Giving an example, many large SAP customers already selected an integration platform. But, they also know that PI (XI) is required component of some SAP modules. Therefore they try to understand the product and decide how much they are going to use it. As far as seen on the market, they are introducing SAP PI along with their established integration platform, mostly to support SAP-to-SAP integration scenarios. Where this looks like an advantage, most of the companies do not want to deal with two different integration platforms. In this case, if a company wants to adopt their integration platform strategy with SAP, gradually moving to SAP PI is the best way to go for. Because, as a result of the research, SAP NetWeaver PI will have a revolutionary change and this can cause serious problems for old PI investments. In addition to this, it is for sure that replacing all BizTalks with PI is not really a strong business case, because PI is still not a perfect product and needs a bit more real life experience. After 4 months of research about ESOA and SAP PI, the researcher makes two predictions about future of SAP PI; 1- PI will be 100% Java based product. It means, SAP will re-write the ABAP part or make an OEM agreement to replace ABAP with an already available solution in the market. 2- Currently, PI is based on hub and spoke, centralized architecture. Development of XI (PI) started during the time when SAP had MySAP base technology but right now SAP has NetWeaver which is more distributed, SOA oriented base technology. So, XI is not a perfect match with SAP’s NetWeaver base technology and ESOA mentality since it does not support open standard based, distributed architecture. Because of SAP’s ESOA strategy they need to make integration distributed and open architecture. By moving to more distributed architecture, they can dramatically reduce the total cost of ownership and increase availability and performance. So, th ese will also cause a major change on product. These changes can be done in two ways; 1- SAP will outsource PI to some other middleware company but will continue to development of this product. Because they already sold PI or XI to 50% of their large SAP users and they cannot suddenly stop supporting the product. Also, PI is playing a centric role for SAP’s ESOA strategy. So that, if SAP wants to be successful on this, they have to pay more attention to integration since this is one of the most crucial part of ESOA mentality. 2- SAP will buy another middleware company or make an OEM agreement to add their solution to PI in order to make it 100% Java based and distributed architecture based more open product. So, it is important to keep all these in mind before making a buying decision. As mentioned before, a radical architectural change on PI, rather than an incremental evaluation, is expected. In order to mitigate the risks, it is recommended that to be careful where companies use PI. It is recommended to use PI within SAP landscape and for opportunistic applications, which means not mission critical projects. Also, make a good calculation about ROI. If it is 10 years, changing already established integration platform to PI is not recommended. To sum up, both integration solutions have bad news – good news situation. As PI adoption grows, SAP will invest more into this technology. But if they want to penetrate into the main market, they have to enrich the functionality of their solution against competing integration platforms. Because current picture clearly shows that PI is dominantly used only by SAP customers. While this can be seen as a success, there are still lots of miles to go for SAP. Both integrated middleware approach (SAP PI) and best of breed approach (SAP PI + MS BizTalk) has pros and cons. So, it is up to company to decide which way to go. As mentioned earlier; unlike "Who Wants to be a Millionaire," there is not a "final answer" to this ongoing debate. After all, the result of the research is to use BizTalk for outside SAP world and SAP PI for SAP-to-SAP at Vattenfall for one or two years and then, if required, make a benchmarking to select only one middleware solution. As a summary of SAP NetWeaver PI (XI); Product Strengths: Part of NetWeaver application packet Highly optimized for SAP-to-SAP integrations Prerequisite for some SAP applications and for ESOA Infrastructure of some SAP products for example BM, DM, Auto-ID Has lots of pre-built content for SAP-to-SAP integrations Challenges: Synchronous scenarios and large file sizes cause performance problems Needs lots of memory and CPU power Very high TCO if you use it outside SAP landscape Smaller market share than leading competitors Performance problems for real time integration Unclear roadmap Consider SAP PI when: Looking for integration of SAP systems Have some plans towards SOA