Open Communications

In my previous posts regarding the 7 Core principles of Open Communications I focused on areas that were specific to platform architecture.
In this post, I want to talk about how you can successfully design, integrate, and maintain your platform so that you are getting the most of your solution.
Wrapping services around your UC platform choice is of great importance to ensuring your implementation is successful. From simple implementation of the core platform to integrating with other line of business applications, its important to have a methodology that is able to be repeated. A successful project starts with up front consulting and provides you, the customer, with the framework of how to proceed with your project. Some of the services associated with a UC implementation are as follows:

Needs Assessment: This can encompass modeling current business practices. Looking at how your business communicates both internally and externally. Categorizing end user roles and responsibilities. Finally it determines the applicability of each UC service to your organization. Where should you begin and what should be introduced first to get the best results.

ROI and TCO assessment: Taking the information gathered from a Needs Assessment, this service will allow you to have a better understanding of the financial benefits to implementing your UC solution. It's critical to justify your business case and a useful exercise for any corporation.

UC Architectural Design: This really focuses on how the UC platform will be implemented and tied into the enterprise over a given period of time. It provides a target architecture so the customer can better understand where the end state will be and how they will get there.

Security, Telephony, and Network Assessments: These are all critical elements to a successful implementation. It is also a key risk management function since the main goal is to gain a more intricate understanding of the enterprise infrastructure as it stands today, as well as what modifications need to be made to support the target architecture.

Project Management: This service can't be overstated. A competent and experienced project manager will make or break a UC implementation. Project managers should have the right mix of certification and practical experience.

Multi Vendor Management: In the real world it's not possible to rip and replace an existing platform overnight. Investments need to be protected and a graceful migration will need to be put in place. Having a vendor that can provide this
service can give you confidence and help to manage a transformation in a controlled manner.

NOC services: How do you manage your environment on a day to day basis? Do you have the tools and expertise to manage the new environment accurately? The ability to outtask certain operational management functions can greatly alleviate overhead of managing your own network. This allows you to make better use of your personnel to work on more strategic revenue-producing projects while ensuring the health of your investment over its lifecycle.

Open Service Delivery should encompass all of the above to provide a cradle to grave capability for the customer. It can reduce risk, justify your investment, and safely maintain its operation over time. As part of any UC platform analysis, Open Service Delivery is a key consideration.  This is the last of the 7 core principles of Open Communications. If you follow all seven, I am confident your UC project will be a success and more importantly your company will enjoy the results of that success for years to come. Drop me a line and let me know your thoughts.
 

As UC enters into a more mature phase in the market, it might seem too late for a Taxonomy that describes all of the various acronyms, vendor positioning, deployment scenarios, and peripheral components that define the overall market. From the many customer meetings I have attended as well as analyst/consultant interactions, I still believe its probably useful to undertake the exercise. Part of what is holding up mass adoption of Unified Communications is that it encompasses a vast array of terminology and technologies that are daunting to many customers. Beyond defining UC, it would be incredibly helpful to give customers a navigation tool that would in effect spell it out in plain terms. In addition it would give customers an understanding of the different approaches taken by the vendors in the market. Finally, I believe it would be helpful to shine a light on how all of the moving parts kind of fit together to deliver an enterprise overall value. Let me know your thoughts. If enough of you say "Yes" I know what I will be working on this summer.

Today I am happy to have Matt Hartley from our Solutions Engineering Group provide a great guest blog on the topic of UC and Social Networking. Thanks Matt for this informative post.

