This is another blog post of a series around the enterprise mobility IT team at SAP. We are an internal team focused on managing mobile devices, mobile applications, and developing custom apps for SAP’s 100,000 employees. 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
As the enterprise mobility team, we manage over 100 different mobile apps at any given time. This includes volume purchase apps, consumer versions of apps listed in our MDM, and custom-developed apps. In my last post about Relay, our custom real-time chat application, we have seven different components that need to be managed and maintained for this single app (iOS, Android, Web, macOS, Linux, Windows, and Server). A good majority of our custom apps are similar, and have multiple components, all of which have independent release cycles and potentially different teams that manage them. We initially used an excel spreadsheet to track and manage these applications and their corresponding components. This became a logistical challenge as our portfolio and responsibilities grew. Our commitment to our end users also grew during this time, and we wanted to provide a consistent support experience across operating systems and apps. We took this opportunity to step back and look at the process holistically, and decided to redesign how we managed and supported apps that we were responsible for. We also defined some essential services and features each of the apps should have, independent of their platform. I touched on this in a previous blog, but from a support perspective each app should include:
- The ability to get in-app help
- Announcements or news about the app
- Information on past or future releases
- The ability to provide feedback to the app owners and developers
Some of the challenges each persona faced were:
App Developers:
- Write repetitive code in each app to include these services
- Having to recompile the app if the in-app help or support contacts had changed
- Have a deploy a new release to inform users about features, upcoming changes or potential outages
App Owners:
- Have to manage critical information about each app in spreadsheets
- App owners are distributed across different orgs and teams
- A dependency on developers to compile and distribute a build just to include in-app help, release notes, upcoming changes, or outages
End Users:
- If I need assistance in an app, where and how do I get help?
Additionally, in our enterprise mobility scenario, we use Jamf for iOS and Intune (recently) for Android. We run our backends and web applications on and SAP Business Technology Platform (Neo and Cloud Foundry), and to get a holistic inventory of apps and components, we would need to visit three different tools.
Meet application support center
To solve these challenges, we decided to develop a management and support tool called application support center – and we have just open-sourced it! It consists of an administration console and individual OS specific SDK’s, which can be referenced or included in your web or mobile apps.
The tool solves some of the challenges and requirements listed above and a few others:
- App Repository: It is a consolidated categorized list of your applications or components. Pertinent details on the app such as a source code link, go-live date, status and bundle IDs. It also lists important contacts. We have also included a free form key-value field allowing us to store helpful details specific to our use case, for example, which apps have push notifications enabled, or a particular feature or function.
- Knowledge Base: The platform provides a consolidated location to store help information for each app. This content can be created and managed by app owners through the console and accessed by end-users directly in-app.
- Release Insights: I have mentioned this in previous posts, but we like to keep our users informed of new releases and updates to our apps. It shows our commitment and is a great way to build a healthy relationship between our end users and developers by incorporating features and fixes. asc provides the ability to store release notes, which can also be accessed in-app by end-users.
- Announcements: In order to keep our end users informed on important details about the app (without invasive push notifications or emails), the tool supports creating announcements that are shown to end-users when they open the app. This could be upcoming changes, outages, known problems, or app-related news.
All of the above are available to our end-users in their apps via an SDK which is synchronized with the central information repository. Most of these are optional features that can be used, and are specific to each component of your application. For example, we only use the app repository to track app developers for the Relay backend component. For the iOS, web, and Android apps, we use the app repository, help, release notes, and announcement features.
Keep in mind that application support center is not a devops tool, runtime environment, nor does it host your apps, it is not a middleware layer, MDM or an app development tool.
Persona: Developers, App Owners and Supporters | |||
 |  |  |  |
| Admin Console | Admin Dashboard | Reporting | System Configuration |
 |  |  | |
| Help content | Announcements | Release notes | Keywords |
Persona: End Users on UI5 app | |||
 |  |  | |
| Help center | App help | App release notes | |
Persona: End Users on iOS app | |||
 |  |  | |
| Help center | App help | App release notes | |
Persona: End Users using Web Interface | |||
 | |||
| Help center | |||
Architecture
We run our asc instance on SAP Cloud Foundry but it can be run anywhere the requirements are met (Node.JS & Postgres). Keep in mind that Cloud Foundry provides some convenience features and handles our security, so these will need to be considered if you deploy asc anywhere else. The image below shows details on the components and high-level architecture of the setup.
Conceptually, developers and application owners create and manage content in the Admin console. Developers then include an SDK (iOS, Android) or reference (HTML5) in each of their apps. The apps then synchronize data from the backend, and displayed in the apps to end-users. If you do not want to include the asc SDK in your apps, you can open the Web UI, which is a simple, single webpage containing the same information as what would be visible in your app, but accessible through the browser.
Open Source
Why open source the tool?
1.) We think other companies might be facing similar challenges to us from an application management perspective, and want to share the tools we have developed.
2.) We hope that the open-source community and contributors will enhance and improve this concept further. Check out our roadmap and issues if you would like to get involved.
3.) If you have tested the tool or look closely, you will notice some additional integrations. We are referencing some additional systems we have in IT, such as app usage. We have also integrated a feature allowing app developers to upload apps to Jamf, our iOS MDM solution. We hope some other IT teams will want to integrate their own services or platforms and share these with others. Check out our Projects page on Github if you want to contribute.
Learn More
If you want to learn a little more about asc or set up your own instance to try it out, check out the Github repo here: https://www.github.com/sap/application-support-center Our wiki shares necessary setup and implementation details, and if you run into any problems, please feel free to create a Github issue, and we will look into it.
You must be logged in to post a comment.