carloscastilla - Fotolia
What if I told you that to deploy a new time entry system for your workforce, you would have to install and maintain a large, proprietary software installation on every computer of every employee at your company? This software would work differently from other software, so a large training investment would need to be made for every employee. And the software is not used at most other companies, so you'll usually need to spend significant time training every new employee. You would justifiably look to a different vendor with a more standard, probably web-based time entry system.
For a long time, these were exactly SAP's expectations for its user-facing software and for SAP development tools. You would have to install the SAP GUI or NetWeaver Business Client for many applications. Even for web-based interfaces, if your standard browser was Google Chrome, due to security and performance concerns, you would have to install Microsoft Internet Explorer because SAP interfaces only worked on IE.
This stance has changed in the last few years, starting with the introduction of SAP's Web GUI over a decade ago, and culminating with a browser-only, standards-compliant approach in the S/4HANA ERP platform, which supports major browsers.
The change is a win for customers for a few reasons. It lets them choose the right tools for the job. Is security a top priority? Use Chrome. Need legacy support? Use Microsoft IE or Edge. Own some Macs? Use Safari.
In addition, it lets SAP users immediately benefit from the furious pace of third-party browser development if they so choose, and it enables scenarios that SAP may not have considered, including the use of different operating systems and form factors.
Developer and operations tools less likely to be standard
However, in the world of developer and operations tools, the situation is more in flux. SAP is moving toward embracing standard developer and operations technologies, but adoption has progressed at different rates on different platforms. Further, SAP's adoption of standard technologies often has a distinctively SAP-flavored spin, which can hinder the use of a standard kit of tools in conjunction with SAP's software.
Nevertheless, the same advantages of being able to leverage standard development technologies instead of proprietary ones are in play. They are:
- Pace of development. SAP can't keep up with the rest of the world in all areas all the time, and sometimes allows developer and operations tools to stagnate. This is less likely with standard technologies.
- Right tool for the job. Sometimes, a particular tool, such as Eclipse, just doesn't cut it as an integrated development environment.
- Enables scenarios SAP may not have anticipated. Development innovations, such as distributed version control, fully automated testing and Agile development, have been slow to spread in the SAP ecosystem, in large part because they are not enabled by SAP's developer and operations tools.
SAP often builds bridges to standard tools rather than adopting standard interfaces to allow standard tools to interact directly with SAP applications. This allows SAP to reap some of the benefits of pace of development, and enables some flexibility for tool choice.
However, this approach also results in a two-tier tooling situation in SAP environments, where SAP development tools are tier 1 and third-party tools are tier 2. The situation is workable in a fully SAP-centric environment, but in most environments, SAP is only one of many players, and development teams would prefer to standardize on a single version control system, continuous integration server and container technology. But as long as SAP is in play, such standardization is difficult, if not impossible.
For example, version control systems (VCSes) are often linchpins of DevOps infrastructure. Checking in code to a VCS will kick off builds, tests and deployment of code to various system landscapes. These systems tend to rely on the VCS being the canonical repository for the application code, with the VCS at the center of application development processes. However, in most SAP environments, including HANA and ABAP, SAP has decided to make the VCS a secondary tool, with SAP's own Web IDE and Eclipse tools as mediators.
As an SAP customer, what do I do?
As always, what you need to do depends on your position and priorities. If you are an aggressive, technology-driven company, and you find that SAP development tools are lagging behind your other development areas, look for ways to revamp your SAP operations and development to use more standard tools and processes that are shared with other areas. This takes a concerted effort, but it is possible, and the benefit will be a more agile and stable SAP platform, as well as the ability to share developers and operations people between SAP and non-SAP platforms.
If you are more conservative, SAP is your primary technology investment and you are happy with SAP development tools and the cost and pace of development, then stick with what you know.
Most companies will fall somewhere between these two extremes. A first step any company should take is to migrate development to areas that are more standard. In the ABAP world, this means moving to more OData and Fiori and UI5 applications on the front end, and SQL and Core Data Services views on the back end. More ambitious companies will want to move more of their UI development to the SAP Cloud Platform.
The exact move you make will depend on your needs and pain points, but keep your eyes open to whether the SAP development tools you use are standard outside of the SAP world, or are limited to only SAP environments.
Start developing Fiori apps
Learn about open source VCSes
Understand HANA development tools