At Avaya: ACE is the Place for RC
Aspirationally, Avaya’s Agile Communications Environment (ACE) is the essence of Recombinant Communications (RC) packaged as enterprise software. As described by product marketing director Sajeel Hussain, ACE came into existence where “UC typically breaks down,” referring to the “siloed”, multivendor IT and communications environments where “nothing works together.” It ships as shrink-wrapped software designed to abstract the underlying communications layer and present it as simple Web services which developers can integrate into their own solutions using their choice of RESTful programming environments.
In other words, Web developers can build communications-enabled apps “without knowing anything about communications.” Genius!
As characterized by Hussain, ACE is the product of marketing “pull” that crosses several functional areas in an enterprise. Demand starts at the functional level, where platform incompatibilities may have thwarted a departmental head’s efforts to reap the benefits promised by providers of “unified communications.” ACE comes to the rescue with shrink-wrapped “connectors” for Cisco, Avaya (including the vestiges of the Nortel CMS line), Tandberg (video endpoints), IBM SameTime, and Microsoft OCS. Thus Avaya makes it possible to overcome incompatibilities with a single DVD that runs on a couple of servers and carries a list price of $10,000-$12,000 for the core license plus per user fees of $50-$100.
As for common use cases, Hussain provided profiles of implementations at a number of global businesses. For example a multi-branch global bank provided a form of “follow-me” connectivity by providing “hot desks” for itinerant executives. The service integrates a voice network that includes IP-PBXs from both Avaya and Cisco with presence management and call origination based on IBM Sametime. In other instances, the ACE SDK was used to “communications enable” business processes and workflows with APIs to CRM and knowledge management systems to support better medical care or customer care in financial services.
Architecturally, ACE resides “on top of” Aura, Avaya’s branded middleware SIP-based communications. Hussain explained that Avaya’s product offering has changed so that ACE will emerge as the application development environment for Aura as well as multivendor environments, and that the “lower layer toolkit (back into Aura Session Manager) will be ACE.”
Hussain, who is a veteran of the “Nortel side of Avaya”, was especially pleased that ACE is now a part of Avaya’s DevConnect program, referring to Avaya’s community of 3rd party developers, acknowledging that this sort of program was “missing at Nortel.”
Avaya is on the right track with ACE. It is putting tools into the hands of the people that are driving enterprise-wide innovation and making sure that key elements of Avaya’s existing fabric for call-handling, voice processing and multi-media interactions remains entrenched in multi-vendor solutions. The short list of supported vendors – IBM, Microsoft, Cisco/Tandberg – is not as “open” as might be ideal, but it does represent a high percentage of Avaya’s current market space.
I don’t mind using technology-oriented descriptors temporarily for the “How” of new technologies, but I think we should start using descriptors that are more meaningful to end users in a business organization. This would be a label that describes the “what” and the “why” of the business process applications
So, please let’s drop the “RC” perspective and move on to what “UC” is supposed to provide to individual end users, as well as to business process. That way, IT can communicate more easily about communication requirements of users rather than just how to implement infrastructures.
Hi Art:
Thanks for your comment. I’m glad you brought up the whole terminology issue because there is no question in my mind that RC is here to stay. But dropping the RC mantel to move backwards into the UC realm is not attractive to me.
RC is a concept that is getting a lot of traction among application developers, system integrators and general implementer/”doers” that make up the Web 2.0 and Enterprise 2.0 crowd (as opposed to the centralized planners and keepers of the locked down world of IT and the data center). For me RC *is* about the end-user experience. Using the iPhone as an example, you can see where AT&T wireless subscribers have assembled their own solutions by combining what Apple provided with the elements that they shopped for in the iTunes store and combined them “on the glass”.
I think you and I can agree that the objective of technology is to solve real problems and create a better user experience. In my experience, this is seldom the result of a “unification”; Instead, it is about the creative reassembly of existing resources, combined with the best of what the Web has to offer. That’s why I don’t see a continuum whereby we might move beyond RC to achieve UC.
As for enhancing IT’s ability to communicate about the communications requirements of end-users, I strongly believe that we’re seeing entirely new forms of dialogue taking shape between companies, their employees and their customers. As a result the end-users define when, where and how they want to carry on these new types of conversations, they are already way past what UC solutions providers are proposing.
Thanks to “agile” solutions that use drag-and-drop, pull-down menus and Visio-like graphics, the gap between end-users and IT support is narrowing. End-users are doing a pretty good job of articulating their needs on-the-fly (I’ve heard the expression that “real-time isn’t fast enough”, but that’s a whole nother discussion). As I note above, I was most impressed by Sajeel’s comment that solutions are coming from ‘Web developers can build communications-enabled apps “without knowing anything about communications’.” That’s pretty cool, and the next step is to have end-users building their own IT solutions “without knowing anything about IT”.
Hi Dan, Hi Art,
Firstly can I say that these moves by Avaya are totally coherent, farsighted, and re-assuring for Avaya investors and customers alike. It clearly signals that there is value in empowerment, in combination, and in recombination, hell, there’s even value in allowing customer to RC with non-Avaya solutions. So far, so super.
When the “top 3″ get all inter-operable with each other it means we may be moving to another competitive arena? What does it remind me of? Well, Instant Messaging. When Google Talk came out and was all fancy and shiny, MSFT and Yahoo signed an interoperability agreement. Why? To keep their Network Effects (in a web sense). Is there a similar theme here (seriously, just asking).
As for Developers, and the battle for developers. Please. Game Over. Voxeo. Next.
So is the battle for IT Departments and Comm’s Managers? If you look at the adoption of Mashup Technologies they have actually mostly found an audience with IT staff looking for better integration methodologies, better tools, iterative. So is Avaya well positioned for these people? Very much.
Thanks for the comment Paul.
Indeed! “Mashup or Catch-up” is the mandate for IT and Comms managers, alike. Although, as Art points out, when it comes to articulating what’s going on to the corporate folks who write the checks, they need a coherent story that shows how they leverage existing stuff while embracing new trends – including collaboration, mobility and multimodality… and more often than not, it’s a multi-vendor solution. Hence RC!