On March 16th, we celebrated our annual VNSG developers day. A day fully dedicated to developers and developer topic. We had magnificent content, both from the hearts of SAP as well as the community mostly accompanied by nice demos showcasing SAP’s latest and greatest.
One of the nicer demos was presented by Twan, who took a photo of the audience and used Machine Learning mechanisms to recognise faces and perform an age, sentiment, and gender analysis on the recognised faces.
The results struck me in a way. Of course we already knew that the majority is male, sentiment on a day like this is positive, and the age analysis looked quite flattering as well. But when I did a personal analysis on the faces without machine learning, it struck me that the age of developers in the (Dutch) SAP community is steadily increasing.
The day before the VNSG Developer day, I attended a lunch organised by the Appsterdam meetup group. I was really curious about this meetup group, their topics and the people behind this community. They happened to be able to pass me a free ticket to the AppDevCon conference that would happen that same Friday, just after the VNSG Developer Day. The AppDevCon is a conference specifically for app developers on both the iOS as well as Android platform.
While I felt like one of the youngest when I was on the VNSG Developer day, I felt like one of the eldest when I was at AppDevCon.
When I was at the AppDevCon, I took the opportunity to talk to some of the other visitors to see if they had ever built application on top of enterprise back-ends such as ERP or CRM systems and whether they had ever heard of SAP.
I absolutely hit a pain point there. Most of the response had to do with headaches around message brokers and integration platforms. OData and Gateway are technologies they had never ever heard of.
When I tried to explain to them what it was and how SAP currently does integration, the discussion quite quickly went into the direction on how these things could be done using the shiny popular frameworks such as React and Angular or their native counterparts such as React Native and Nativescript. When it came down to OData and integration protocols, I was quickly pointed in the direction of GraphQL or got the counter question “what’s wrong with regular REST?”
It became clear to me that the intention of the participants of the conference isn’t really the integration to the back-end. That part is definitely not sexy. What’s more important is what the app looks like and how to build it with as little effort as possible.
I have tried to explain about the Fiori design language to some of the attendees and have also explained how this would be integrated into SAP Cloud Platform SDK for iOS. That its objective was to increase developer productivity and contribute to a consistent user interface. Unfortunately this didn’t hit a sweet spot as well.
Although the people I talked to could imagine that this would be beneficial if you would launch an array of products in a large company, this was definitely not their focus area. Most of the times they were hired for an external facing, mostly consumer type app or a one off app an in those cases they just found the Fiori design language too rigid.
Especially from a design point of view, they wanted to have more freedom to adjust the app to the overall experience of the user in that particular app, without caring to much about the world outside of that app. It also seems that the design language they were talking about, had more to do with animations rather than consistency. They believe that with those little extra’s they would be better able to capture the user’s emotion than with a consistent user interface.
SAP Mobile Services
When I spoke about the mobile services on the SAP Cloud Platform and was explaining about the features of the cloud platform in combination with mobile services, at a certain point they understood what I was trying to say and they started comparing the SAP Cloud Platform and mobile services with Google’s Firebase, which admittedly has quite an overlap in functionality.
I was explaining that emphasis would of course be on back-end connectivity and various business services such as analysis, integration with IoT, enterprise social and others. They mentioned that in most cases, they weren’t tasked to do these kinds of things, but these things were taken care of by developers in the back-end teams. Although none of the folks I spoke to knew about the SAP Cloud Platform, they would consider looking at it when they would be asked to take care of similar back-end tasks. There! Mission accomplished, finally something I could at least trigger their interest with, although not to the extend that I hoped for.
SAP Cloud Platform SDK for iOS
During various sessions we held at the VNSG special interest group meetings, but also at the developer day, we noticed a vast interest in the SAP Cloud Platform SDK for iOS. One of the reasons that I was at the AppDevCon was because I would be interested to know whether (non-SAP) iOS app developers would be interested in the SDK as well.
I’m afraid that the SAP Cloud Platform’s Mobile Services is not on their radar screen, and it is of course to early to ask about the mobile SDK (thanks for your highlighting this, Pierre). However, there is a good interest in Google’s Firebase, and I believe that SAP Cloud Platform SDK for iOS could be the Firebase for enterprise mobile developers. There is quite an overlap in functionality, and consumer-type services such as ad-provisioning are replaced with analytics and integration services, making the SAP Cloud Platform a good contender to take the place of mobile platform of choice for mobile enterprise app developers.
It seems that Firebase is setting a de-facto standard in this area though, and it would be wise for product teams behind the SAP Cloud Platform SDK to keep a close eye on what is happening in this field. Especially the continuous client synchronisation is praised by many, leading to an always synchronised offline version of the database, without any additional developer effort.
Another part where the SAP developers may have to take a peek into are the number of Cocaopods the SDK consists of. Currently the SAP Cloud Platform SDK for iOS has three SDK files, while the Firebase SDK can be included in an app on a much more granular level, which may lead to less bloated apps. Note: Swift apps are currently a bit on the heavy side anyway, and the SDK doesn’t make that much of a difference. But it is my expectation that Apple will be able to improve this as well. To make sure that the SDK doesn’t become the “weakest link”, it would be nice to more granularly select the SDK parts that are going to be included in the app.
The Firebase SDK allows developers to configure the framework using plist files. The SAP Cloud Platform SDK for iOS only allows developers to configure the framework in code. It is my personal opinion that the configuration through plist is quite elegant and it would be nice to offer this as a configuration option as well.
SAP developers vs iOS developers
One of the questions I have been asking myself is who will up the SAP Cloud Platform SDK for iOS. Will it be the SAP developers learning Swift and Xcode, or will it be iOS developers trying to understand how SAP, the SAP Cloud Platform and the iOS SDK will fit into their tool-chain.
On the other hand, it may also be just a luxury problem when there are so many modern development environments and languages to choose from. And the front-runners will always be looking beyond what they know, and will be happy to keep up and learn new things. I do expect the SDK for iOS to be picked up by the same people that were also the first to pick-up XSA and UI5. For these polyglots, another language will be just another challenge, if at all. And SAP has done a tremendous job to make this experience as painless as possible. Developers already familiar with the UI5 tooling will feel quite at home when they understand that the Assistant is very similar to the WebIDE templates, that the SAP Fiori for iOS Mentor app is quite similar to UI5 Explored, that the SDK is quite similar to the KAPSEL SDK, and that the SDK is very well documented, just like the UI5 SDK.
The question remains whether iOS developers will see the value of the SAP Cloud Platform in combination with the SDK for iOS to simplify the connection to the back-end and will they accept that the SDK will be working slightly different from what they are currently used to (e.g. Firebase)?
Ultimately, it would be great if iOS developers would see the SAP Cloud Platform and SDK for iOS as part of their tool chain. Perhaps the SDK could be for enterprise what Firebase currently is for consumer-type applications. The SDK may need to offer a slightly more similar feel to Firebase though, which means it would have to break with the patterns that it has in common with the KAPSEL SDK.
There’s a massive difference in the iOS and SAP community. Not only in the tool chains and frameworks of choice, but even in demographics. It is a question whether these communities will grow together organically, and the SAP community could certainly use some young blood.
To get iOS developers on board, it may be necessary to provide an enterprise toolchain that is similar to the tools they are already using. Equally important are the education and continuous developer relationship building within this community.
Looking at the interest in the SDK for iOS at past events, the SAP community is probably going to embrace the SDK for iOS without much effort. People that were early adopters of technology such as XSA and UI5 are likely to be the early adopters of the SDK for iOS again.
There is one thing that the iOS and SAP community have in common. They are both spoiled with choice in the area of modern development environments, frameworks and languages. With the SDK for iOS in place, there will even be more choice for enterprise app development. It will be very interesting to see how these communities adopt this new technology, evolve, and hopefully grow towards each other.
Let me know what you think?