Social networking has become an Internet phenomenon and it continues to grow.  Web sites like Facebook alone have well over 200 million active users, and of those users, close to 100 million of them log on each day.  Those are staggering numbers and no wonder this type of online community is an advertiser's dream.  As a matter of fact, today many sales professionals use online social networking as a direct way of selling their products and services.  So, from a sales and marketing perspective the customer reach is vast on
a social networking site like Facebook. It only makes sense to jump on the band wagon.  Also, many organizations are moving to online social networking as a way to bring their colleagues together.  If you go to LinkedIn, you'll see thousands of company profiles available to be searched.  It's almost like having access to a big corporate directory in the sky, or in technical terms, the cloud. 
And to be honest, that is exactly what it is.  As more and more people get online and join social networks, organizations really have no choice but to follow them.  And in the not so distant future, more and more organizations will adopt online social networking as a way for bringing people together to communicate, to collaborate and to share ideas.  Heck, if the people are already online sharing photos, there is no reason they couldn't spend some time working on productive tasks for their company or organization, especially if they are getting paid.

So, what does this mean for Unified Communications?  Well, in order for organizations to fully adopt social networking one day as a viable
meeting place for getting work done, a couple things have to happen.  One, organizations must feel comfortable with cloud computing.  And we all
know the hesitations there: reliability, availability, and security.  Two, cloud based business services would have to be provided by the social networking site so that work can get done. These cloud based business services, or "Virtual Company Services" as I like to call them, could range from access to CRM's like Salesfore.com, web conferencing tools like WebEx or access to an entire virutal computing environment like Amazon's Elastic Compute Cloud (EC2).  

In essence, the LinkedIn's and Facebook's of the world are well positioned, today, to be the future channel for reselling virtual company services
like Unified Communications.  Packaged and sold to businesses who no longer have a brick and mortar establishment, but rather a bunch of at home
workers who connect online with their co-workers in a virtual company, managed by a social networking site, doing all their work in the cloud.

Matthew Hartley
Siemens Enterprise Communications, Inc
matthew.hartley@siemens-enterpirse.com

 The other day, we had a rather severe weather event in my area that resulted in a rather lengthy outage of our cable service and in turn no connectivity to my enterprise. Luckily for me, I had a backup plan and was able to reconnect
using my cellular 3G card. It got me to thinking about all of the possible points of failure that can impact us in the enterprise. In a typical enterprise, there are many moving parts that must all work together to provide end users seamless
connectivity and high availability. Even with ever increasing reliance on other modes of communications such as email, Instant Messaging, and even social networking today, the end user still has literally no tolerance when their voice platform fails. You can probably blame your local telephone company for setting this expectation since they had decades and decades of experience to build highly redundant and highly available voice networks. This expectation transitioned into the enterprise with the advent of the PBX. These platforms were hardened appliances that were engineered for maximum uptime and many PBX providers had maintenance services to provide critical spares to customers that were willing to pay for it. In short, voice failed in only the rarest of occasions and when it did fail it was fixed promptly. So it's completely legitimate and logical to ask if we can obtain the same kind of resiliency in a world where communications has been converted from TDM to IP, from hardware to software, run on separate networks to converged with all other enterprise
traffic and even embedded into line of business applications. The obvious answer to this question  is "Of Course It Can".

 In order to achieve the same level of business continuity in this brave new world, it's critical to ensure that you have the right architecture. The attributes of such an architecture are varied but some of the critical ones are listed below.

 Active/Active vs. Active/Standby: In an active/active architecture all registered endpoints are cached on both sides of the cluster. Most enterprise voice platforms today support active/standby in which a re-registration process must take place when one side of the cluster fails. This is completely unsatisfactory in an enterprise production environment today. Active/Active ensures that not only is a re-registration process not necessary but when a side of the cluster fails, the end user knows no difference. They continue to process calls and invoke features. Furthermore, the architecture is built so that only one side of the cluster is necessary to support all subscribers.

 Multiple levels of hardware/software redundancy: Simply put this means no single point of failure in the core call control platform. From a hardware perspective, this is normally handled by replicating all critical hardware interfaces and components in a server (hard drives, processors, NIC cards, and power). The software is much more complex. Linux as an underlying OS is critical. In addition, some clustering functions are required that work in concert with the OS as well as the application to optimize the failover process when it's necessary.
 
 From Embedded to Standalone: Some UC architectures today have completely intertwined the call control with other communication channels that a failure in the core architecture means all communication channels are impacted. The architecture must support the ability to back off to a basic voice capability should the application platform become impacted.
 
 Standalone Survivability: As I mentioned previously there are many moving parts in the enterprise today and so even with the most resilient architecture there is always the possibility for network hardware or the network in general to fail. When this happens a typical customer may not have a backup connection. That means the individual site must be able to standalone and provide basic services to the end user as required. It must do so in a seamless manner and must restore service to the core platform when the network is available again.
