Enabling Enterprise Mobility with SAP
Jess, Michael
In today’s digital economy, enterprises around the globe are transforming the way they do business by building new apps and modernizing legacy systems. Mobile devices – and especially Android – provide a critical channel for the success of any digital transformation project. In this session, you’ll experience SAP Cloud Platform Mobile Services and the tools SAP provides to support Android developers.
 Michael, yes, is product manager for everything mobile on Android with SAP. And normally this works much better, but the content of his presentation and what he has to present to you will be brilliant. I'm convinced. Michael, yes, the stage is yours, please. Oh, that's definitely going to be a special entry in the history of DroidCon, I believe. All right, so as Heinrich said, my name is Michael Jess. I work with SAP product management in the mobile area. And today's session topic is enabling enterprise mobility with SAP. So it's really unfortunate because it put quite a lot of effort in the slides and the demos that we are having, so we need to find a way here. Up front, I can say I'll be at the booth, at the SAP booth later, so I kindly ask you guys, if you're interested, if you have the time, stop by and I'm going to show you everything. I don't think that, I mean, this is already difficult, right? There's no way I can show you this on the mobile device screen. We need to find some other way to do this. Okay, so before we start, excuse me, I want to ask a question. Is there anyone who is not very familiar with SAP? Wonderful. Okay, so the big question is what is SAP, actually? What do we do? And I did try to shortcut this little and did a quick Google search and thought, like, maybe we find something brief, snappy, description, what we're doing, but actually it's not that simple. So I thought hard and I found that the easiest way to understand a company is by understanding the customers and the value preposition they're trying to deliver. So let's put ourselves in the shoes of an archetypical SAP customer that's not the SAP customer that we have, it's like one kind of customer which is a production company. So we're trying, and the bubble there is saying product, right, that's very difficult to spot, we're trying to sell a product. So what do we need for this? Well, number one is we need a salesperson who is able to sell the product to a customer. So salesperson reaches out to the customer and says, do you want to have a product? They take a look at it, say, yes, please, that looks awesome. So can I have one, please? Let me check the stock. So the salesperson does and finds, oh, no, there is nothing there right now. So I'll reach out to the production department and ask them if they can produce one of such product for me. Well, they do need to check the stock and what they find is we're just fresh out of the manufacturing parts to manufacture this product. So the next department is involved, which is procurement. We need to purchase parts from our suppliers to be able to manufacture this product. After procurement, acquire the parts and deliver them, hand them delivered to the warehouse, financing is involved to pay the supplier. Well, now that this is done, production department can take the parts out of warehouse, the salesperson is notified that everything is in place now, the sales order is dispatched to the customer, and last but not least, financing department is notified that the customer can be built. So this is just one very simple process. It's one instance of a bunch of processes that we typically find at customers. So why is this important? Number one is, or what's the issue with this really? The key thing to know is that as enterprises grow, their need for automation and systems increases as well. So it's not like that everyone starts with an integrated software suite from scratch. It's really that many enterprises grow organically. And what you end up with in the end is an unintegrated mess of different subsystems. There is one system doing financing, maybe there's some spreadsheets floating around in the enterprise. Maybe there's some other software components for warehousing. And the issue with that is the enterprise becomes very slow. You will have all sorts of data inconsistencies and so on and so forth. Now, our founders realized that in a way, all companies are functioning very similarly. Those departments, everything that's there are similar or if not the same between companies. And they realized let's just provide standard business software that is solving those issues. And that's what we are calling enterprise resource planning software. So why is this interesting and important? Number one is, where do we find mobile in this whole picture? Clearly, one usual use case is field services. The sales person is very likely to have an app or something these days to present products to the customer. Another important key area where we typically find mobile applications is the warehouse where people are running around. So traditionally, especially the warehouse, is where we find ruggedized devices. And we are also having these days we're finding some nice instances. For instance, Zebra is also here, delivering Android ruggedized devices that are commonly found in this area. These days, this is just one of the product areas that we have. Now, I really need my cheat sheet here. We also have other product areas. One would be IoT and supply chain management. It's basically another area. We have supply or relationship management. We also have analytics. What else is there? Strategic sourcing, supply or relationship management is what I already said. And so on and so forth. So the really important thing is, last but not least, these days SAP is not only this, it's not only enterprise resource planning, but we are also a technology company. We also deliver a technology platform. And this is in essence SAP Cloud Platform. Why I'm leading to this? Because SAP Cloud Platform is an enterprise Cloud Platform where we are delivering a high amount, a high number of technical services. And one of these services is a mobile service. So much as Google is offering Firebase, we are having the SAP Cloud Platform mobile services that are fulfilling a similar purpose only in the enterprise context. All right. So that covers what SAP is doing, the enterprise part. But this talk is really about enterprise mobility. So why is it that enterprise mobility is special or different or more difficult even than, well, general purpose mobile app developments? Luckily, I found a nice research paper that summarizing what I felt are the key challenges for enterprises. The first thing is usability versus security. And you've also heard this in Sean's talk. You've heard this in John's talk that security is a very dominant topic. Why is that so? Because when we're talking about enterprise mobility these days, we're generally talking about second generation enterprise mobility as a research term for this. What does it mean? Basically, mobility since the advent of smartphones, which is pretty much the summary of the past 10 years. Why is it important? Because people are bringing expectations from their consumer experience to the enterprise. They're used to very simple focused apps. They're used to opening an app and understanding it right away. The days of manuals and reading them are over. And when we personally, I guess you can also relate to this, when I see an app in an app store and I don't get it immediately, I'm just discarding it and selecting the next likely candidate. So this is what people expect. Reality in enterprises even today. IT is very defensive about releasing data. So what we find is like, yeah, we're going to manage your device. You need to password secure this. Perhaps we're adding some biometrics to the mix. Then your application is secured by username and password. By the way, please, as soon as you logged in, you also give a passcode. By the way, I forgot, you will only ever see data in VPN. That's an awful user experience. Because you have many, many gates before you can actually use the application. And you need to cross these borders each time. You're basically interacting with the application. The second thing is innovation or the ability to innovate. The reason here is that this is like the better case where IT departments or administrators are willing to release data. What we see otherwise and also something that we at SAP have observed traditionally is that businesses say or ask the IT department, can we have an app for this? And IT looks at this, says, this information is way too sensitive to put it anywhere outside our system premises. We have on-premise systems. The data is not going to leave this. What you would expect probably is that the business owner says, oh, well, okay, so then there is no app. What happens in reality is they find ways around it. So there is going to be a growth of point-to-point connections. Because when you start with one app, you don't stop at one app. There's one app and then there's the next. And then there's another one. So you have a point-to-point connection from System 8 to Mobile app A, then there's System B to B, maybe there's a third app that's again connecting to System A with a variety of authentication schemes, protocols, whatever you use. So there is no common denominator in all this. And from an IT perspective, this is plenty unmanageable. So not only does this slow down the speed at which an enterprise can really develop the applications, it is also like a manageability risk and it puts the data at risk. The third thing is, so we only have four, the third thing is how does development work in this? Mobile app development is a pretty agile process. I think you can all agree upon that. How often is a mobile app updated, especially in the consumer area? And this is also what users expect. Every few weeks, months, perhaps that's it. In traditional IT, a system upgrade is done every few years, perhaps. The major upgrades project is kicked off. That will take half a year with a smoke test in the end. And then maybe there is a rollback because there were some unanticipated issues in all of this. And the sum of all of this is that there is a mismatch between the skillset that traditional IT has. And when I say IT, ultimately, also mean developers because in the SAP ecosystem, IT also encompasses development. So our customers usually have IT departments where they are also mobile app developers, for instance. That they are not used to this development style. Perhaps they are coming from the old ABAP system. So there were some hands raised about people who didn't know ABAP. Essentially, ABAP is the power horse, the old SAP power horse and enterprise resource planning when it comes to customizing SAP systems. So we had a pretty extensible on-premise development framework that you could use to tailor SAP applications to your business needs. And those guys are caught in the whole enterprise cycle mentally. They are just not used to this edge I work for. And this is also what we are seeing today. So how does that relate to what we have at SAP today? Number one is we do have an enterprise-ready cloud platform that means security is a very huge concern to us. And we are implementing a great deal, a great many best practices that we've discovered over the past years, authentication schemes and so forth in our cloud platform. So that would address the security needs. And it's pretty easy even to acquire SSO across backend systems. Because some customers do insist that they want to have multiple backend systems per application. We recommend one API for one app. But generally speaking, you can have multiple and then there's the SSO question. Also came up before. The second thing is since we are offering a cloud service, much like Firebase, we are taking away many of those traditional IT and infrastructure concerns. So not only do we offer those services, those security-related services, but also other general purpose services such as push offline and security was the other thing. There was also a visible on the one slide from Sapphire that Sean presented. Where Bjarne Gorky was presenting the new Android SDK. More on that in a second, by the way. The third thing is that we are providing, we're delivering development tools that accelerate your development process. So number one is we are very aware of continuous integration. Other agile development practices. So our tools are generally ready for this. But also we are giving you ways to generate applications on the bootstrapping code that's required to integrate with our cloud platform. And last but not least, if that is still not enough to support you to get you up to speed with our software, then we also are heavily investing in a strong partner ecosystem that can serve as implementation partners for those projects. All right. So that was the theory. Soon there would have followed the demo part. So I'm just going to talk you through three key development approaches that we have. And this is probably going to be pretty tough just by talking. So once more, I'd like to ask you if you'd like to join us at the booth so that I can show you those things as well. I want to talk about three approaches to developing applications with our SAP technology. Number one is SAP mobile cards. Number two is mobile development kit. And third thing is the all new SAP cloud platform SDK for Android that also, as Sean has mentioned briefly in his talk. So the first one, mobile cards. Mobile cards is a piece of technology that's generally speaking very similar to passbook style applications. So in case you know those, there are variants for iOS and Android. It's a kind of application, general purpose application that allows you to take things like concert tickets with you or tram tickets or business cards. So your data is just being stored in this application. And you can get this by a bunch of means. Like there are vendors, ticket vendors who would allow you to store this ticket format on your phone. So we are basically transferring this concept to enterprise data in that you can take pieces of enterprise data with you. You can subscribe to feeds more or less from cloud platform containing address data of partners or customers. Your inbox, for instance, purchase orders you need to approve. But we also have standard integration with S for HANA that is our latest iteration of enterprise resource planning systems. We have standard integration for success factors that would be our HR related, the talent management software, but also for hybris and field glass. So there is a bunch of standard components that you can use to mobilize pieces of data from SAP enterprise software. But this is also extensible. You can have your own, well, so-called cards in this application. The cool thing about this is, and this is also concerned traditional, well, first baby steps in enterprise mobility is that we take the user authorization from the very application to the back ends. What we, architectures that we have seen in the past is there is a piece of middleware that is accessing your back end system by means of a technical user. So you cannot no longer distinguish between individual users. You cannot say user A has access to that piece of information. User B has access to this piece of information. This is all in our technology stack. And the cool thing is the application comes with standard features such as sharing and push support. And when I share a card, a piece of information with someone else, he will only, or she will only able to see this if they have the authorization to do so. And so it's also inherently secure. That's a really cool feature we have here. The second thing that I was mentioning is mobile development kit. Mobile development kit is targeting something that analysts like to call citizen developers. So it's basically technical persons with a strong business context and a certain lack of hard core development skills for people who would feel uncomfortable digging into Java or Kotlin native code or something. So what we did is with SAP Web IDE, we are delivering a visual toolkit that allows you to visually design and code applications. By means of two things, number one is clearly something that's not very novel. Something we also have in Android Studio is a WYSIWYG editor basically for user interfaces. The second component is that when you add buttons or input fields to your application, you get to specify validation logic by using Google Blockly. So this is a visual approach to programming basically in case you're not familiar with JavaScript. This is eventually going to be rendered to JavaScript, speaking of which, so you can also directly mess on that level. The outcome of this toolkit is what Tellori calls truly native. We have seen also in Jake's keynote, we have heard about React Native. We have chosen a slightly different path. We are using native script, but the technology stack is essentially the same. So it is an web-based abstraction layer on top of native user interfaces. So I specify a piece of user interface in JavaScript and it's going to be rendered natively. At the same time, my logic is still JavaScript and gets interpreted in a, well, yeah, in the JavaScript runtime, depending on what you have on your mobile device. Okay. This leads to the question, is this cross-platform? Technically, yes, not quite yet. Android support is something that's in the works. It's on our roadmap. It's not been delivered yet. Currently, it's just iOS, but this is our go-to strategic, go-to cross-platform solution going forward. Okay. Last but not least, the very interesting thing, the most interesting thing, I guess, for the audience here is the SAP Cloud Platform SDK for Android. Before I continue talking about this, if you would like to learn more about this, we also have a hands-on later today that was mentioned. That's 5.20pm. Hopefully, I can get my issues sorted out by then. We are going to build an application with that. So you would be able to get some hands-on experience as well, even if you're missing the demo here. So what we did is we are providing both an SDK and the set of tools that integrates with mobile services. The first piece, let's say the developer-pacing piece, is a plugin that we deliver for Android Studio. So you can easily integrate support for SAP applications in Android Studio. And in this plugin, the so-called wizard, you can log into your mobile services account. So you're basically connecting from your local IDE to a Cloud Platform account. Why is that cool? Because, as much as in Firebase, where you can download the Google services, Jason and stuff, the applications you write clearly have a server and a client part. There is some server, some cloud configuration that you need to maintain. And you also need to write matching client code. So what it does is it will allow you to create the configuration on mobile services or reuse existing sets of configuration values and generate a matching app locally. So as soon as you hit the finish button, you will be able to run this application. It will be able to connect to your account. You can log in with your user. And as Sean also spoiled it before, it's generating a crude user interface for you that allows you to explore the underlying data service. At the very least, it's a very simple way to verify that your whole end-to-end setup is working, which is a huge step, actually, towards developer productivity. All right. So those are the things I have here to present to talk about. The rest would have been demos of all these things. That clearly doesn't work. So I'm sorry about this piece. I will be available for you for questions here. And at the booth, thanks for your attention so far. And sorry about the IT issues. That's as much for me as much the first time this happened as for the Droid Compersonal. So I'm very sorry for you having this experience here. Thank you very much. Thanks anyway.
 Michael, yes, is product manager for everything mobile on Android with SAP.  And normally this works much better, but the content of his presentation and what  he has to present to you will be brilliant. I'm convinced. Michael, yes, the stage is yours, please.  Oh, that's definitely going to be a special entry in the history of DroidCon, I believe.  All right, so as Heinrich said, my name is Michael Jess. I work with SAP  product management in the mobile area. And today's session topic is enabling  enterprise mobility with SAP. So it's really unfortunate because it put quite a lot of  effort in the slides and the demos that we are having, so we need to find a way here.  Up front, I can say I'll be at the booth, at the SAP booth later, so I kindly ask you guys,  if you're interested, if you have the time, stop by and I'm going to show you everything.  I don't think that, I mean, this is already difficult, right? There's no way I can show  you this on the mobile device screen. We need to find some other way to do this.  Okay, so before we start, excuse me, I want to ask a question. Is there anyone who is not very  familiar with SAP? Wonderful. Okay, so the big question is what is SAP, actually? What do we do?  And I did try to shortcut this little and did a quick Google search and thought, like, maybe we  find something brief, snappy, description, what we're doing, but actually it's not that simple.  So I thought hard and I found that the easiest way to understand a company is by understanding  the customers and the value preposition they're trying to deliver. So let's put ourselves in the  shoes of an archetypical SAP customer that's not the SAP customer that we have, it's like one kind  of customer which is a production company. So we're trying, and the bubble there is saying  product, right, that's very difficult to spot, we're trying to sell a product. So what do we  need for this? Well, number one is we need a salesperson who is able to sell the product to  a customer. So salesperson reaches out to the customer and says, do you want to have a product?  They take a look at it, say, yes, please, that looks awesome. So can I have one, please? Let me  check the stock. So the salesperson does and finds, oh, no, there is nothing there right now.  So I'll reach out to the production department and ask them if they can produce one of such  product for me. Well, they do need to check the stock and what they find is we're just fresh  out of the manufacturing parts to manufacture this product. So the next department is involved,  which is procurement. We need to purchase parts from our suppliers to be able to manufacture  this product. After procurement, acquire the parts and deliver them, hand them delivered to the  warehouse, financing is involved to pay the supplier. Well, now that this is done, production  department can take the parts out of warehouse, the salesperson is notified that everything is in  place now, the sales order is dispatched to the customer, and last but not least, financing  department is notified that the customer can be built. So this is just one very simple process.  It's one instance of a bunch of processes that we typically find at customers. So why is this  important? Number one is, or what's the issue with this really? The key thing to know is that as  enterprises grow, their need for automation and systems increases as well. So it's not like that  everyone starts with an integrated software suite from scratch. It's really that many enterprises  grow organically. And what you end up with in the end is an unintegrated mess of different  subsystems. There is one system doing financing, maybe there's some spreadsheets floating around  in the enterprise. Maybe there's some other software components for warehousing. And the  issue with that is the enterprise becomes very slow. You will have all sorts of data inconsistencies  and so on and so forth. Now, our founders realized that in a way, all companies are functioning very  similarly. Those departments, everything that's there are similar or if not the same between  companies. And they realized let's just provide standard business software that is solving those  issues. And that's what we are calling enterprise resource planning software. So why is this  interesting and important? Number one is, where do we find mobile in this whole picture? Clearly,  one usual use case is field services. The sales person is very likely to have an app or something  these days to present products to the customer. Another important key area where we typically  find mobile applications is the warehouse where people are running around. So traditionally,  especially the warehouse, is where we find ruggedized devices. And we are also having these  days we're finding some nice instances. For instance, Zebra is also here, delivering  Android ruggedized devices that are commonly found in this area. These days, this is just one of the  product areas that we have. Now, I really need my cheat sheet here. We also have other product  areas. One would be IoT and supply chain management. It's basically another area. We have  supply or relationship management. We also have analytics. What else is there? Strategic  sourcing, supply or relationship management is what I already said. And so on and so forth.  So the really important thing is, last but not least, these days SAP is not only this,  it's not only enterprise resource planning, but we are also a technology company. We also  deliver a technology platform. And this is in essence SAP Cloud Platform. Why I'm leading to  this? Because SAP Cloud Platform is an enterprise Cloud Platform where we are delivering a high  amount, a high number of technical services. And one of these services is a mobile service.  So much as Google is offering Firebase, we are having the SAP Cloud Platform mobile services  that are fulfilling a similar purpose only in the enterprise context.  All right. So that covers what SAP is doing, the enterprise part. But this talk is really about  enterprise mobility. So why is it that enterprise mobility is special or different or more difficult  even than, well, general purpose mobile app developments? Luckily, I found a nice research  paper that summarizing what I felt are the key challenges for enterprises. The first thing is  usability versus security. And you've also heard this in Sean's talk. You've heard this in John's  talk that security is a very dominant topic. Why is that so? Because when we're talking about  enterprise mobility these days, we're generally talking about second generation enterprise  mobility as a research term for this. What does it mean? Basically, mobility since the advent of  smartphones, which is pretty much the summary of the past 10 years. Why is it important? Because  people are bringing expectations from their consumer experience to the enterprise. They're  used to very simple focused apps. They're used to opening an app and understanding it right away.  The days of manuals and reading them are over. And when we personally, I guess you can also  relate to this, when I see an app in an app store and I don't get it immediately, I'm just discarding  it and selecting the next likely candidate. So this is what people expect. Reality in enterprises  even today. IT is very defensive about releasing data. So what we find is like, yeah, we're going  to manage your device. You need to password secure this. Perhaps we're adding some biometrics to the  mix. Then your application is secured by username and password. By the way, please, as soon as you  logged in, you also give a passcode. By the way, I forgot, you will only ever see data in VPN.  That's an awful user experience. Because you have many, many gates before you can actually use the  application. And you need to cross these borders each time. You're basically interacting with the  application. The second thing is innovation or the ability to innovate. The reason here is that  this is like the better case where IT departments or administrators are willing to release data.  What we see otherwise and also something that we at SAP have observed traditionally is that  businesses say or ask the IT department, can we have an app for this? And IT looks at this,  says, this information is way too sensitive to put it anywhere outside our system premises.  We have on-premise systems. The data is not going to leave this. What you would expect probably is  that the business owner says, oh, well, okay, so then there is no app. What happens in reality is  they find ways around it. So there is going to be a growth of point-to-point connections. Because  when you start with one app, you don't stop at one app. There's one app and then there's the next.  And then there's another one. So you have a point-to-point connection from System 8 to Mobile  app A, then there's System B to B, maybe there's a third app that's again connecting to System A  with a variety of authentication schemes, protocols, whatever you use. So there is no common  denominator in all this. And from an IT perspective, this is plenty unmanageable. So not only does  this slow down the speed at which an enterprise can really develop the applications, it is also  like a manageability risk and it puts the data at risk. The third thing is, so we only have four,  the third thing is how does development work in this? Mobile app development is a pretty agile  process. I think you can all agree upon that. How often is a mobile app updated, especially in the  consumer area? And this is also what users expect. Every few weeks, months, perhaps that's it.  In traditional IT, a system upgrade is done every few years, perhaps. The major upgrades project is  kicked off. That will take half a year with a smoke test in the end. And then maybe there is a  rollback because there were some unanticipated issues in all of this. And the sum of all of this  is that there is a mismatch between the skillset that traditional IT has. And when I say IT,  ultimately, also mean developers because in the SAP ecosystem, IT also encompasses development. So  our customers usually have IT departments where they are also mobile app developers, for instance.  That they are not used to this development style. Perhaps they are coming from the old ABAP system.  So there were some hands raised about people who didn't know ABAP. Essentially, ABAP is the  power horse, the old SAP power horse and enterprise resource planning when it comes to  customizing SAP systems. So we had a pretty extensible on-premise development framework  that you could use to tailor SAP applications to your business needs. And those guys are caught in  the whole enterprise cycle mentally. They are just not used to this edge I work for. And this is  also what we are seeing today. So how does that relate to what we have at SAP today? Number one is  we do have an enterprise-ready cloud platform that means security is a very huge concern to us.  And we are implementing a great deal, a great many best practices that we've discovered over the  past years, authentication schemes and so forth in our cloud platform. So that would address  the security needs. And it's pretty easy even to acquire SSO across backend systems. Because some  customers do insist that they want to have multiple backend systems per application. We recommend one  API for one app. But generally speaking, you can have multiple and then there's the SSO question.  Also came up before. The second thing is since we are offering a cloud service, much like Firebase,  we are taking away many of those traditional IT and infrastructure concerns. So not only do we offer  those services, those security-related services, but also other general purpose services such as  push offline and security was the other thing. There was also a visible on the one slide from  Sapphire that Sean presented. Where Bjarne Gorky was presenting the new Android SDK. More on that  in a second, by the way. The third thing is that we are providing, we're delivering development  tools that accelerate your development process. So number one is we are very aware of continuous  integration. Other agile development practices. So our tools are generally ready for this. But  also we are giving you ways to generate applications on the bootstrapping code that's required to  integrate with our cloud platform. And last but not least, if that is still not enough to support  you to get you up to speed with our software, then we also are heavily investing in a strong  partner ecosystem that can serve as implementation partners for those projects.  All right. So that was the theory. Soon there would have followed the demo part. So I'm just  going to talk you through three key development approaches that we have. And this is probably  going to be pretty tough just by talking. So once more, I'd like to ask you if you'd like to join  us at the booth so that I can show you those things as well. I want to talk about three  approaches to developing applications with our SAP technology. Number one is SAP mobile cards.  Number two is mobile development kit. And third thing is the all new SAP cloud platform  SDK for Android that also, as Sean has mentioned briefly in his talk. So the first one, mobile  cards. Mobile cards is a piece of technology that's generally speaking very similar to  passbook style applications. So in case you know those, there are variants for iOS and Android.  It's a kind of application, general purpose application that allows you to take  things like concert tickets with you or tram tickets or business cards. So your data is just  being stored in this application. And you can get this by a bunch of means. Like there are  vendors, ticket vendors who would allow you to store this ticket format on your phone. So we are  basically transferring this concept to enterprise data in that you can take pieces of enterprise  data with you. You can subscribe to feeds more or less from cloud platform containing  address data of partners or customers. Your inbox, for instance, purchase orders you need to  approve. But we also have standard integration with S for HANA that is our latest iteration of  enterprise resource planning systems. We have standard integration for success factors that  would be our HR related, the talent management software, but also for hybris and field glass.  So there is a bunch of standard components that you can use to mobilize pieces of data from  SAP enterprise software. But this is also extensible. You can have your own, well, so-called cards in  this application. The cool thing about this is, and this is also concerned traditional, well,  first baby steps in enterprise mobility is that we take the user authorization from the very  application to the back ends. What we, architectures that we have seen in the past is there is a  piece of middleware that is accessing your back end system by means of a technical user. So you  cannot no longer distinguish between individual users. You cannot say user A has access to that  piece of information. User B has access to this piece of information. This is all in our technology  stack. And the cool thing is the application comes with standard features such as sharing and push  support. And when I share a card, a piece of information with someone else, he will only,  or she will only able to see this if they have the authorization to do so. And so it's also  inherently secure. That's a really cool feature we have here. The second thing that I was mentioning  is mobile development kit. Mobile development kit is targeting something that analysts like to call  citizen developers. So it's basically technical persons with a strong business context and a  certain lack of hard core development skills for people who would feel uncomfortable digging into  Java or Kotlin native code or something. So what we did is with SAP Web IDE, we are delivering a  visual toolkit that allows you to visually design and code applications. By means of two things,  number one is clearly something that's not very novel. Something we also have in Android Studio  is a WYSIWYG editor basically for user interfaces. The second component is that when you add buttons  or input fields to your application, you get to specify validation logic by using Google Blockly.  So this is a visual approach to programming basically in case you're not familiar with  JavaScript. This is eventually going to be rendered to JavaScript, speaking of which,  so you can also directly mess on that level. The outcome of this toolkit is what Tellori  calls truly native. We have seen also in Jake's keynote, we have heard about React Native. We  have chosen a slightly different path. We are using native script, but the technology stack is  essentially the same. So it is an web-based abstraction layer on top of native user interfaces.  So I specify a piece of user interface in JavaScript and it's going to be rendered  natively. At the same time, my logic is still JavaScript and gets interpreted in a, well,  yeah, in the JavaScript runtime, depending on what you have on your mobile device.  Okay. This leads to the question, is this cross-platform? Technically, yes, not quite yet.  Android support is something that's in the works. It's on our roadmap. It's not been delivered yet.  Currently, it's just iOS, but this is our go-to strategic, go-to cross-platform solution going  forward. Okay. Last but not least, the very interesting thing, the most interesting thing,  I guess, for the audience here is the SAP Cloud Platform SDK for Android.  Before I continue talking about this, if you would like to learn more about this,  we also have a hands-on later today that was mentioned. That's 5.20pm. Hopefully,  I can get my issues sorted out by then. We are going to build an application with that.  So you would be able to get some hands-on experience as well, even if you're missing the  demo here. So what we did is we are providing both an SDK and the set of tools that integrates  with mobile services. The first piece, let's say the developer-pacing piece, is a plugin  that we deliver for Android Studio. So you can easily integrate support for SAP applications  in Android Studio. And in this plugin, the so-called wizard, you can log into your mobile  services account. So you're basically connecting from your local IDE to a Cloud Platform account.  Why is that cool? Because, as much as in Firebase, where you can download the Google  services, Jason and stuff, the applications you write clearly have a server and a client part.  There is some server, some cloud configuration that you need to maintain. And you also need to  write matching client code. So what it does is it will allow you to create the configuration  on mobile services or reuse existing sets of configuration values and generate a matching  app locally. So as soon as you hit the finish button, you will be able to run this application.  It will be able to connect to your account. You can log in with your user. And as Sean also  spoiled it before, it's generating a crude user interface for you that allows you to explore  the underlying data service. At the very least, it's a very simple way to verify that your whole  end-to-end setup is working, which is a huge step, actually, towards developer productivity.  All right. So those are the things I have here to present to talk about. The rest would have  been demos of all these things. That clearly doesn't work. So I'm sorry about this piece.  I will be available for you for questions here. And at the booth, thanks for your attention so far.  And sorry about the IT issues. That's as much for me as much the first time this happened as for  the Droid Compersonal. So I'm very sorry for you having this experience here.  Thank you very much. Thanks anyway.
