Based on the social media feedback and the activity on the previous blogs in this series, I've obviously hit a sore point with a lot of people. However, it was a bit rude of me to rant about how bad things are and demand someone fix it, without providing some ideas, some suggestions (plus every good trilogy requires at least four parts).
Please take this opportunity to tell me what you think of these ideas, add your own suggestions, and maybe even rank what you see here and in the comments. The SAP Developer Relations team are aware of how ugly the existing situation is, but they can't provide us with what we want (or at least decent reasons why they can't provide what we want) until they hear from us.
Alice is getting there...
First a progress report; Alice has got her SAP Developer Edition up and running, she has got her head around the fact that it is an entire server and development system in one, and she's coding away. There were some minor issues with stupid things like the difference between SAP namespaces and Customer namespaces....
but it took Alice only a few minutes to produce
What do want and when do we want it ?
Now, as a developer, I'm stuck at simple ABAP procedural reporting, so I'm going to leave any critique about the documentation and training paths that Alice should now follow to some one who knows better. One thing I will say, though, is that while there is a lot of good stuff in the Cross-Technology Developer Center and ABAP Platform Developer Center Community Spaces, there are a lot of places that will confuse the unguided Developer.
For example, some documents point Alice at old releases of the ABAP system and other documents and pages appear to be confusing ABAP on HANA with ABAP on MaxDB. Alice started off with the "Develop an on-premise business application with HTML5 & in-memory persistence" tutorial (again with the naming confusion - in-memory persistence ? is this different to database systems ? and does this imply the existence of some kind of out of memory or even out of body persistence ? No wonder people get confused with what happens to your HANA in-memory data when you turn the box off...) and while it talks about in terms of an ABAP on HANA system, the requisite tables for working through this document were also available in her ABAP on Max DB system.
However, one problem that the issue with Customer v SAP namespaces raised is that unless Alice jumps through the hoops to become a certified partner, she can't get her own namespace for her developments. What happens if she builds the next 2 Clicks, and her object names clash with something that is already installed at a customer's site ?
This leads into code management in general - Fifteen or twenty years ago, the Transport Management System was light years ahead of anything else in change management and control of source code, but modern tools have caught up and passed it by. SAP needs to be open to GIT and Subversion and other repository tools. SAP needs to provide a ABAP client or interface that serializes SAP content to push and pull it from the non ABAP repository, and at the very least integrate with the ABAP in Eclipse tools. In a perfect world, it would also work from within the SAP GUI as well, but modern non SAP Developers won't be using SE80 unless they have to .
While we are on the subject of modern tools, despite SAPs flagship accounts being ones where the business runs SAP, the vast majority of customers use SAP for a specific function within their business, and run most of their processing on other software. Integrating SAP systems into other software should be as easy as making a twitter API call. The easier this integration is, the more "Innovation at the Edge" will occur, providing more value for existing SAP customers and increasing the value for new SAP customers. SAP needs to provide a wider range of APIs or pre-configured ODATA interfaces to allow on premise systems in general to integrate better with other systems; everything from Salesforce to monitoring tools like BMC to configuration software like Chef and Puppet.
Easy Installation
The most obvious problem that many people identified is that there are "too many step" required to install a Developer Edition. Apart from discouraging potential developers, this also introduces opportunities for error by the installer (by incorrectly performing or missing a step) and by SAP (incorrect links and documentation).
(from KIDS REACT TO OLD COMPUTERS)
In a perfect world, all SAP on-premise systems (whether on a physical server or Amazon, Rackmount, Open Stack, Azure...) should be able to connect and download notes, notes, bug fixes, patches, support packs, upgrades, and apply these, etc. themselves. Just like Windows Update, or "npm update" or "git pull". No Solution Manager, no SAPRouter, no nothing except a HTTP connection to SAP.
In a perfect world, installation should consist of running sapinst, filling out the fields and hitting go. With no questions asked after you hit the go button. Checking against a licence or control file would be a good way of ensuring that only the appropriate components are installed on appropriate hardware; for example, a "Developer Edition Licence" would allow installation on any hardware key, but would not install or run the full blown ECC or SRM components.
In a perfect "Innovation without disruption" world, the install would also give the option to update our installation to the latest Enhancement Pack automagically (if that is what the installer wants), but that's a bigger issue than a technical upgrade. Anyway, regardless of this, there would be an option to update the DBMS and Operating System to the appropriate patch levels for the current EHP.
This is how server and desktop operating systems from Windows to SUSE already work.
I understand that making this work would require a bit more control over the target environment than SAP has. For example, if there's an issue with the installation process, where does the blame lie ? With SAP, or the OS vendor or the DBMS vendor ? The only way this could even hope to work is for SAP to own or have some control over the DBMS and the Operating system. Like they do already do with HANA. Like the relationship they have already built with SUSE for the HANA environment. Even if it's not practical for all combinations of Hardware, Operating System and Database system, it's manageable for ABAP on HANA or MaxDB. As an aside, making this one-shot installer only available for ABAP on SUSE on HANA would be useful in marketing ABAP on HANA (make it easier to install HANA / ABAP on SUSE than on any other platform...)
In fact the Developer Editions would be an excellent place to start this with, but could we please have the systems in a downloadable form, not tied to a specific cloud platform in a specific location, like the Corporate Network versions of both the NW 7.40 ABAP systems currently are.
Easy Documentation
Can we have a simple and accurate path through the process, from a link on sap.com that says in large letters ABAP Developer Editions - no licence fees forever, that goes to a one pager that distinguishes between the on premise systems and other SAP products, and includes the download link and installation instructions for Azure or SUSE 11 (with a pointer to the appropriate SUSE image for Amazon Web Services, Rackmount etc), and a VMWare version (in the appropriate format to allow people to choose either VMWare or Virtualbox).
Given that the current (NW 7.4) on premise Developer editions appear to have had some of the traditional post implementation work already done (such as SGEN and Transport Management configuration), why stop there ? For example, I noted that there was no simple way of downloading the SAP GUI from within the Developer Edition that Alice installed. ABAP systems are Web Servers. The User Guide should incoporate a link to http://<ip-address>:50000/sap/bc/gui/sap/its/webgui/! to allow Alice to logon and begin her journey as soon as possible.
Another suggestion is to build on the example of the older SAP Developer Editions, which came with a small set of help files that could be configured (ABAP systems are Web Servers) via the icm/HTTP/file_access profile parameter to be accessible via a web browser.
Apart from documentation links, this is an appropriate place to include links to the various SAP GUIs included in the system. In the example below, I just copied the files from an older Developer system, but I could include any static html or javascript (including UI5 ...)
Easy Information
if SAP want to attract modern developers, they have to be open in spirit not just word. This means that all Developers - freelance, employed by an SAP customer, an official SAP partner or even SAP themselves - must have the same access to howtos, work rounds and patches. Any suggestion that this is not so suggests that SAP are playing favorites among their partners and friends at the big System Integrators.
SAP needs to decide what to do with SCN. SAP Support needs to either commit to SCN and properly curate support documentation on SCN or stop pinching community created SCN content to respond to Service Market Place messages and to support basic installations scenarios. They need to be all in or all out. If they are going to leverage SCN then they owe it to the community to return the favor, by making their Service Market Place content (not product downloads) as accessible as SCN is.
Summary
I've already been approached by a member of SAPs Developer Relations team who sounds very enthusiastic about changing the process of accessing and installing Developer Editions. I'm taking the opportunity to provide his team with some feedback on what I want to see. Now it's your turn :smile:
- SAP Managed Tags:
5 Comments