Some architectures provide these standalone functions in combination with the routing functions. This can be a significant issue if that platform fails as all services in the branch will be impacted.

 Beyond the attributes mentioned above, I believe it's possible to take the resiliency functions even farther. With the right combination of software, hardware, and networking complimenting each other, resiliency can be extended and multiplied. Take the example of my cable service outage at the beginning of my blog. Extend the principle of using a wireless backup capability to restore service in the enterprise space. With the advent of 3G and soon 4G, it would be possible to provide this alternate network connection on demand. If you take this concept forward you can see an environment where virtual software functions can be moved from data center to data center ensuring call control will always be available.
In my opinion, we are nearing the day when we will raise the bar for resiliency that was originally set by Ma Bell a long, long time ago.

Dont you love marketing terms!!!

Hey folks, in my on-going series of blogs covering Seven Core Principles of Open Communications, I thought it best to start with a recap of the first four principles we have covered thus far. Our first four principles have covered the following

• Unified Communications
• IT Based Communication
• Fixed Mobile Convenience
• Business Process Integration

The 5th principle is a bit of a marketing term on one hand but has some very real and lasting implications for customers on the other hand. There is no other component of a communications platform that can make or break its success like the user experience. An easy to use, intuitive interface can mean rapid end user  uptake and ensure customer loyalty for a long time. Provide something that is clumsy, non intuitive, expensive, and proprietary and you can expect some unhappy users and that means unhappy customers !!! 

Lets further define the concept of a Rich User Experience. In my humble opinion, this boils down to some key attributes. 

Ease of Use: You notice most people dont have to spend a great deal of time learning how to use their mobile devices. Thats because handset manufacturers understand that ease of use equates to customer loyalty.

Flexibility:  For Unified Clients, I would say this equates to how easy it is to incorporate the main functions of the client across dfferent devices and workflows. Can I take the same client functions and embed them in a workflow or on a mobile device to have the same familiar interface to work from.

Consumerization: Hey is that a word!!! What I mean by that is allowing the user experience to be customized with attributes that give the user some ownership and emotional attachment ( I know its getting a little heavy right) It can be simple things like ring tones, or changing the skins, moving the different components around to better fit your personal way of working. The more emtionally attached you become the more likely you will be productive and more importantly the harder it will be to switch to something else.

Multimodal: Some users prefer to use their voices to communicate,others prefer to use IM, some like Email (I cant stand email) while others still like video. A Rich user experience gives the end user choice and allows for escalation from one media stream into another in a seamless fashion (IM to voice/Voice to video), 

In my view, a lot more emphasis should be placed on the end user experience to ensure buy in and productivity takes place. After all if the user isnt happy there is a good chance you wont be happy either..know what I mean.

Among the many tasks I perform in the CTO office, customer interaction is by far my favorite. I supopse the main reason is that I am constantly seeking to get customer feedback and input on our strategy. The other day a customer asked me a rather complicated question around unified communications, Business Process Integration, and what the value would be to his particular company. I have to admit I was not prepared to answer his question directly since it was our first meeting. Normally I like to get the customer talking to me about their business and the associated challenges before I would try to provide the kind of advice that would be meaningful. After the meeting, I spent some time considering the question in more general terms. Integration of voice and data applications has always been a forgone conclusion for our industry. It was just a matter of when. Now that we are in the middle of the UC revolution, acronyms such as BPI, CEBP (communications enabled business processes), and CEBA (communications enabled business applications) get mentioned in articles, press releases, panels, and customer briefings constantly. Its a whirlwind of concepts that are often difficult to comprehend let alone pronounce. Lets try to break it down into something more easily understood. 