Enabling_Enterprise_Mobility_with_SAP_m3tPauerDrc_0_33647.png Enabling_Enterprise_Mobility_with_SAP_m3tPauerDrc_33648_33662.png
Michael, yes, is product manager for everything mobile on Android with SAP. And normally this works much better, but the content of his presentation and what he has to present to you will be brilliant. I'm convinced. Michael, yes, the stage is yours, please. Oh, that's definitely going to be a special entry in the history of DroidCon, I believe. All right, so as Heinrich said, my name is Michael Jess. I work with SAP product management in the mobile area. And today's session topic is enabling enterprise mobility with SAP. So it's really unfortunate because it put quite a lot of effort in the slides and the demos that we are having, so we need to find a way here. Up front, I can say I'll be at the booth, at the SAP booth later, so I kindly ask you guys, if you're interested, if you have the time, stop by and I'm going to show you everything. I don't think that, I mean, this is already difficult, right? There's no way I can show you this on the mobile device screen. We need to find some other way to do this. Okay, so before we start, excuse me, I want to ask a question. Is there anyone who is not very familiar with SAP? Wonderful. Okay, so the big question is what is SAP, actually? What do we do? And I did try to shortcut this little and did a quick Google search and thought, like, maybe we find something brief, snappy, description, what we're doing, but actually it's not that simple. So I thought hard and I found that the easiest way to understand a company is by understanding the customers and the value preposition they're trying to deliver. So let's put ourselves in the shoes of an archetypical SAP customer that's not the SAP customer that we have, it's like one kind of customer which is a production company. So we're trying, and the bubble there is saying product, right, that's very difficult to spot, we're trying to sell a product. So what do we need for this? Well, number one is we need a salesperson who is able to sell the product to a customer. So salesperson reaches out to the customer and says, do you want to have a product? They take a look at it, say, yes, please, that looks awesome. So can I have one, please? Let me check the stock. So the salesperson does and finds, oh, no, there is nothing there right now. So I'll reach out to the production department and ask them if they can produce one of such product for me. Well, they do need to check the stock and what they find is we're just fresh out of the manufacturing parts to manufacture this product. So the next department is involved, which is procurement. We need to purchase parts from our suppliers to be able to manufacture this product. After procurement, acquire the parts and deliver them, hand them delivered to the warehouse, financing is involved to pay the supplier. Well, now that this is done, production department can take the parts out of warehouse, the salesperson is notified that everything is in place now, the sales order is dispatched to the customer, and last but not least, financing department is notified that the customer can be built. So this is just one very simple process. It's one instance of a bunch of processes that we typically find at customers. So why is this important? Number one is, or what's the issue with this really? The key thing to know is that as enterprises grow, their need for automation and systems increases as well. So it's not like that everyone starts with an integrated software suite from scratch. It's really that many enterprises grow organically. And what you end up with in the end is an unintegrated mess of different subsystems. There is one system doing financing, maybe there's some spreadsheets floating around in the enterprise. Maybe there's some other software components for warehousing. And the issue with that is the enterprise becomes very slow. You will have all sorts of data inconsistencies and so on and so forth. Now, our founders realized that in a way, all companies are functioning very similarly. Those departments, everything that's there are similar or if not the same between companies. And they realized let's just provide standard business software that is solving those issues. And that's what we are calling enterprise resource planning software. So why is this interesting and important? Number one is, where do we find mobile in this whole picture? Clearly, one usual use case is field services. The sales person is very likely to have an app or something these days to present products to the customer. Another important key area where we typically find mobile applications is the warehouse where people are running around. So traditionally, especially the warehouse, is where we find ruggedized devices. And we are also having these days we're finding some nice instances. For instance, Zebra is also here, delivering Android ruggedized devices that are commonly found in this area. These days, this is just one of the product areas that we have. Now, I really need my cheat sheet here. We also have other product areas. One would be IoT and supply chain management. It's basically another area. We have supply or relationship management. We also have analytics. What else is there? Strategic sourcing, supply or relationship management is what I already said. And so on and so forth. So the really important thing is, last but not least, these days SAP is not only this, it's not only enterprise resource planning, but we are also a technology company. We also deliver a technology platform. And this is in essence SAP Cloud Platform. Why I'm leading to this? Because SAP Cloud Platform is an enterprise Cloud Platform where we are delivering a high amount, a high number of technical services. And one of these services is a mobile service. So much as Google is offering Firebase, we are having the SAP Cloud Platform mobile services that are fulfilling a similar purpose only in the enterprise context. All right. So that covers what SAP is doing, the enterprise part. But this talk is really about enterprise mobility. So why is it that enterprise mobility is special or different or more difficult even than, well, general purpose mobile app developments? Luckily, I found a nice research paper that summarizing what I felt are the key challenges for enterprises. The first thing is usability versus security. And you've also heard this in Sean's talk. You've heard this in John's talk that security is a very dominant topic. Why is that so? Because when we're talking about enterprise mobility these days, we're generally talking about second generation enterprise mobility as a research term for this. What does it mean? Basically, mobility since the advent of smartphones, which is pretty much the summary of the past 10 years. Why is it important? Because people are bringing expectations from their consumer experience to the enterprise. They're used to very simple focused apps. They're used to opening an app and understanding it right away. The days of manuals and reading them are over. And when we personally, I guess you can also relate to this, when I see an app in an app store and I don't get it immediately, I'm just discarding it and selecting the next likely candidate. So this is what people expect. Reality in enterprises even today. IT is very defensive about releasing data. So what we find is like, yeah, we're going to manage your device. You need to password secure this. Perhaps we're adding some biometrics to the mix. Then your application is secured by username and password. By the way, please, as soon as you logged in, you also give a passcode. By the way, I forgot, you will only ever see data in VPN. That's an awful user experience. Because you have many, many gates before you can actually use the application. And you need to cross these borders each time. You're basically interacting with the application. The second thing is innovation or the ability to innovate. The reason here is that this is like the better case where IT departments or administrators are willing to release data. What we see otherwise and also something that we at SAP have observed traditionally is that businesses say or ask the IT department, can we have an app for this? And IT looks at this, says, this information is way too sensitive to put it anywhere outside our system premises. We have on-premise systems. The data is not going to leave this. What you would expect probably is that the business owner says, oh, well, okay, so then there is no app. What happens in reality is they find ways around it. So there is going to be a growth of point-to-point connections. Because when you start with one app, you don't stop at one app. There's one app and then there's the next. And then there's another one. So you have a point-to-point connection from System 8 to Mobile app A, then there's System B to B, maybe there's a third app that's again connecting to System A with a variety of authentication schemes, protocols, whatever you use. So there is no common denominator in all this. And from an IT perspective, this is plenty unmanageable. So not only does this slow down the speed at which an enterprise can really develop the applications, it is also like a manageability risk and it puts the data at risk. The third thing is, so we only have four, the third thing is how does development work in this? Mobile app development is a pretty agile process. I think you can all agree upon that. How often is a mobile app updated, especially in the consumer area? And this is also what users expect. Every few weeks, months, perhaps that's it. In traditional IT, a system upgrade is done every few years, perhaps. The major upgrades project is kicked off. That will take half a year with a smoke test in the end. And then maybe there is a rollback because there were some unanticipated issues in all of this. And the sum of all of this is that there is a mismatch between the skillset that traditional IT has. And when I say IT, ultimately, also mean developers because in the SAP ecosystem, IT also encompasses development. So our customers usually have IT departments where they are also mobile app developers, for instance. That they are not used to this development style. Perhaps they are coming from the old ABAP system. So there were some hands raised about people who didn't know ABAP. Essentially, ABAP is the power horse, the old SAP power horse and enterprise resource planning when it comes to customizing SAP systems. So we had a pretty extensible on-premise development framework that you could use to tailor SAP applications to your business needs. And those guys are caught in the whole enterprise cycle mentally. They are just not used to this edge I work for. And this is also what we are seeing today. So how does that relate to what we have at SAP today? Number one is we do have an enterprise-ready cloud platform that means security is a very huge concern to us. And we are implementing a great deal, a great many best practices that we've discovered over the past years, authentication schemes and so forth in our cloud platform. So that would address the security needs. And it's pretty easy even to acquire SSO across backend systems. Because some customers do insist that they want to have multiple backend systems per application. We recommend one API for one app. But generally speaking, you can have multiple and then there's the SSO question. Also came up before. The second thing is since we are offering a cloud service, much like Firebase, we are taking away many of those traditional IT and infrastructure concerns. So not only do we offer those services, those security-related services, but also other general purpose services such as push offline and security was the other thing. There was also a visible on the one slide from Sapphire that Sean presented. Where Bjarne Gorky was presenting the new Android SDK. More on that in a second, by the way. The third thing is that we are providing, we're delivering development tools that accelerate your development process. So number one is we are very aware of continuous integration. Other agile development practices. So our tools are generally ready for this. But also we are giving you ways to generate applications on the bootstrapping code that's required to integrate with our cloud platform. And last but not least, if that is still not enough to support you to get you up to speed with our software, then we also are heavily investing in a strong partner ecosystem that can serve as implementation partners for those projects. All right. So that was the theory. Soon there would have followed the demo part. So I'm just going to talk you through three key development approaches that we have. And this is probably going to be pretty tough just by talking. So once more, I'd like to ask you if you'd like to join us at the booth so that I can show you those things as well. I want to talk about three approaches to developing applications with our SAP technology. Number one is SAP mobile cards. Number two is mobile development kit. And third thing is the all new SAP cloud platform SDK for Android that also, as Sean has mentioned briefly in his talk. So the first one, mobile cards. Mobile cards is a piece of technology that's generally speaking very similar to passbook style applications. So in case you know those, there are variants for iOS and Android. It's a kind of application, general purpose application that allows you to take things like concert tickets with you or tram tickets or business cards. So your data is just being stored in this application. And you can get this by a bunch of means. Like there are vendors, ticket vendors who would allow you to store this ticket format on your phone. So we are basically transferring this concept to enterprise data in that you can take pieces of enterprise data with you. You can subscribe to feeds more or less from cloud platform containing address data of partners or customers. Your inbox, for instance, purchase orders you need to approve. But we also have standard integration with S for HANA that is our latest iteration of enterprise resource planning systems. We have standard integration for success factors that would be our HR related, the talent management software, but also for hybris and field glass. So there is a bunch of standard components that you can use to mobilize pieces of data from SAP enterprise software. But this is also extensible. You can have your own, well, so-called cards in this application. The cool thing about this is, and this is also concerned traditional, well, first baby steps in enterprise mobility is that we take the user authorization from the very application to the back ends. What we, architectures that we have seen in the past is there is a piece of middleware that is accessing your back end system by means of a technical user. So you cannot no longer distinguish between individual users. You cannot say user A has access to that piece of information. User B has access to this piece of information. This is all in our technology stack. And the cool thing is the application comes with standard features such as sharing and push support. And when I share a card, a piece of information with someone else, he will only, or she will only able to see this if they have the authorization to do so. And so it's also inherently secure. That's a really cool feature we have here. The second thing that I was mentioning is mobile development kit. Mobile development kit is targeting something that analysts like to call citizen developers. So it's basically technical persons with a strong business context and a certain lack of hard core development skills for people who would feel uncomfortable digging into Java or Kotlin native code or something. So what we did is with SAP Web IDE, we are delivering a visual toolkit that allows you to visually design and code applications. By means of two things, number one is clearly something that's not very novel. Something we also have in Android Studio is a WYSIWYG editor basically for user interfaces. The second component is that when you add buttons or input fields to your application, you get to specify validation logic by using Google Blockly. So this is a visual approach to programming basically in case you're not familiar with JavaScript. This is eventually going to be rendered to JavaScript, speaking of which, so you can also directly mess on that level. The outcome of this toolkit is what Tellori calls truly native. We have seen also in Jake's keynote, we have heard about React Native. We have chosen a slightly different path. We are using native script, but the technology stack is essentially the same. So it is an web-based abstraction layer on top of native user interfaces. So I specify a piece of user interface in JavaScript and it's going to be rendered natively. At the same time, my logic is still JavaScript and gets interpreted in a, well, yeah, in the JavaScript runtime, depending on what you have on your mobile device. Okay. This leads to the question, is this cross-platform? Technically, yes, not quite yet. Android support is something that's in the works. It's on our roadmap. It's not been delivered yet. Currently, it's just iOS, but this is our go-to strategic, go-to cross-platform solution going forward. Okay. Last but not least, the very interesting thing, the most interesting thing, I guess, for the audience here is the SAP Cloud Platform SDK for Android. Before I continue talking about this, if you would like to learn more about this, we also have a hands-on later today that was mentioned. That's 5.20pm. Hopefully, I can get my issues sorted out by then. We are going to build an application with that. So you would be able to get some hands-on experience as well, even if you're missing the demo here. So what we did is we are providing both an SDK and the set of tools that integrates with mobile services. The first piece, let's say the developer-pacing piece, is a plugin that we deliver for Android Studio. So you can easily integrate support for SAP applications in Android Studio. And in this plugin, the so-called wizard, you can log into your mobile services account. So you're basically connecting from your local IDE to a Cloud Platform account. Why is that cool? Because, as much as in Firebase, where you can download the Google services, Jason and stuff, the applications you write clearly have a server and a client part. There is some server, some cloud configuration that you need to maintain. And you also need to write matching client code. So what it does is it will allow you to create the configuration on mobile services or reuse existing sets of configuration values and generate a matching app locally. So as soon as you hit the finish button, you will be able to run this application. It will be able to connect to your account. You can log in with your user. And as Sean also spoiled it before, it's generating a crude user interface for you that allows you to explore the underlying data service. At the very least, it's a very simple way to verify that your whole end-to-end setup is working, which is a huge step, actually, towards developer productivity. All right. So those are the things I have here to present to talk about. The rest would have been demos of all these things. That clearly doesn't work. So I'm sorry about this piece. I will be available for you for questions here. And at the booth, thanks for your attention so far. And sorry about the IT issues. That's as much for me as much the first time this happened as for the Droid Compersonal. So I'm very sorry for you having this experience here. Thank you very much. Thanks anyway.
today's session topic is enabling enterprise product for me. Well, they do need to check the realized let's just provide standard business running around. So traditionally, especially the SAP Cloud Platform mobile services that are is secured by username and password. By the way, development work in this? Mobile app development new Android SDK. More on that in a second, by the both an SDK and the set of tools that integrates