We’re really starting to see some cool things coming from Avaya’s Engagement Development Platform (EDP). You may remember that this is the new name for what used to be called Collaboration Environment (CE). For those who don’t know or are still a little bit hazy about EDP (or even CE), it is Avaya’s newer platform that developers can use to gain access to the cool capabilities of Avaya Aura through API’s (Application Programming Interfaces) and SDK’s (Software Development Kits).
For those who have been around a while, you may be very aware of Avaya’s AES server (Application Enablement Services), which is also a platform that exposes capabilities of Avaya Aura through API’s and SDK’s. You see AES servers a lot in Call Center applications. So, while they both expose the coolness of Avaya’s feature set, there’s some huge differences between AES and EDP. In fact, you really shouldn’t think of one being better than the other. Definitely don’t think of one replacing the other (not yet anyway). Let’s talk about this a little more and give you some ideas and dive a little deeper into EDP.
First, to better understand EDP, let’s level set our knowledge of AES. It’s important to know that AES is limited to, exposing the coolness of only Communication Manager (no other vendors, and no other Avaya products). It uses a proprietary link to Communication Manager and turns that access into fairly standard APIs. Some very common APIs that are available with AES Servers are TSAPI (Telephony Server Application Programming Interface) and JTAPI (Java Telephony Application Programming Interface). Both of these are control protocols (meaning they don’t send actual voice/video data). These are used a lot for Computer Telephony Integration (i.e. CTI) and are generally written in C and C++ (or Java, as is the case with JTAPI) programming languages. We see this a lot with Call Recording, Call Reporting, and Screen Pop applications. JTAPI is very similar to TSAPI but is used a lot with Web integrations (to sites like Salesforce.com), due to its use of Java. There’s another API available with AES Servers called DMCC (Device, Media, Call Control). DMCC, available in Java, .NET, and even XML, is proprietary to Avaya but is used by a lot of the call recording partners. It gives very granular control over hard and soft endpoints and can handle both signaling and bearer path (i.e. voice).
EDP is very different from AES. First, its APIs are the more popular web-services type APIs. It is very much SIP based. It leverages Avaya IMS architecture and can get in the middle of SIP flows as Session Manager does its Application Sequencing with IMS-Originate and IMS-Terminate messages. Since it is really connected more to Session Manager, it can interact with a lot more than just Communication Manager. As these SIP messages go through EDP, EDP can interact with many different adjuncts through pre-defined connectors or “snap-ins.” The current version of EDP has several premade snap-ins a developer can leverage. Things as simple as email, chat, SMS, as well as more complex things like presence, Scopia voice/video conferencing, Communication Manager, WebRTC, Context Store, Real-time Speech Search, etc.
The best part is that developers can create their own snap-ins to expand the capabilities of EDP either as a proprietary plugin for their app, or something that they could sell to developers. These snap-ins are all about creating re-usable connectors to external things. For example, when Avaya saw what we were doing with PasswordPro, they suggested that we create a snap-in to EDP that would allow customers/developers to create workflows that could include the automatic creation and resetting of passwords for new employees.
It’s impressive to see where Avaya is going with this. It’s already pretty cool right out of the box, but the flexibility and open nature of it allow a very robust ecosystem to emerge. Even Avaya is using EDP for their own application development and feature enhancements. In Aura R7, APS (Avaya Presence Server) can go away, because it is simply being re-created in EDP. In EDP, it will have a MUCH better interface to federating to other presence sources (such as Lync/SFB), and giving developers more flexibility to creating their own aggregation logic.
Avaya demonstrated a Call Park/Pickup app at this past IAUG that they were starting to beta test that is meant to emulate CS1000 Call Park functionality. I know some CS1000 users drooling over this capability. The point is that the same “developer kit” that Avaya product teams are using to introduce new capabilities, is the same one that 3rd party developers, such as Arrow Systems Integration can use.
So, when you come up with these weird, crazy off-the-wall ideas or feature requirements that could literally change the way you do business, if only it existed, and you just can’t find a vendor who has that capability, think about Avaya Aura and the Engagement Development Platform.
About the Author
Vice President, Strategy and TechnologyMore Content by David Lover
David Lover leads the strategy for our core Enterprise Communications portfolio. He focuses on products and solutions to address the customer needs of Unified Communications and Collaboration, Customer Experience, CEBP, and End-User Adoption.
David works closely with the product marketing and development teams of our top partners to understand their strategy, and while representing Arrow SI and their customers, collaborate with those teams to provide guidance and feedback to shape the future direction of those partners’ portfolios. He uses these relationships and set of product knowledge to work with Arrow Systems Integration teams to be in alignment with the total portfolio strategy. As a member of Arrow Systems Integrations executive leadership team, he works with every part of the business.