Most if not all large enterprises have business processes that they utilize within departments as well as across departments. These processes help define roles and responsibilities and drive some consistency and efficiency within and between enterprises. When ERP systems were all the rage in the 90's, there were several high profile lawsuits against ERP vendors from customers who claimed the vendor's technology didnt deliver on their promises. One of the lessons that vendors have taken away from this experience is that no matter how wonderful your technology a successful implementation hinged equally if not greater on the end users abilitiy to adapt and fully use the new system often in fundamentally different ways than they were used to. Whats all this have to do with BPI and Unified Communications? In my opinion, we are going through a very similar exercise today with UC. Often times a customer's business culture is unable or unwilling to make use of the benefits that UC and BPI can provide. I contend this has more to do with the way you go about introducing the technology but it also has to do with how flexible your offering is to work with the line of business applications the customer employs.  Customers should have the following criteria for vendors they are evaluating in this area.

 

• Are the APIs extensive enough to provide multiple integration points into a customer application
• Beyond the standard line of business apps, what other integrations can be offered into areas such as management, modeling, and provisioning applications.
• Does the vendor have a well conceived methodology covering needs assessment, design, integration, and on-going monitoring to ensure success
• Does the vendor have experience across the line of business landscape or just within one segment (Microsoft only, IBM only, SAP only)

Of course these are just a few questions that should be asked. Just as important to the overall success of implementing BPI through UC is how well you know and understand your corporate culture. Does your company typically work in silos, do your employees embrace change or are they somewhat resistant. Do you natuarlly collaborate across departments or with other companies/customers/partner? How do you measure employee productivity? In addition, it is important to understand and model employee roles and responsibilities.  Are employee roles well defined today? Finally, how well do you understand your current business processes? Are you able to model these processes to see if they are viable and efficient today? Are you able to analyze where improvements can be made?  If not is your vendor capable of providing this service in order to identify where UC atrributes can be applied to result in improvement.  

if you can answer the questions above than you are well on your way to gaining real value for your enterprise with BPI/CEBP.

The Enterprise Market has been absolutely bombarded lately over the topic of Cloud Computing.  Naturally my interest in Cloud Computing extends to Unified Communications in the Enterprise. SIemens Enterprise announced a proof of concept with Amazon Web Services at VoiceCon over a month ago. The Idea behind the proof of concept was to address several key concerns that customers have articulated around UC as well as to demonstrate the adaptability of an Open Communications software platform. 

Many enterprise customers express frustration with Unified Communciations today especially in the SME segment but also within the Large Enterprise segment. Customers tell me that implementing UC is a complex task requiring capital investments both human and financial as well as time. When the ROI is expressed in soft dollar savings, it becomes very difficult to justify such an investment especially in the current economic situation. So the logical question is "How does Unified Communications in the Cloud Address some of these issues?" In the Case of the proof of concept I mentioned above, the direct impact of offering UC in the Cloud is that it removes much of the complexity of adopting and piloting UC. First, the UC software is already running in the cloud so no hardware/software capital expense is necessary, Second, through a portal offering an enterprise customer can sign up for service and receive their own dedicated instance of the application. Customers have the choice of provisioning users on their own or using Siemens Enterprise or a channel to perform this work on their behalf. The approach addresses the human capital concern as well as some of the time concerns customers worry about. Perhaps one of the most important aspects of UC in the cloud is that enterprise customers can expirement with UC at low risk to determine if it works for their environment. If a customer decides they are not ready or it doesnt deliver on their expectations they can simply turn off the service (They only pay for what they have used...a true utility model). 

