This is the second blog post of a series around the enterprise mobility IT team at SAP. We are an internal team focused on managing mobile devices, applications, and developing custom apps for SAP’s 100,000 employees. I have been a part of this team for the past six years. I believe we have some unique stories, software, tools, and insights to help others in the community considering, or currently undertaking, some of the challenges which surround mobility and its adoption in the enterprise.
Introduction
Apps have been a cornerstone for deploying mobile devices at SAP, and like any symbiotic relationship, the success of one depends on the success of the other. Our employees have realized the benefits of simplicity, speed, and availability in consumer applications and the power of their mobile devices. They have brought that same expectation to the enterprise and expect that these same traits be available in their work lives and daily processes. This is often how our mobile projects are initiated. In my eyes, the employees who demand innovation are the unicorns of the enterprise – they are passionate, willing, and eager to buck the norm and innovate on processes, which could be decades old, but rife for improvement.
These key users drive the project initiation process and pitch us a concept to develop and deliver the solution for their target audience. They will often be the champions of the application, define the requirements, and act as our business liaison through the development lifecycle. The ideas are sometimes typical, and common themes are related to:
- An opportunity to save costs or time by automating an outdated or manual process
- The replication of a consumer or Fiori app because of its popularity, usage, or effectiveness
- A GUI process might be too detailed, and a team wants to simplify it or make it available anywhere
[The Fiori/UI5 web apps idea may spark some questions – why don’t we just use these web applications on our mobile devices? We firmly believe that native apps provide a superior end-user experience to apps that are simply ported or even optimized for mobile devices. This topic and discussion could be a blog post in itself.]
In addition to the employee request process, we also develop mobile apps that we as a team believe might benefit our end users. A few examples of these include:
- A showcase of the SAP technology or platform which we believe may display their opportunities and spark new ideas
- The mobile platform (iOS or Android) might deliver an innovation that we could showcase
The Project’s success depends heavily on these key users’ knowledge and experience as a company, as a company, have thousands of business processes and millions of lines of custom code in our core ERP system. As a team, we would not be able to successfully take an idea to fruition without constant app reviews and feedback from these employees.
Development Team Org Chart
The reason for sharing our organization chart is that I believe it provides some context for achieving our goals and end-user demands. This also shows that we have full-time designers and testers in the same team. In other organizations, this might not always be the case, but I believe the alignment and direct report responsibilities ensure that all critical components of the SDLC are controlled and assigned by the Head of Mobile App Development (The fabulous and talented Lisa Brown)
Design: Focus on Design Thinking, Icons, Prototyping, and Visual design. Marketing helps us promote our internal apps to end-users through app campaigns, videos, or content.
App owners: For our larger apps, we assign an owner responsible for the overall management and success of the Project and its on-going operations. App owners might be developers on other projects and could also manage multiple apps.
Developers: Tech leads, frontend, backend developers and testers.
Operations: Manage support tickets and escalate any high priority issues.
We have adopted two core development methodologies, Agile SDLC, and Design Thinking, both of which have significantly increased our projects’ effectiveness and success in conjunction with the key users.
Agile SDLC
Similar to most software development lifecycles, the native mobile lifecycle is very similar:
Our primary method of requirement generation occurs during our design thinking workshops with key users. It encompasses the “Discover and Design” aspects of our Agile SDLC with demos at each sprint’s end. We generally document our requirements, integration, flowcharts, design documents, and usage scenarios in Mural. Both designers, developers, and testers are included in the design thinking sessions to ensure that the appropriate knowledge transfer and collaboration occur from the start.
Developers and architects also use the design phase to consider the application’s requirements from a technical perspective. Over the last few years and ~ 40 apps, we have seen a reasonably consistent categorization of projects from an architecture perspective:
Once the requirements are reasonably well defined, the frontend prototyping is done by our design team using Sketch with the helpful Fiori and Mobile SDK design stencils. Our key business users then validate the prototypes, and the development sprints are kicked off. We use a mix of Github for source control and Jira, or Github again, for Project, sprint, and issue tracking.
What is unique about mobile app development is that it generally has a variety of integrations and dependencies. Some examples of these in our case include:
- Security – SSO certificates
- Connectivity – SAP Cloud Platform, SAP Cloud Connector, SAP Mobile Platform, SAP Gateway
- Analytics – Crash Log Reporting, Usage Analytics
- Support – In-app help, feedback. We have defined some of these as “requirements” for each of our apps and ensures that our end users have a consistent experience.
These integrations and frameworks avoid rewriting the same functionality in each app we develop, which speeds up development time, provides a consistent end-user experience, and distributes some implementation efforts.
From a coding perspective, each developer can use the IDE or tools that they find the most productive to get their tasks done.
iOS, macOS, tvOS Development:
- We migrated to be 100% swift based after a great 5-day “Objective C to Swift” Nerd Ranch iOS Training event for all of our developers shortly after the Swift announcement.
- XCode – Obviously 🙂
- CocoaPods/SPM
- SAP Mobile SDK
Android Development:
- Android Studio or IntelliJ
- SAP Mobile SDK
Backend Development:
- Our backends are all application-specific but do have one thing in common, which is they all run on SAP Cloud Platform
- It depends on the runtime, but we have Node.JS, Java, and XS Classic backends powering our mobile apps
- For ERP integration, we develop or reuse Gateway services written in ABAP
[I will venture into more specific implementation details of each application type in a future blog post.]
Testing
Like most development teams, we aspire to write as many unit tests as feasibly possible, and we have recently implemented SauceLabs for running integration testing on physical devices.
Deployment
Building our internal apps is done with xMake [https://xmake.io/#/getting_started], which we use to sign and compile the app for distribution. We currently have two separate MDM solutions that are specific to each platform type. iOS, macOS, and tvOS apps are uploaded to Jamf. Our Android apps are uploaded to a managed Google Play Store and exposed to VMWare Workspace One, our MDM solution for Android devices.
App Discovery
With a user base of roughly 100,000 employees, marketing is an essential aspect of our deployment process as we need to inform potential users about the availability of a new app. Like the consumer world, email is not always the most effective method of a “call to action” request, and we also do not want to spam our users continuously. In the past, we have printed posters, had in-person events, internal blogs, or shared articles for newsletters. We also do some in-app cross-promotion marketing, which might be useful to a specific user base. An example of this would be a banner or pop-up in our of our Sales Apps, announcing another a new Sales App. All of our apps are listed in the relevant internal app store, which is another avenue for app discovery.
Updates
Another unique aspect of mobile apps is the expected fast cadence of bug fixes and feature requests. As an app matures, the updates, changes, and requests decrease, but we ultimately still have a responsibility to our end users to ensure support, uptime, and availability. We have developed a custom framework for in-app help and release notes. This has two significant benefits: It shows we are actively listening to feedback and providing features and fixes. Secondly, it enables the users to help themselves before creating support tickets.
Conclusion
This is a high-level summary of some of the aspects we as an internal Enterprise Mobility development team focus on when we take an idea from conception to production. Does your team do something different? Please let me know; we are always looking for ways to learn and improve our mobile development processes and tools.
