An Application Enablement Platform, a.k.a. AEP, in the context of this article is a software product with foundation level capabilities that are used by a team of developers to build a consumable software application.
An AEP does not come with an occupancy permit for consumable use. You have work to do to get to an operational application. What they offer is a significant head start.
The term AEP is relatively new, often referenced as a means for classifying a type of software platform that is targeting the IoT space. The hypothesis is that AEP’s make it easy to develop the end solution. “Easy” is debatable because it ultimately depends on the availability of skilled software developers and operations people with the motivation to make it work.
Before we get into whether or not they are right for you, let’s explore how AEP’s came to be. First, a refresher on Platforms.
We wrote about Software Platforms in the past and started by defining the term platform:
Platform: a platform provides low-level functionality ready-made as an accelerator [or enabler] to a consumable solution.
A platform is not a complete solution; It requires additional effort to complete the solution and make it consumable. The benefit of a platform is to provide commodity capabilities faster and cheaper while maintaining the ability to differentiate through customization.
A platform, as you may have guessed, is not limited to software. The origin most likely came from the automobile industry. Within an IoT solution stack, you will 
find many references to software platforms including hardware platforms, processor platforms, communication platforms, and data platforms. Another variation, an end-to-end platform, is one that targets a very specific vertical (i.e., a fleet tracking platform that includes a tracking device, data plan, and software specifically tailored for tracking a fleet of vehicles).
Therefore, given this wide range of platforms, the software industry, or perhaps software analysts, needed to differentiate what they were talking about so a name or category was born: AEP, Application Enabling Platform. Note that Google has yet to discover the term or at least prioritize it (try AEP in a Google search).
Why are there so many AEP’s targeting IoT?
For many software companies, big and small, IoT is the next big growth area and offering an AEP theoretically extends the possible markets they can enter while minimizing the variants they need to maintain. One platform can serve many markets. The customer can then bet on the specific end solution use case.
Here’s an example: instead of developing a software platform that targets fleet tracking, the software provider can create a more generic AEP that has location tracking capabilities. The AEP would be the foundation for tracking any object containing a location finding sensor and the ability to communicate its position back to the software platform. Their customer can then employ a team of software developers to finish it for their own unique requirements.
The benefit to the consumer of an AEP, typically another business, is that they can shorten their development timeline by starting with the AEP as a foundation while still maintaining their ability to differentiate through customization. The foundation is maintained by the AEP provider while the business consumer is responsible for the final build and operation.
The disadvantage or risk of an AEP is that the consumer must have the skills to complete the project and of course the solution is now locked into the terms of the AEP contract.
Is an AEP right for you?
Only you can decide on an answer to this question! Remember, an AEP is a starting point. A foundation from which you are to build your software application. As with any foundation, you will be required to train people on how to work with it, setup, maintain, and customize the AEP. An AEP is not plug and play. You will want to think about the resources and effort required to develop your application and maintain your application over time when evaluating an AEP.
There are a few common areas that will require customization. Examples include the user interface, device integration, data specific processing logic, and system integration.
User Interface
If the user interface capabilities of the AEP are basic, you will need to create integration API’s and create your own web or mobile interface. This level of customization is most often seen in consumer applications or white label applications that will be packaged and resold. Less prevalent for internally used applications where the UI is less important.
Device Integration
You will need to understand the capabilities or limitations that the AEP has with device integration. Are you limited to just one internet protocol or will it support many? Does it offer a database capability that is compatible with your device data model? Will it scale to support device and data growth? Will your device be expected to ensure that a connection was made and verify that data sent were received? Some AEPs require you to install a software agent on the device to manage connectivity. Will your device support this? Will you have the ability to perform mass installs of this agent if your device count extends to 1000’s or 100’s of 1000’s? Will you be able to update this agent or the device over the air without the need to physically connect to the device? Now, with all of the above in mind, can you accommodate a diverse inventory of devices, with unique communication protocols, data models, and sensor capabilities? Or, if device diversity is not important, will you be able to accommodate the next generation version of your device?
Data Processing
You will need to understand the processing capabilities of the AEP and the mechanism for adding priority as well as custom logic. When a device sends a data signal, can you prioritize it for a real time alert? How do you apply logic so that the AEP knows what to do with the signal (i.e., send SMS, send alert to dashboard, etc.)? Do you have the flexibility to apply any type of logic or are you limited to if-then statements? Can you mash device data with other data sources (see System Integration) and apply logic to the combined data set?
System Integration
Do you have a requirement to pull data in from 3rd party enterprise systems like CRM or ERP? Or will you be required to push data to these systems? What level of development is needed to ensure that this connection is properly developed and maintained?
Operations
Most modern AEPs are accessible as a hosted service that includes upgrades and support from an operations team. However, most will not support the custom work that you apply to the platform. You will need to determine how you will support the development and operations functions and the level of sophistication needed to meet the expectation of your customers (users of your solution).
Acquisition cost
AEPs are generally available as a monthly or annual subscription. For IoT solutions, the pricing typically varies by volume of data and connected devices. If you do not have the means to hire and retain developers, you may be required to outsource development to complete your application. If that is the case, you will also need to consider the need to retain the outsource firm for future development, upgrades, and support.
Alternatives to an AEP
What if an AEP is not right for you? It is not your only option. You have two, and in some cases three alternatives.
- Find an off-the-shelf application that matches your specification (this may not exist).
- Find an outsource partner that will build and maintain your application.
- Internally develop a custom application (do-it-yourself).
Finding an off-the-shelf application can be the most economical and is probably 
the best approach if your application is a commodity with no need to be differentiated from a competitor. Applications for internal, operationally focused used cases come to mind.
Bridgera is an example of an outsource partner that builds custom applications to customer specification. With their Bridgera IoT platform, they bring the advantages of an AEP but provide all the customization and support as a service. There is never a need to do any of it yourself, ever! Most important when working with an outsource partner is to ensure that you have a maintenance and support solution for the life of the product.
If you do it yourself. Developing a custom software application or developing an application by leveraging an AEP both require your company to be committed to becoming a software company. This means you will need to develop software competencies in the form of skilled people. You will need to establish development and operations best practices and mechanisms for recruiting, training, and retaining developers, QA, and support personnel. You will also need a management team that understands software development and is able to differentiate the skilled people from the not-so-skilled people. All developers are not created equal!
The most important thing to remember is that if you are not comfortable with the responsibility of becoming a software company, don’t. Look for an off-the-shelf solution or find a partner who can develop and maintain the solution for you, per your exact specification without the need to compromise.
