How to build an application integration framework for flexibility
Learn how MOBI Wireless created a back end infrastructure that makes it easy to implement different business workflows across service providers.
Enterprise developers are often tasked with building complex applications spanning multiple services. This can lead to integration challenges, and can make it difficult to customize the application for different customers. MOBI Wireless Management has tackled this challenge with a thoughtful approach that simplifies the implementation of business rules for processes that span multiple services.
Eric Sendelbach, Chief Technology Officer, MOBI Wireless Management LLC, said "Our Ruby on rails framework is good at abstracting away the plumbing to get web applications running. This allows us to come up with create ways to incorporate business rules for customers."
MOBI Wireless creates a mobility management solution for enterprises that provides a single interface for managing all of the interactions related to smart phones. The applications allows an enterprise to automatically order and set up new phones for new employees, manage billing, and decommission and erase phones when an employee leaves. This application infrastructure needs to work smoothly with multiple carriers, billing providers, CRM systems, and mobile device management services.
Create core rule sets
One good practice lies in customizing the core application using configurable rule sets, rather than customizing for each customer, said Sendelbach. MOBI has developed an internally developed business rule library that allows the business to generate nested condition sets. These rules can be attached to lots of different data models in its back end systems. There is also an automation rules engine that allows MOBI to tie these processes together. For example, the latest iPhone that might only be available to employees in departments with certain eligibility.
About 45 predetermined workflows relating to typical business processes have been implemented in the core platform. The existing engine allows them to address specific needs of the customer and is not bound by the limitations of external tools. Sendelbach is looking at bringing in BPMN 2.0, which will allow customers to create their own workflows through visual flow charts. MOBI would then provide automated processes that could be dropped in as components of a business user's process.
Sendelbach said, "We have looked at tools like ProcessMaker and Bonitasoft and they are doing cool things, but they are trying to solve all of the business process scenarios you could imagine. We are digging more at the core concept of BPMN that allows a standard way to organize process."
Configure rather than customize
Another way that MOBI has made the software platform more flexible is to think about organizing capabilities using configurations that can be toggled in the application. Sendelbach said "We don't just implement the request, we take a step back to see if there is a configuration we can turn on or off. Over the course of 8 years we have ended up with a wealth of configuration options."
MOBI has a team of engineers that work with new customers to tease out their requirements during the presale process. There is also a team of solutions engineers that take these specifications and translate them into configurations. Sendelbach said, "If we are missing a setting, we will engage the development team. I like to think of development building the Lego pieces, and then they get assembled through the configurations. This reduces the testing requirements, and also gives us some control in terms of governance and risk management."
This approach also helps to mitigate concerns relating to the governance and risk management requirements of MOBI customers. There is considerable personal information embedded in the call detail records which are moved through the MOBI application infrastructure. As a result, MOBI needs to ensure that it is managing this data in a way that is consistent with the general practices of the company. Sendelbach said, "A lot of the way we mitigate that is by controlling changes via configurations. It is up to our individual customer representatives to educate customers on what is available and the implications of that in regards to GRC."
We are digging more at the core concept of BPMN that allows a standard way to organize process.Eric Sendelbach, CTO, MOBI Wireless
Create a common abstraction tier across integrations
Another challenge is that carriers have different APIs for provisioning and setting up the billing for new phones. In addition, different mobile device management providers have slight different abstractions for erasing and locking phones when required. To address this challenge, MOBI built a backend integration tier that provides a common interface for workflows across different providers.
In the beginning, the MOBI development team built separate integrations for the cell phone providers and cloud services. But this grew to be unmanageable. So the MOBI development team created an internal library that serves as an adaptor layer for external services. This library captures traffic coming in through exposed endpoints for 3rd party initiated JSON and XML calls. Sendelbach expects they will adopt an enterprise service bus architecture once they have to manage over 100 integrations.
Inside of these main integrations, there are sub integrations supporting the carrier billing systems like Verizon, AT&T, and Sprint. Other integrations work with various mobile data management services like AirWatch and MobileIron to automate the erasure of data and deactivation of phones that have been lost or stolen. The backend library allows the MOBI framework to lock a device, without having to know what specific software framework or carrier that specific phone uses.
Simplifying new processes
The next evolution for integrations is to let third parties write applications that work on top of the MOBI platform. The set of integrations they have develop would allow 3rd party recycling vendors to write the workflow around disposing of deactivated phones.
When someone gets a new iPhone, a manager might want to see the total cost of that transaction, which could drop considerably by with rebates from turning in old phones. MOBI will facilitate this process or could help an enterprise maintain a cold stock of devices for redeployment when a phone is lost or broken. In some cases, this kind of process might actually reduce phone breakage. Sendelbach said, "A lot of people seem to drop their old phone in the toilet when the new iPhone comes out."
How do you overcome the integration challenges you encounter? Let us know.