UC in the Cloud is a natural extension to Unified Communications and the future is really a blank canvas where you can imagine all kinds of innovation. IBM, Oracle, salesforce.com, and other application vendors have all announced plans to run on Amazon's EC2 infrastructure. Aside from running their UC portfolio in the cloud, Siemens Enterprise has also announced plans to release an SDK platform to the more than 450k developers currently operating in Amazon's cloud. Its not hard to put two and two together. You could easily see a mashup of UC apps embedded in these line of business apps and delivered as a service to Enterprise Customers. This would have a multiplier effect on the ROI for customers given the added complexity of CEBP. Looking down the road you can see all sorts of interesting applications for disaster recovery, hybrid models, Federation points, and on and on. Once your application sits in a cloud such as Amazon's EC2 the sky may not even be the limit.

 

Greetings All

I have been expirementing lately with a variety of social media tools and looking at their usefulness for the enterprise space. WIthout a doubt Social Media is having a major impact on enterprises today and this impact will only grow going forward. One tool in particular that is very intriguing to me is Twitter. Twitter has experienced explosive growth over the last 4-6 weeks (probably because I have started to use it..just kidding).  Why is twitter so popular? I believe the answer is twofold. Twitter is very easy to use and folks dont have to write long drawn out articles to get their thoughts or message out. In fact you only get 140 characters so it forces you to be very efficient in articulating your thoughts. The other reason (of course there are more than 2 reasons but simple is better in my book) is that a user can subscribe to only the content they want to follow.  Dont like what a partcular tweet you can unsubscribe. I  think the combination of these 2 attributes will make Twitter a success in the long term. We already see a great deal of innovation being built off of Twitter (  twibes, tweetbrain, or dashboard apps like tweetdeck) and clearly it offers yet another mechanism for people to network and collaborate although not in the traditional sense of the word. 

The social marketing aspect of Twitter may be one of the most powerful attributes as well. This weekend alone I noted at least 20 tweets on one product in the span of 12 hours. The idea of promoting a brand or product in this manner may seem strange but it is grounded in sound marketing principles I can assure you. You can build a great deal of buzz and interest in this manner and I am witnessing it firsthand every day.  In short I'm all a Twitter over Twitter..

I was thinking about how I would approach this component of the seven  principles of Open Communications. Fixed Mobile Convenience is the one aspect of Open Communications that I believe is central to how we operate now and into the future.  There are numerous marketing messages out there about the increasingly mobile workforce so I will try not to bore you with more of the same. You may have noted the term Fixed Mobile Convenience vs Convergence. I used convenience because it illustrates the idea that subscribers should have choice especially when it comes to their mobile offerings. For some end users, it will be important to have one device from which to communicate with rest of the enterprise. For others it will be critical to be reachable on a single number despite using multiple devices during the day. There is another aspect of mobility that requires a user to be able to move between deivces within the enterprise and have their features and functions follow them wherever they go.  

What is clear about the above is that mobility is not a one size fits all proposition. The term convenience really addresses the need for flexibility and the reality that all three environments exist within most enterprises.  Customers need to ask their vendors some key questions such as how they define FMC and what flexible FMC solutions can they offer. You see, despite the marketing hype thrown out regarding FMC, whats really important to understand is that we are an increasingly mobile workplace. Because we are so mobile we should not have to sacrifice the ability to be connected in the manner that best suits our own purpose and preference.

