Architecture Planning is Key for Enterprise UC

It is very important to have a solid architectural design to guide your UC implementations. Of course, UC should start with a high-level UC Strategy, based on our UC definition of "communications integrated to optimize business processes." That strategy will outline the sequence of UC investments and application roll-outs, whether those are for User Productivity (UC-U) or are for Business Process improvements (UC-B), as described in the UC Resources section of our site.

On Monday, June 28, my peers at UCStrategies.com and I had a discussion of this topic, which will soon appear as a podcast in the Industry Buzz section of the site. The most significant point made by the team was that UC Architecture must be considered in the context of the overall Enterprise Architecture -- a very important point. Many of the architectural elements described in this article already exists within the enterprise architecture (directories, business applications, middleware, and more). UC should use the existing resource were appropriate or, at least, easily integrate to those existing, often mission critical elements.

With that UC strategy in place, you will be able to design the guiding architecture. The benefits of this architectural design are many. The top several are:

• Avoid duplication of competing technology elements. The examples are numerous, including the master directory role, the presence engine plan, the user experience model, the business application integration model, the middleware level, the database model, the administration model, and the maintenance model. Duplication in any of these elements can lead to fragmentation of the overall solution.
• Deliver the best user experiences for the best business results. A well-designed architecture will enable seamless user experiences. Users will find exactly the right tools for the job at any point in their work and in the relevant business processes. Moving from one task or process to another will have the same look, feel and functionality. A fragmented architecture will either prevent that seamless experience, resulting in confusing interface changes, or will require significantly more development and support cost for the Telecom and IT team.
• Achieve the best time to return (time to market). An integral architecture will enable efficient development and testing. This reduces the time from concept to implementation, with the obvious benefits of lower cost and of earlier realization of the savings, revenue enhancements, or competitive differentiation.
• Realize the lowest Total Cost of Ownership (TCO). The lower costs come across the board, from lower acquisition costs, to lower infrastructure (servers, gateways, etc.) costs, to lower training and staffing costs (DBA positions, Help Desk positions, etc.), to lower development costs, and to lower, non-duplicated maintenance costs.

So, the reasons for UC architectural planning are compelling. What are those architectural elements you should include in your plan?

While the best architecture will vary between industries and between enterprises within an industry, the elements are fairly consistent. In our UniComm Consulting engagements, we work with the following elements, reflecting both our professional experience and the clients' environments. For this article, they are listed from the user interface inward. An illustration follows the text of this article.

