Unvired Digital Enterprise Platform is now fully integrated with the Vault Project from Hashicorp to enhance the security

Unvired Digital Enterprise Platform is now fully integrated with the Vault Project from Hashicorp to enhance the security

Blog Security

The Unvired Digital Enterprise Platform (UDEP) encrypts all configuration and messages before persistence. Industry best practices are followed for the encryption. All data for a company is AES 256 encrypted (the same technology your bank uses to secure your transactions) and decrypted with a symmetric key. Each company has its own symmetric key so that data across companies can never be accessed under any circumstances. Further to secure the keys, they are stored in key files in a landscape that is physically separate from the servers running the UDEP. For e.g. in an AWS environment, they are stored in S/3. The passwords to these key files are stored separately after encrypting with a landscape key.

To further harden this, UDEP is now fully integrated with the VaultProject from Hashicorp. From the Hashicorp website: “Vault secures, stores, and tightly controls access to tokens, passwords, certificates, API keys, and other secrets in modern computing. Vault handles leasing, key revocation, key rolling, and auditing. Through a unified API, users can access an encrypted Key/Value store and network encryption-as-a-service, or generate AWS IAM/STS credentials, SQL/NoSQL databases, X.509 certificates, SSH credentials, and more.”

So how exactly does UDEP use Vault?

The passwords for the key files are now stored in Vault.  Each company has its own password stored in Vault. The access tokens for Vault are passed to UDEP via environment variables. These access tokens have tightly configured policies to ensure that the tokens can only access and perform the permitted operations.

Additionally, the auth tokens can be response wrapped. In this case, the real tokens are inserted in a “cubby hole” in Vault and a temporary one-time access token is instead configured for UDEP. UDEP unwraps the token and then uses the “real access token” to access the keys. In case the unwrap operation fails, this indicates that some other operator has intercepted the key and the system can be shut down immediately and the vault sealed to prevent any further compromise. This also ensures that the environment variables that are configured are practically useless for a hacker as they cannot be reused.

To prevent leakage of data in case a token is compromised, the tokens can also be configured to be renewable periodically. Issued tokens can be revoked and then access of keys via these tokens is not permitted.

Further UDEP also supports rotating keys used via Vault. Keys of all companies can be rotated and ensures that your data is as secure as required.

To summarize:

  1. Keys are stored in a separate Vault.
  2. Access is provided via response wrapped one time tokens.
  3. Access tokens can be periodic to facilitate revocation in case of a compromise.
  4. Keys can be rotated according to your security policy.
  5. Vault provides a detailed audit log that records all access operations for monitoring and verification.

So with the UDEP and Vault integration, all your configuration information and business data that is flowing through the UDEO is protected to the maximum. Stay safe.

Customer Case Study- Part 3: Integrating BLE in Hybrid Mobile Apps

Customer Case Study- Part 3: Integrating BLE in Hybrid Mobile Apps

Blog Developer's Viewpoint Lessons Learnt Technology

In Part 1 of this blog, we looked at building Hybrid Mobile Apps and the technologies one could use. In part 2, we looked at the translation of the app so users can interface with the app in the language of their choice. In this concluding part of the blog, we will look at peripheral integration in Hybrid Mobile Apps.