Greetings Everyone and first let me apologize for my long absence since my last blog. I have been working feverishly on a new Go To Market Approach for our UC portfolio and I was also fighting a rather serious cold for the last few weeks (OK this is better than telling you all the dog ate my homework isnt it). I hope to post soon on this new market approach but today I want to continue on with the seven principles I laid out in my initial blog. The second key principle of Open Communications is the idea of "IT Based Communications". At first glance this might seem like a nifty marketing term but if you start to think about what this might mean for your enterprise it becomes very relevant in the way in which enterprises design and deploy communications into their enterprise architectures. By way of background its common knowledge that most communication platforms have been implemented as standalone components with perhaps one or two narrowly defined interfaces that would touch the IT infrastructure. With the advent of IP telephony and now Unified Communications, the power of software has revolutionized the concept of how you deploy your communication assets. In addition, there is no longer the implication that communication is only voice oriented. In fact communications has become multimodal with email, chat, text, web, and video coferencing all playing a vital role in how enterprise customers interact.  Of coures voice still plays a foundational role in this new paradigm and its critical to understand that customers should not have to put up with less voice capability to enjoy the benefits of richer communication functions.

For IT based Communications to be succesful, it has to be tied into both the application fabric as well as the infrastructure fabric if an enterprise architecture. The application fabric refers to embedding the realtime functions of communications, presence, and collaboration into the day to day workflow of your subscribers. This is commonly referred to as Business Process integration or Communications Enabled Business Processes (CEBP). Instead of having tightly defined and largely separate domains for voie and IT, the two are tightly woven together and realtime communications are consumed into application space.The second component of this principle is the integration of your communication assets into the IT infrastructure. I submit this is an equally important and critical element of Open Communications. The extent to which an Communications element can be designed, deployed, integrated and managed by standard IT best practices and tools, signifies the degree to which a vendors implementation can be considered IT Based Communications. Some examples include the following

 

• leveraging the standards based interfaces and protocols in use at the infrastructure layer.
• Providing either direct connectivity or proxy based connectivity to enterprise FCAPS platforms so that the communication infrastructure and IT based infrastructure can be managed in a holistic manner.
• Supporting deployment options such as virtualization so that your communication software assets can be deployed in the same manner as other IT applications.

We are in the beginning phase of Unified Communications Transformation and its imperative that customers evaluate their vendors on these principles. As I mentioned in a previous post, once customers take a hard look at these principles and start applying them to their vendors, the list gets short in a hurry.

Drop me a line or post some comments whether you agree or disagree. I promise my next post will come much sooner.

 

In my first blog, I provided some background on the principle of Open Communications as well as some context to why this is critical for Enterprise customers. The first principle of Open Communications that I want to explore is Unified Communications. This is perhaps one of the most critical topics in our industry today. The hype surrounding Unified Communications has reached epic proportions in our industry. There are literally dozens of blogs written specifically on this topic so it might be odd that I would put in the context of a broader set of principles but in fact this is where it belongs.

A bit of history on this topic is probably in order. Over 10 years ago our industry began a monumental change with the introduction of Voice over IP.  One of the key messages of this transformation was the enablement of voice and data applications over a single network infrastructure. The promise of tighter integration between voice and data was one of the lynchpins to buy into Voice over IP. It's fair to say that ten years later we have made significant progress in the adoption of VOIP but it's equally fair to say that the promise of tighter voice and data integration has not been fully delivered. Yes we can run voice traffic over IP networks and yes we have realized some level of integration with data applications but nothing approaching the promises made oh so long ago.
 
Enter Unified Communications. Positioned as the next step in the evolution of enterprise communications, UC is really the attempt to deliver that which VOIP did not. Specifically UC deals much more directly with application layers to achieve the integration that VOIP could not achieve.  VOIP did not achieve this level of integration primarily because VOIP did not leverage open integration, APIs, SOA architectures, and the necessary integration skills to put it all together. In fact, VOIP was primarily a recreation of TDM technology riding on an IP layer. In other words, it didn't deliver Open Communications as it initially promised.

It's not hard to understand really. The available protocols to achieve this level of integration were not really present 10 years ago and the willingness to open their platform seemed foreign to most vendors.

In some ways vendors are repeating the same mistakes they made with VOIP in UC. How is that you might ask? If you separate the marketing hype from the technology, and focus on the vendor's architecture, you can quickly separate the pretenders from the real deal. For Unified Communications to be truly open, it has to be based on the following attributes