1. User Interface Elements: This comprises the models and the software to support the user experiences. Selections include a downloaded client vs. a web-browser-type client vs. links from existing clients (such as a CRM or ERP package). Also, options exist for native (such as a BlackBerry or an iPhone-specific interface) vs. generic interfaces (i.e. using the web browser on a the BlackBerry or iPhone). It may be required to have an Application Program Interface (API) directly to the user interface layer, so as to manipulate the functions, features, look or feel of the interface; such APIs are not always provided in off-the shelf UC clients, mostly due to vendor concerns for support issues.
2. Directory and Identity Elements and Policies: These elements are often seen as the nucleus of UC applications. The directory and identity elements, including the Presence engine(s), are the central repository of the user profiles and other characteristics. Applications should post to, or at least synchronize with, the central directory and presence engine. All user authorizations and policies should flow from a centralized identity engine. The goal is to remove the chance of multiple, varying instances of an employee (i.e. depending on how the administrator of each individual module or application types in a name.) A master source for authentication and permissions is critical to an effective security policy.
3. Middleware and Workflow Platforms and Tools: This layer is one of the most often duplicated or fragmented, even within a single vendor's branded product. The objective is that UC applications, user experiences and process flows are created in a consistent, easy to use, auditable layer. Each communication service (call, hold, transfer, conference, IM, e-mail, desk sharing, video, device controls, recording, logging, monitoring, documenting, etc.) should be consistent, even if the services are being delivered by many different elements. These are core concepts of architectural models such as Service Oriented Architectures (SOA), Web Services Description Language (WSDL), and Internet Multimedia Subsystem (IMS), among others. This layer is often abused by "add-on" modules that are actually their own "add-on" architectural models. The value of consistency in this layer is obvious.
4. Database elements: Of course, UC Applications link to databases to "optimize business processes." This can be in the UC-U modality, such as linking to directories and personal contact lists when launching or managing a communications session. This can also be at the UC-B modality, such as linking to Customer Relationship Management data when integrating communications into the sales process (as with comm-enabling Salesforce.com sessions). Sometimes, there is a reason to have an intermediary database layer, such as for system performance or for process-specific purposes. However, those layer should be transient data that is reliably extracted from and updated to the appropriate master databases; this is important for business continuity and for auditability and compliance, as well as to avoid the errors that almost always occur with duplicate "masters."
5. Communications Engines: These, of course, are the elements that provide the "communications integrated" part of the UC definition. There are many well-qualified communications engines available in the market today. In some cases the core products that are evolving from IP PBX systems, e-mail servers, and directory servers are incorporating excellent UC communications modules. In other cases, the traditional products are not evolving and it is necessary to either add-on other communication engine elements to supplement the traditional products, or even to deploy all the new UC applications on new UC-designed platforms.
6. Business Applications and BPM Engines Elements: Most business processes are now embodied in software-based business applications and business process management (BPM) engines. Therefore, communications events must interoperate with the applications and the applications and BPMs must be able to invoke communications services. Often, the communications functions must be presented through the User Interfaces of the applications (1 above).
7. Communications End-points: While communication end-points can have a major influence on the User Experience, they are positioned adjacent to the Network layer due to the end-points' physical device and transport functionality. Communication end points have become much more diverse in the past 10 years, ranging from IP Telephones, to SIP phones, to Personal Computers (PCs) and PC tablets, to video systems, to smart phones, to cell phones, to Bluetooth headsets. The end is not yet in site, for sure. The architectural issues include suitability for the purpose, security, reliability, manageability, transport connections, etc. A key factor is the openness of the device as well as the networks on which they operate.
8. Network Functionality: For most UC applications, the network will be based on packet-based services (LAN, WAN, public Internet, IP VPN tunnels over the Internet, MPLS or Ethernet services), using the broad range of Internet Protocols. Even here architectural decisions are required such as whether to employ proven but complex H.323 or newer but simpler SIP trunk services; or whether to use signaling protocols over WAN services (like MPLS - Multi-protocol Label Switching) or to use the public internet for communication between sites. If mobility is part of your UC applications, then the WiFI and Cellular networks (both data and voice) will be included. Further, we are a long way from migrating off the PSTN, so consider the scenarios when these services will be essential, and how they will interconnect with the rest of the network topology you have selected. The challenge is how best to optimize (there's that word again) the network topology for cost, performance, reliability, interoperability and security-and how to keep on top of these as upgrades and migrations occur. Gateways are, and will be, a crucial element of this architectural layer, to support both the coexistence of UC with legacy communications systems and the transition points between the various network protocols and transport types.¹

¹ With contributions from Lisa Pierce, Strategic Networks Group

Evaluating UC Architecture in layered elements simplifies the task by allowing incremental and progressive evaluation. Of course, decisions on one layer can affect selections in another layer, so a complete architectural design may require two or three iterations. Yet, those will not take a long time and, therefore, are worth the time and energy.

When the architecture is complete, it becomes the guide to vendor and product selection, to application development, and to operational management. On the vendor front, it is clear that no vendor, no matter how assertive their claims, is best in every architectural layer. Thus, the enterprise UC architecture will also provide a guide to the interoperability requirements, demonstrations, and support that are necessary for successful and economical UC application deployments.

Your comments to this article are welcome below or by e-mail. Do you think we should have a UCStrategies.com Forum on this topic? Please send an e-mail to [email protected] with comments and with any suggestions for improvement or clarification.