The app that we developed connects to a smart pillbox which is essentially a Bluetooth Low Energy (BLE) device. Ionic Native BLE plugin (https://ionicframework.com/docs/native/ble/) comes in handy.

A little background on the data organization in a BLE device:

Every BLE device advertises something called as services. Each service corresponds to a feature. Usually one of these services deals with device discovery, which holds device identifying information in one of its characteristics. Services and characteristics are UUIDs and they are specific to a class of BLE devices that your application supports. Typically, you get this information from your BLE device manufacturer. So, before you start integrating to a BLE device, you should have this information ready.

Some of the best practices for integrating a BLE device:

1. Always scan for a specific service for connecting to a BLE device. Scanning for all services slows down the discovery process.
2. Some BLE devices require you to connect with them before they give out device identifying information. In those cases, if you are connected to a wrong BLE device, you should disconnect and continue with the discovery process. Remember that BLE devices can only connect to one device (master) at a time, if you do not disconnect, then this BLE device will not be discoverable.
3. A very important usability aspect is the information you provide to the user. You need to have the Bluetooth turned on in the device before you initiate any BLE discovery process. As a developer, you need to identify the start of Bluetooth in the device and provide options for the user to turn on Blue-tooth. On mobile devices, turning on Bluetooth can only be user initiated, so you can put up messages, possibly navigate to the settings screen where the user can turn on Bluetooth.
4. Always display the state of the Bluetooth discovery process to the user. The user needs to know if you are searching for devices, whether you discovered any devices or if you are connected to the target device, the battery state of the connected device etc.
5. It is always a good practice to create a common service/module to deal with Bluetooth connection. Encapsulate all the methods and data in this module so that it can be imported into other apps if required.

If you have any query regarding Hybrid Mobile Apps, please write to us at developers@unvired.com and we shall answer your queries at earliest.

Customer Case Study- Part 2: Translating a Hybrid Mobile App

Customer Case Study- Part 2: Translating a Hybrid Mobile App

Blog Developer's Viewpoint Lessons Learnt Technology

In Part 1 of this blog, we looked at building Hybrid Mobile Apps and the technologies one could use.  In this part, we will look at the translation of the app so users can interface with the app in the language of their choice.

To start, you need to add translation support to your app in order to render your app in multiple languages. Here’s how we did it @ Unvired for Hybrid Mobile app.

1. Identify and enable strings for translation:

All user-facing strings need to be translated. However, some strings could be embedded in HTML, while others are in Typescript code. We need to enable strings in both these places for translation. Angular JS provides an internationalization library (i18n) (https://github.com/ngx-translate/core) specifically for this purpose. For enabling translation,

we used a translate pipe in HTML:

<div>{{ “Messages” | translate }}</div>

we used a method call for strings in code:


In both these cases, we are translating the string “Messages”.  The way it works, this library looks up for translation for the key “Messages” in a special strings file (which we will be constructing next), and once located, replaces the “Messages” string with the translated value.

2. Construct Strings file:

Strings file in an ionic app is a JSON file containing key-value pairs. The value containing the translation for the key. We need to add a strings file for every language the app supports. Each of these files should have the translation for all strings which require translation.

We automated the process of extracting all translatable strings onto a strings file with the help of an npm tool called angular-translate-extract (https://www.npmjs.com/package/angular-translate-extract) which can be configured as a grunt task. However, this project was published two years ago and not in active development and was only able to extract strings from HTML and JavaScript code, which we didn’t have in our project. Luckily, this project supported adding of a custom parser which accepts a pattern (Regular expression) for extracting strings. We used this excellent website https://regex101.com and constructed a regex pattern to match the translatable strings in the code. Depending on the number of languages to support, you will need to configure the grunt tasks to generate required output files.  For e.g. en.json (English), es.json (Spanish) etc.

We ran the grunt task and we were able to extract all the strings in the app to the required files.   These json files can then be handed off to the translators to provide the translated strings.  Note that the files need to be saved as UTF8 encoding to ensure the strings are saved correctly.

In the last step, we added a way for the user to select his preferred language.

3. Select preferred language in the app:

We created a new page in the app to select the preferred language and made it as the very first screen of the app. Only after the user selects a language, she can continue with using the app. Once a user selects the language, we made that language as the default language for the app so that all strings get displayed in that language. We also stored this selected language code locally, so that next time the user starts the app she does not have to choose the language again. The app also allows the user to switch languages after login if they desire.

Note that some apps take the approach of using locale to figure out the language to use.  For e.g. German in Germany or French in Paris could be obvious choices once can make in these countries. While this is a very valid approach we feel that it’s better to use this mechanism to default a choice for the user but still permit them to choose their language of choice (for e.g. Spanish in the US) rather than the tie to local.

3. How do we know all strings are covered?

Instead of manually updating strings in json files and verifying, one can generate something called as pseudo-localized strings file. There are various online tools available which can generate this file for you. These tools make the value visually distinguishable from the original by replacing the original characters with accented characters. We replaced our Spanish son file with pseudo-localized strings file and executed the project.

We tested and enabled few other strings for translation. Ran the grunt tool to extract these strings. Re-generated pseudo-localized strings. We did this cycle many times until we were sure that all strings are covered for translation.

4. Translating Dates:

While translating messages can be done by language experts and complete coverage can be achieved, the dates (Month and Day names) were in fact not translated and had to be handled programmatically. We had used Moment.js library for formatting dates and this library supports internationalizing by means of calling a very simple function:


After this point, all day and month names were translated into Spanish.

5. The last mile, let the server know what language to speak:

Few messages that were displayed in the app were sent from the server (this could also be true for errors).  Since all the messages from the server to the user have to be in the user’s preferred language, so we created a new API in the server to accept and store user’s preferred language. We added Internationalization support for all the user-facing strings sent by the server and got it display in the user’s preferred language in the device.  This can be achieved with standard web app internationalization (similar to some of the details above).

Read Part 3 of this blog about Integrating BLE in Hybrid Mobile Apps.

Customer Case Study- Part 1: Migrating from Native to a Hybrid Mobile App

Customer Case Study- Part 1: Migrating from Native to a Hybrid Mobile App

Blog Developer's Viewpoint Lessons Learnt Technology

At Unvired, we were tasked with rebuilding an iOS native app onto an HTML5 Hybrid for a healthcare services company.  The main objective was to target the ever increasing Android market and doing it with a common code base for Android & iOS. This will be a three-part blog dealing with the technologies we use, how we achieve peripheral integration and how we internationalize our apps for all markets. I want to share my thoughts in developing this application and explain why we think building a hybrid mobile app is probably more suited now than ever before.

The advantages of building a Hybrid app over platform-specific native apps are many. On the face it, you get to maintain a single code base across platforms. Writing the code just once and getting it run on multiple platforms is not just cool but also saves a lot of time and money. Effectively, this means you get to market your app faster on multiple devices and don’t need to choose one set of users (or market) over the other.

The various technologies we used for app development:

  • Ionic Framework (ionicframework.com):

Ionic has a rich set of mobile-optimized UI components which when run on a mobile device, offers native look and feel. It also integrates with the Cordova Framework (https://cordova.apache.org) for accessing native capabilities. This basically means you can support any native feature like Camera, custom Hardware integration, Push Notifications etc., from your Hybrid mobile app.

  • Angular JS with Typescript:

Angular JS is an HTML5 technology which lets you manipulate an HTML on the fly.  The latest version of Angular JS (Angular JS 4) uses Typescript (https://www.typescriptlang.org) for app development. Typescript converts to JavaScript under the hood but offers big benefits like object-oriented design, type-checking, ahead of time compilation, all of these which are not available for JavaScript developers.

  • Visual Studio Code IDE:

This is an IDE from Microsoft and offers many developer-friendly features like code refactoring, navigation using hyperlinks, type-checking, built-in source control etc. This IDE checks for syntax errors in the code and the developer can fix the code without having to compile the code in order to spot errors. Source control integration with Git makes it even more compelling.

Under the hood:

Ionic helps realize “near” native look & feel in hybrid. The UI elements in Ionic are so well designed, it’s many times visually hard to distinguish a native app from an Ionic app. This means your users won’t have to adjust to a new UI paradigm when they upgrade to a hybrid version of your app.

On the performance side, Ionic has improved dramatically over last few years. For example, it uses WKWebView when the app is run on an iOS device. WKWebView is a high-performance webpage rendering engine from Apple. Ionic uses the best technology in each of the platforms for delivering the content. Because of all these reasons, the app experience in Ionic is such a breeze.

The app that interfaces with a smart pillbox to help patients take the right medication. Communication with the Bluetooth enabled Pillbox is mission-critical for this app. This calls for tight hardware integration with the native layer and Ionic aces in this aspect.

Ionic has a vast set of native integrations which are called plugins for use by the developers. These plugins tap into the native capability in each of the supported platforms and offer a common interface for interaction through Typescript. Our target platforms of this app were iOS and Android and we used a Bluetooth Low Energy plugin (https://ionicframework.com/docs/native/ble/) for integrating with the smart pillbox. One can find a list of all the native plugins available in the Ionic Website. If you don’t find an appropriate plugin for your requirements, you can develop one quite easily by using the Cordova Framework (https://cordova.apache.org).

Overall, adopting HTML hybrid app has been a rewarding experience so far and it offers great benefits like ease of development, quick time to market the app, great performance and robust integration with native platform. Given all these benefits, it’s probably the right time to make the switch to the hybrid route for developing multi-platform mobile apps.

Note: You are probably aware that React Native has a lot of traction over hybrid in developing mobile apps, React Native though takes a different approach to mobile development.  React is “Learn once, write anywhere” whereas Hybrid is “Build once, run anywhere”.

Read more on React in our blog Part-2.

Progressive Web Apps vs. Native Mobile Apps

Progressive Web Apps vs. Native Mobile Apps

Blog Technology Viewpoint

As you go about implementing your Digital/Mobile strategy, one of the decisions that you will have to make is whether to build for the Mobile Web or Native apps or both. There has always been a debate around this, but the lines between them are blurring now. Gone are the days when you were required to go Native for high-performance apps, offline capability, or if you needed an app icon installed on the home screen. Although web technologies have evolved significantly, there are no clear-cut answers yet. Specifically, Google has invested in technologies that enable the creation of Progressive Web Apps (PWAs), which combine the best of the two worlds—that of mobile web and native apps. We share below our take on PWAs based on research on this topic and our experience of enabling customers with their digital/mobile requirements.

What are PWAs?

In a nutshell, PWAs bring native app-like functions and features to websites. They should work on all smart devices, adapting the performance to the ability of the device, browser, and connection.

The key Benefits are:

  • Works across platforms (Desktop, Web, Android, Windows, and iOS (Safari has limitations)
  • Option to save the PWA icon to the Home screen
  • The ability to send push notifications
  • Some offline capability to provide a good User Experience is possible
  • Make payments
  • Access native device features like camera
  • No need for any App download or seek Approval from App Stores
  • Easier to use in Low Bandwidth Conditions or on lower end smart devices
  • Easy Discoverability and Shareability (just share a link)
  • Less Costly to Develop compared to Native apps as no need to maintain different code bases for Web, Android, IOS, and Windows
  • Fast Loading: Order of Magnitude Lower Data Sizes compared to Native apps

In fact, one of the most attractive features of PWAs is their download size, compared with iOS apps and Android apps. This is important because the smaller the size, the quicker the download, and better the performance.

Limitations of PWAs

It should also be noted that PWAs today have some limitations, especially for the iOS Platform. As Safari has yet to implement the Service Worker feature, PWAs on iPhones and iPads are not able to send push notifications or work offline.  As far as Windows goes, Microsoft is in the process of supporting Service Workers in their Edge browser.

PWAs Vs. Native Apps

Now that we understand PWAs, a natural question to ask is whether PWAs eliminate the need for Native apps. This question is best answered by analyzing what strategy enterprises are actually undertaking in the real world.  Google has shared the Case Studies of Twitter and Lancome, and the highlights are:

Twitter PWA Case Study

The Twitter Lite PWA combines the best of the modern web and native features. It became the default mobile web experience for all users globally in April 2017. Twitter developed Twitter Lite to deliver a more robust experience, with explicit goals for instant loading, user engagement, and lower data consumption. Twitter’s website reaches millions of users, but it’s traditionally been difficult to re-engage users on the mobile web. After implementing the “Add to Home screen” prompt asking users to save Twitter Lite to their home screens, Twitter has seen 250,000 unique daily users launch Twitter Lite from the home screen 4 times a day on average. Twitter also implemented web push notifications that work the same as those from native apps and arrive even if the user’s browser is closed. The implementation is delivering over 10 Million push notifications a day. Full details can be read at:


Lancome PWA Case Study

At first, Lancôme considered building an e-commerce mobile app but decided that an app only made sense for customers who visited regularly. They understood that shoppers on Lancôme’s mobile site behave differently, and wouldn’t return to an e-commerce app. Lancôme wanted to build the right user experience (UX) on all of their devices. The company needed a fast-loading, compelling mobile experience, similar to what they could achieve with a native app but one that was also discoverable and accessible to everyone via the mobile web.

Instead of minimally updating their underlying site, Lancôme looked to PWA technologies to provide an immersive, app-like experience. They took advantage of service workers to deliver reliable performance on unstable networks and push notifications for re-engagement. Their best-in-class PWA achieves a performance score of 94/100 on Lighthouse, an automated tool for improving web page quality.

With the new PWA, the time until the page is interactive fell by 84%, compared to their previous mobile experience.  Lancôme saw their mobile sessions rise by more than 50%, and conversions increase by 17%. Full details can be read at:



The Unvired view is that enterprises do not need to necessarily choose between native apps and PWAs. Companies like Twitter, Lancome, and Ola Cabs (a leading cab service in India) have both native apps and PWAs. It really depends on the business strategy, target customers/markets, and the prevailing bandwidth/mobile devices environment.  There are various possible Scenarios:

  1. Existing Web and Native Apps Presence: You have several options. If you already have developed native apps, you should continue to enhance their User Experience if the native experience is very important for you.   At the same time, you may want to move your website to a PWA to enhance performance.
  2. Existing Web Presence Only: This may imply that native apps are not critical for you. Evaluate moving to PWA and get the best of the mobile web and native apps.
  3. Poorly Performing Website on Mobile: Evaluate moving to PWA and get the best of the mobile web and native apps.
  4. Existing Native Apps Presence Only: Enhance Native Apps if the native functionality is critical. Else, evaluate moving to PWA.
  5. No App Presence at all (for example a New Company/Product): Evaluate PWA as a first option while recognizing that PWA is limited on iOS currently (No offline, No Push Notifications). Instead of Web + Native (iOS) +Native (Android) +Native (Windows 10), you can build only for Web + iOS.

I would love to hear your views on this topic—have you implemented PWAs as yet? Pl. comment below or write to us at sales@unvired.com to share your thoughts.


Developing apps and other integrations with the UMP REST API

Blog Technology Viewpoint

The Unvired Mobile Platform offers a rich set of REST APIs to build custom integrations easily.  The REST APIs are broadly classified into APIs that deal with:

  • Sessions – Handles persistent login sessions
  • Users – Work with Unvired users (Create, Update, List, Lock etc)
  • Groups – Work with groups of users (Create, Update, List etc)
  • Applications and Libraries – Work with Unvired applications and libraries (Execute functions, Deploy, Undeploy, Configure Properties and Settings etc)
  • Messages and Attachments – Queue messages, attachments, retrieve them etc.

Other APIs include:

  • Companies – Work with Unvired Companies (Departments) (Create, Update, Activate plans, List etc)
  • Status – Get technical status information on the platform for monitoring etc.

Some use cases can be to create a user in the UMP when a user is provisioned in MS Active Directory, or write command line tools that create users/groups based on other Identity Management systems like ADS, LDAP etc, deploy (make available) applications to users belonging to specified ADS groups etc.  The APIs can also be used to for e.g. execute functionality in an enterprise system like a ticketing system from a web site wherein the user can request support.

The APIs are documented in detail and the documentation is made available as Swagger definitions for import into API testing tools, code generation etc.  Additionally if you are a Postman fan (http://getpostman.com) you can directly import the UMP Postman collection to work with the APIs and test/develop.

The detailed documentation can be accessed at the Unvired Developer Portal (http://developer.unvired.com)

Enjoy developing smart integrations.  Let us know what you build here and receive a memento from Unvired 🙂

Unvired for Health Care Applications

Blog Lessons Learnt Mobile Use Case Technology
healthcareMobile access to patient data or Protected Health Information (PHI) is of paramount importance.  While the backend is already digitized using EMR (Electronic Medical Record) systems, the last mile is mostly manual using pen and paper or other offline means of data management.  Modern health care requires that the care team has immediate access to the patient information.
PHI is part of the HIPAA Privacy rule and protects most “individually identifiable health information” held or transmitted by a covered entity or its business associate, in any form or medium, whether electronic, on paper, or oral.  This requires that mobile and web applications enabling this access are ultra secure and handle the information accordingly.
Unvired recently implemented a Patient Information System on mobile with a backend database to store the PHI data securely.  The key aspects were:
Mobile Application
1.  Data at rest is encrypted on the iOS devices.  Additional data protection is enabled with security mechanisms such as password/PIN to prevent unauthorised access.
2.  Data in transit is transmitted via secure HTTPS/SSL.
3.  Data stored in the backend database is encrypted at rest.  Connections to the database are protected via encrypted SSL connections.
4.  The web application allows online access and all data is invalidated/cleared on session termination.
The Landscape
The Unvired Mobile Platform (UMP) enabled this offline/online access to the patient information from both Mobile devices and web browser.  While UMP satisfies the security and encryption requirements of HIPAA, Unvired partnered with Aptible (http://aptible.com) to additionally enable a secure environment in the AWS cloud.  Aptible provides a platform on AWS to securely deploy applications and satisfy the regulatory requirements.  UMP was deployed in Docker containers on the Aptible landscape to enable this secure access.  All the dockcer containers are isolated in an Amazon VPC with restricted access.  Additional logs and audit trails in Aptible ensure that every access to the landscape is recorded.  All data transmitted and received via the platform is logged and audited by the UMP.  Once data is safely delivered to the device, the data is cleared on the UMP and no PHI information is cached.
The combination of the secure UMP platform with the Aptible landscape provides a secure and cost effective platform for customers to deploy mobile and web applications to handle PHI in a secure and compliant manner.  Over the next few weeks there will be a series of follow up blogs delving into more detail on each of the above aspects, do join us for the journey.
Contact us to know more about how Unvired can enable a robust health care solution for your institution.

3 Ideas for Designing for Chatbots

Blog Bots Viewpoint

Chatbots are the rage, but we are in the early days.  We are still not sure about how best to design for bots.  Yes, while conversational interfaces have promise to redefine the User Experience, the challenge facing us is to identify the right Use Cases, and the appropriate design.  After reviewing the nascent literature on this, talking to customer end users, and based on our own experience of building chatbots for enterprise systems, here are 3 ideas for Designing for Chatbots:

  1. Minimize Input: The user experience should be the priority.  Expecting users to enter free text has the potential for failure.  Instead, it may be best to have users give structured input.  For example, our developers at Unvired have designed a Command Infrastructure that eliminates lengthy free text input.  For example, Users can select Approve or Reject a Purchase Order in SAP or View Sales order from Oracle EBS with a Get Order Details simple chat command.
  2. Hybrid Approach: In some cases, the user may want to talk to a human at some point in the conversation with the bot. Good design should enable a human to jump in at any time.  Say, for example, you are ordering flowers on Facebook Messenger using a chatbot, but are frustrated because you cannot find what you are looking for.  There should be a way out to reach out to a human.
  3. Simple: The design for chatbots should be simple. One of the advantages of bots is that the need for say, a 3 screen application is eliminated.  There is no GUI.  Bots interactions should be kept simple and short—the user should give minimal input, and receive the output.

Let me know if you have other ideas for designing for bots.  These are early days, and we can all learn from each other.

This blog was first posted on LinkedIn.

Chatbots for SAP: Talk to SAP and Disrupt the User Interface

Blog Bots Mobile Use Case

Lately, there has been a lot of buzz around bots.  Bots are the lightweight programs that will make our work easier, and help us escape the multitude of apps that users have to navigate.  Bots have a simple text interface that eliminates the need for a Graphical User Interface (GUI).  Bots talk to systems, applications, and things- hence the term chatbots.   Much has already been written about bots, machine learning, AI, Natural Language Processing, and so this blog discusses a very specific sub-topic: Chatbots for SAP.

Interfaces with SAP come in many forms—the SAP GUI, Personas, and SAP Fiori among others. That is till now-enter the conversational interface.  At Unvired, we have developed chatbots for SAP to enable various Use Cases:

1.SAP ERP-Workflow: How about SAP messaging you an alert that a Purchase Order needs to be approved?  You look at the details, and approve.  Your text “Approve” gets the PO approved in SAP.

2.SAP ERP-Sales: The Sales leader needs to report to the CEO the latest sales figures. A quick text to SAP, and the answer comes right back. How about looking at a sales chart—that can be viewed too.

There are so many chatbots for SAP that would be a must have—for SAP ERP, S/4 HANA, SAP CRM, Cloud for Customer (C4C), SuccessFactors, and others.  Customers in industries including Manufacturing, Chemicals, Financial Services, and Real Estate have indicated interest in exploring Use Cases for chatbots.

Chatbots for SAP enable receiving alerts from SAP, taking actions/decisions on those alerts, and  searching/querying all with the intent to streamline workflow, and make work easier.

If you are an SAP customer or SAP partner, and want to collaborate with Unvired to build chatbots for SAP, please send me an Inmail or email me or comment on this post.  We would love to jointly define some Use Cases for chatbots.  These are exciting times indeed.  As always, looking forward to others sharing their experience with and thoughts on bots.

Four Themes from the Best Practices for Chemicals (SAP) Conference

Blog Mobile Use Case Viewpoint

Earlier this week, I attended the Best Practices for Chemicals (SAP) Conference hosted by The Eventful Group in Houston.  It was a great conference attended by several CIOs including from Huntsman, Nova Chemicals, PLZ Aeroscience, and Americas Styrenics among others.  There were many great presentations.  Here are the top themes:

1.Digital: Chemical companies are embracing digital.  Mobile applications, Internet of Things (IoT), Predictive Analytics, and the Cloud is being adopted by this industry.  Agricultural chemical companies are combining sensor data, soil data and weather information to increase crop yield. HANA is beginning to be adopted as a database and SAP S/4 HANA is also making headway as the digital core. Customers, Suppliers, Employees, and Assets are the four pillars of Digitization.

2.Outcome based: Chemical companies are also innovating and defining new business models. For example, instead of selling compressors, they are selling “Compressed Air” as a service. It is all about Outcome based models.

3.Cyber-security: Chemical companies are very concerned about being hacked.  Given the nature of the products they make, a cyber attack can be very dangerous.   There are regular meetings held where Chemical companies discuss how best to implement cyber security.

4.Global Compliance: Chemical companies have to ensure that their products comply with various regulations. Also, they have to register each product in the country where they plan to sell. Regulations change frequently, and it is critical to stay on top.

This blog first appeared on LinkedIn