It must be based on a pure software model.
It has to provide open integration at multiple layers and not just one or two  APIs.
It must leverage Open standards in all facets of the architecture (CODECS, signaling protocols, SOA architecture, Web services etc.)

One example that highlights the above is the implementation of SIP as your signaling protocol. This is generally considered the De Facto standard today and many vendors claim it as one of the core components of their call control architecture. However SIP alone does not necessarily drive an Open Communications approach. Some vendors provide SIP over non standard CODECS or mated to specific hardware platforms such that the enterprise customer is still locked into their architecture or severely limited in their choice when they utilize this approach. This often creates a 'Walled Garden Effect' where communications within that vendor's domain is full-featured and offers the end user all the functionality they could want. However, when you link this vendor to another vendor the capabilities drop substantially.

In an Open Communications paradigm, there should be no limitations when multi-vendor integration occurs. So we place Unified Communications as one tenet of a larger equation that drives towards the goal of Open Communications.  I welcome your feedback on this and any other topics so drop me an email

Paul.McMillan@Siemens.Com
 

Welcome one and all to the newest TMCnet blog on Open Communications. As the title suggests, we will be discussing Open Communications and how it relates to the Enterprise Communications market today and into the future.
I want to take a moment to introduce myself as this is my first posting. I have been in the communications sector for well over 20 years working in the Military, Federal, and Commercial spaces.
 In my current role, I am working in the office of the CTO looking after our technical vision and strategy as it relates to our UC portfolio. Its been an interesting 20 years in the communications industry
When I started out over 20 years ago in the military, we used proprietary technology almost exclusively. Everything down to the multiplexing/de-multiplexing of voice channels had a proprietary component.
The software was often custom coded and had millions of lines of code.The costs associated with this approach were enormous but more importantly, the technology was usually antiquated by the time it reached full deployment.
Soon after the first Gulf war ended, there was a major shift in the approach of acquiring and developing new communications systems in the military.The most obvious change was the move towards acquiring and integrating
off the shelf hardware and software as part of the development cycle. The reasons for this were mainly expediency (what we would call time to market in the commercial sector).
A normal acquisition cycle could take as long as 8 years to go from concept to deployment. With the move towards 'Off the shelf hardware' called COTS, the acquisition cycle could be dramatically reduced and the costs associated
with the development cycle were reduced as well. 

 Fast forward to the year 2008, we are in the midst of a massive transformation towards a more open software based Communications environment. The Unified Communications Market is undergoing significant change and the field is more crowded than ever with claims of  "Open Interfaces" or Standards Based" getting tossed out there with reckless abandon. Seems like the Market could use some definition around what it really means to be open. Perhaps it's better to view this as a set of principles that Enterprises can follow to determine if the solution they are looking to implement is really "Open". We at Siemens Enterprise Communications have identified Seven Key Principles in an attempt to define and embody Open Communications.
 In the coming weeks I will touch on each of these 7 Principles in more detail, but for now I will provide basic definitions as a starting point.

Unified Communications: Open Communications unifies business communication and collaboration into a single, simple concept.
IT Based Communications: Open Communications embraces open standards and an open IT-oriented software approach to communications.
Fixed Mobile Convenience:  Open Communications uses the most cost effective network without losing the convenience of mobile devices.
Business Process Integration: Open Communications increases productivity by deeply integrating unified communication into workflows.
Rich User Experience: Open Communications solutions are human-centric, focusing strongly on the ease of use and joy of use.
Business Continuity and Integrity: Open Communications ensures business continuity with carrier-class (scale, security and resiliency) architectures.
Open Service Delivery: Open Communications solutions can be deployed in many ways including multi-vendor, managed or hosted options. 

In addition to discussing the topic of Open Communications in this blog, I will also be delving into other areas of interest and will try to provide a glimpse into what lies ahead in our industry. I invite you to submit comments, suggestions, and observations on these topics. If you have a topic that you wish to discuss drop me an email.