No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

UC Architecture Strategy #5--Services Model

As IT continues to evolve, business organizations continue to press IT to not only be faster, better, and cheaper, but to be easier to work with. Toward this end, cloud computing is taking off, in part, because IT is being broken down into a set of services that can be integrated together to create a solution. Whether it is a public, private, or hybrid offering, the end objective is to break the IT into a bunch of standard services that are integrated with information, processes, and people, to deliver a unified solution for a business organization.

A service model can be broken down into 6 categories:

1) Service Owner--An individual and/or team that is accountable for a specific service
2) Service--An IT function that provides specific functionality
3) Service Catalog--A list of all services that IT provides including:
a. Definition--What the service offers
b. Tiers--It is critical to offer two to four levels of service: A basic service that is very cost effective and has a best effort support model, to a premium service with full functionality, high availability and support. This gives business users the choice on service quality versus cost.
c. SLAs--The availability, performance, delivery, and other metrics around the service
d. Chargeback--Units of charge, major cost drivers, and standard monthly rates. Private cloud solutions need to cover the upfront cost to build the service and spread cost out over 3 years.
e. Information--A URL for more information along with a name and number of the service owner for more detailed information.
4) Relationship Manager--A broker between the service provider and business customer.
5) Service Level Agreements--Every service should be a contract with written definitions of SLAs, how they are measured, and penalties. IT should have OLAs (operational level agreements) with their partners.
6) Charge Backs--Billing based on usage and/or per user to cover implementation and support costs.

Figure 1. IT Services Model

In IT infrastructure, services are categorized into a stack of major service areas, with each area having its suite of services. Building a portal or back-end business application such as ERP or SCM uses a fairly standard stack of IT infrastructure services that are well defined, as shown on the left side in Figure 2. These services focus on machine-to-machine communication. On the right side is the stack of communication services. Communication services are defined as the services required for person-to-person or person-to-machine communication. The application layer is used as the bridge between users on devices accessing backend system information.

Figure 2. IT Infrastructure Service Categories

The next step is to break down each of the service categories into each of the sub-services. While this concept sounds easy, in practice it is very difficult because there is some overlap. Most IT infrastructure groups also align their organizational model in each service area, and there can be some organizational conflict around who should own what.

As a side note, a lot of vendor decisions in the communication space are made by which group owns a given service. For example, if voice mail is owned by the Telecommunications team, the solution is most likely to be from a traditional telecommunications supplier like Cisco or Avaya. If voice messaging is owned by the collaboration team, then it is most likely a traditional email messaging vendor such as Microsoft or IBM. The same holds true for Session Border Controllers. Are they owned by the Network, Telecom, or Security team?

The focus of this strategy is on UC solutions, composed of Telecommunication, Session Management, Interaction, and Collaboration services. Each of these service categories will be broken into all the suite of sub-services that comprise them.

Telecommunication services focus on real-time communication between 2 or more people. Real-time communication has its own set of unique network and device requirements.

Figure 3. Telecommunication Services

Session Management Services are tied to enabling multi-channel/modal communication between communication devices and all the rules and addressing for communication to be established. These services are still maturing as most communication protocols start using SIP for communication establishment. One big opportunity for the industry is to have presence services tightly integrate with the other session management services. SIP proxy servers play a large role in providing Session Management Services.

Figure 4. Session Management Services

Interaction Services are those services used for people who do not know each other but need to communicate. These services are usually associated with Contact Centers. Contact centers are evolving to interaction centers that span communication across multiple channels and contacts over time.

Figure 5. Interaction Services

Collaboration Services are between two or more people who know each other and are working towards a common objective. Collaboration is either planned through a scheduled meeting, or it can be ad hoc due to an event that triggers the need to collaborate, such as an outage.

Figure 6. Collaboration Services

Every service should have a detailed description so that business consumers of the service understand what is included, how to consume them, and the associated cost of a service. Yes, as hard as IT may try, customization will need to occur. Having a standard service, though, is a good place to start. Public versus private services need an apples to apples comparison. Figure 7 is an example of a service catalog description of an IVR service.

Figure 7. IVR Services Example

A business communication solution takes a suite of communication services and integrates them to create a custom business application. One thing that makes UC difficult for most IT organizations to handle, is that UC is a combination of both infrastructure and applications. Most large IT organizations are broken up into a shared IT infrastructure/utility with specific application groups that support each of the major lines of business. The business has a requirement, it goes to the application group to build a solution, and in turn the application groups utilize the IT infrastructure as required, with the help of IT architects. Since UC is a combination of both infrastructure and applications, in a lot of cases, UC works directly with the business just like the application support groups.

In order to make a Service a success, a bunch of service management processes must be defined and maintained for each service to guarantee high availability, quick delivery, and optimal costs.

Figure 8. Service Management

Everyone says that IT should be managed like a business, but the actual effort to do this is significant in size. If the decision is made to use a Services Model, then IT can meet the ever-changing demands of the business in a timely and cost effective manner.

Footnote: This is part of a series on UC Architecture that I do.
1) Defining UC Architecture--What is it and how does it fit into other architectural frameworks?
2) Centralization--Moving all UC into the data center/cloud with SIP trunking
3) Consolidation--Reducing and tightly integrating all UC platforms using SIP
4) Integration--Integrating all channels of communication: Web, email, phone, ...
5) Services Model--Adopting a services model to describe and deliver UC services
6) Operational Excellence--Design, process, tools, and skill set to deliver a 99.999% available solution
7) Measuring UC Success--Defining and measuring UC success factors. It is not just about technology.
8) Future UC Game Changers--4G cellular, increase in number of end points, TV integration,...