The SAP NetWeaver Gateway Product Management team interviewed various customers over the last years in order to always have a good overview on the required steps and processes being used at our customers when a new user interface is required – mobile or non-mobile. Everywhere we found comparable roles involved.
- Requirements were provided by the Line-of-Business
- An IT Consultant (internal or external) took over the project management and the communication of feedback or change requests. Additionally the data model was often defined by this role
- The App developer for the frontend focused on the development of the application in the required technology (HTML5, SharePoint, Mobile …). This involved often also the creation of mock-ups and later the update of the app.
- The SAP Backend Developer was also involved in the feedback process for the requirements – just like the frontend developer – and then provided the required services in the backend system.
This pattern allows every role to focus on their areas of expertise.
The most prominent user-interface technologies we consistently see at our customers are native mobile experiences (Android, iOS, Windows Mobile), Microsoft’s User Interface technologies like Microsoft SharePoint or Microsoft Office (e.g. performing mass data change in Microsoft Excel) or HTML5 – and here clearly a strong focus on SAP UI5. What becomes evident is that quite a lot of user-interface technologies are being used. Especially in the very dynamic world of frontend technologies with a lot of innovation it is important to involve the right expert with the right skillset for each user-interface technology.
In the past it was not too easy to de-couple backend and frontend. So also the frontend developer required skills for the backend (e.g. which RFC-calls, call sequence …). And it was not easy to find someone who is good in one of the frontend technologies and in SAP technologies.
With the introduction of the neutral OData protocol (which is added to the SAP Business Suite via SAP NetWeaver Gateway) it is now possible to clearly separate these two worlds by a contract that can be understood by both sides, the backend and the frontend. This contract defines the required entities, the attributes, key fields, relations and much more http://www.odata.org .
The SAP backend developer finds with SAP NetWeaver Gateway an ABAP-based environment that helps with the creation of the required services based on the agreed contract. The ABAP developer is then focusing on the mapping between the business logic and this contract in the familiar ABAP development environment. SAP NetWeaver Gateway is accelerating this activity by providing various generators for Business Suite content or Business Information Warehouse based content. So the required training time for an experienced ABAP expert is really short.
The same applies for the frontend developer. As now there is no longer the requirement to also be an expert of the details of the involved SAP backend system it is now becoming much easier to find experts for the user interface technology of choice. Also the frontend developer is now starting based on the neutral contract. Various generators for e.g. Microsoft Office (http://scn.sap.com/docs/DOC-47563), Android, iOS, PHP, Java or HTML5 (http://www.sdn.sap.com/irj/sdn/gateway?rid=/webcontent/uuid/a09fe802-c162-2e10-d59a-be4a4f27c49b) reduce the required effort to create proxies and now the frontend developer can purely focus on the frontend technology.
Compared to other interface approaches (e.g. Web Services / SOAP Services) SAP NetWeaver Gateway and OData have several advantages. So typically the OData Services are being developed newly optimized for each use-case. This allows a reduction of required bandwidth and improves the performance. Due to its more light-weight nature REST-based approaches like OData are also more common in frontend development and receive a lot of support by the ecosystem (http://olingo.incubator.apache.org/ or http://www.odata.org/libraries/)
This clear separation of the involved roles is now providing a lot of benefits:
- Reduction of the project risk as no longer experts having knowledge of two domains are required
- Reduction of the project risk as now a clear and standardized format (OData) is being used to formulate the contract between frontend and backend.
- Reduction of the project risk as now SAP standard software is taking care of the ‘Enterprise Readiness’ like single sign on, authentication, security, logging, …
- Reduction of the project duration as now a lot of manual steps are taken over by standard software (SAP NetWeaver Gateway)
All these factors are now increasing the willingness to invest in new and improved user experiences. A nice example of the result can be seen here: http://youtu.be/qrJTcgvpkKo.
You make a very valid point that good user experience requires good software design at the architectual level. Technology that supports the division of labor so that people can do what they are best at and what interests them most will surely be a great benefit to those using SAP NetWeaver Gateway.
The forum ‘Design & UX’ is closed to new topics and replies.