Building an SAP/Microsoft Interoperability Team
Building an SAP/Microsoft Interoperability Team
I am passionate about the opportunities that are available to develop interoperability scenarios between SAP and the Microsoft platform. The ability to bring Line-of-business (LoB) data into a central portal location can improve usability and provide a better return on your technology investment. You can also improve the user experience, especially a casual SAP user, by bringing their data and enabling business processes in a familiar tool like SharePoint. When you couple this with the ability to develop custom frontend UI’s to simplify complex SAP screens, you can easily see that this could add tremendous value to your environment.
Before becoming a Microsoft employee, I was a customer who was headed down this path. One of the questions I always asked myself was how were we going to build an interoperability practice within my company. After attending SAP Interop training this past week, those thoughts crept back into my mind. Although I am no longer responsible for doing that, I think I now have a grasp on what this means and what it would take. I am hopeful this blog entry turns into a discussion on how to make this happen and it will enable customers to start to undertake this task.
Build a SAP Interoperability Lab
If at all possible, you need to establish a SAP Interoperability lab environment. This is necessary to test things like Single Sign On, enablement of SAP Enterprises services within SharePoint, development of custom UI’s to SAP business processes and so on. By building a lab, you can isolate this work to ensure it does not affect your development, test or production environments. It provides a place for you to do a proof of concept before moving forward in a development system.
What would be needed in this environment?
· SharePoint System
· SAP ECC System
· Active Directory System
This would be the minimum setup. But if you have BI, CRM, SRM and other SAP applications running in your environment, you might consider adding these systems to your lab. In addition, if you are using BizTalk or SAP XI/PI as your Enterprise Architecture Integration (EAI) tool, you would need to add these systems to the environment.
All of these systems can be setup in a virtual environment, thus limiting the cost of this step.
Determine a Proof of Concept Business Process
The next decision I think that needs to be made is what business process you want to enable in an interoperability scenario. This could be a FI, SD, MM, PP or any other business process you currently run in SAP today. The process itself is not the concern as much as identifying the appropriate functional person to work on the Interoperability Team. This person will be key in helping bridge the gap for the developers.
Does it matter which process you pick? Not really, but if I were involved in picking the process, I would pick one that was complex and the typical user of this process is not an experienced SAP User. Vendor Create could be a potential process. In many companies, the people who create vendors may only do this occasionally. If so, remembering how to navigate the SAP process can be difficult and by moving to a SharePoint or .Net solution, you should be able to greatly reduce the complexity. This will bring an immediate efficiency improvement and adding value to your company.
Build Your Interoperability Team
Who should be on your Interoperability Team? Let me suggest the following individuals:
· SAP Functional
· ABAP Developer
· SAP Basis Administrator
· .NET Developer/SharePoint Developer/Administrator
· SharePoint Administrator
The SAP Functional person is important to be able to communicate and help everyone understand exactly what the business process does, what information should be displayed and what information is required. They bring their functional experience to the table and they will be able to help with testing the new solution.
The ABAP developer will be able to determine what the best way is to access this data. They can help determine if there is an existing BAPI or Enterprise Service to call or a BSP that can be accessed. They can also look at the functional modules that exist for this process. It will be key that the ABAP Developer and the .NET/SharePoint Developer can communicate in terms that each understand. I will address this point later.
SAP Basis Administrator will be needed to help with establishing the appropriate access whether it is setting up and configuring RFC connections, establishing trusts between SAP systems and so on. The time that they will have to spend on the project is minimal, but extremely important. In some SAP environments, this role may be filled by the SAP Security Administrator and not a SAP Basis Administrator.
Depending on which technology is being used for the User Interface, you will either need a .NET Developer or a SharePoint Developer/Administrator or both. This person will be responsible for the development work that needs to be done on the Microsoft platform.
If Single Sign-On (SSO) is needed and Active Directory (AD) is used within this environment, an Active Directory Administrator will need to be allocated to the project to help ensure security is addressed correctly.
Cross Train Developers
One suggestion I would have would be to cross-train your development staff. Send your ABAP developer to a C# programming class and send your .NET developer to an ABAP development class. This will help both of them to speak the same language and help them work together to build a solid solution. I realize training classes are not cheap, but maybe you could utilize your Software Assurance training vouchers for the C# class. I think the money will be well spent because it will accelerate the development efforts. I think you will quickly realize a return on your training investment through improving your time to market and the efficiency and effectiveness of your interoperability solution.
SAP Interoperability Training
Another suggestion is to schedule SAP Interoperability Training for your entire team. This training can be scheduled to be brought onsite at your company. The training is provided by Microsoft for a fixed fee and is quite affordable for onsite training. After this class, everyone who attends will have a good overall understanding of what the possible interoperability scenarios are and will better understand the plusses and minuses of each interoperability solution.
Determine Architecture
This next step in the process is to determine your key architecture strategies.
Security
How will you handle security? Will you utilize one of the single sign on technologies like SPnego or Secure Store? This is a discussion the team will need to have together. Determine the strategy and put together a plan to set this up and test it.
SAP Architecture
What will be your method of extracting/updating data in SAP? Will you only be reading data or will you then need to update the data? This will help determine which methods you will deploy within SAP. Once you have determined the approach, you can start working on identifying and documenting the SAP components that will be used in your solution.
SharePoint/.NET Architecture
The discussion around the data (read or modify) will help determine what your options are in the SharePoint/.NET world. Once this is determined, then development or configuration on the Microsoft side can begin. You will want to document your approach.
POC Development
Finally you can start to develop and test your process. Hopefully during the preceding steps you will start to develop some patterns and practices that can be applied to building reference architectures for your environment. For example, you may decide that if there is an Enterprise Service in SAP available, that should always be the preferred method, followed by BAPIs and then by calling specific function modules. On the SharePoint side, you may decide that you want to always utilize the Business Connectivity Services component and if possible, you always want to expose that data using a custom webpart within a SharePoint Iframe. Whatever your decisions are, you should document them and publish them so that your start building all of your interoperability scenarios following a standard process and within your architectural guidelines.
Well there you have it, my ideas for establishing a SAP Interoperability Practice. I know it isn’t perfect and I have only spent a few days thinking about this. I would be very interested to hear what you think. Please provide feedback in the comments section below. If you have questions or comments for me, please send them to raymond.smith@microsoft.com.