Today, Communications Architecture, which focuses on the technology and services of how people interact with each other, business processes, and information, is spread across multiple IT architecture domains. The goals in defining Communication Architecture are:
* Acknowledging that communications warrants its own IT architecture domain
* Agreeing how communication architecture fits with other IT architecture domains
* Defining what makes up a communication service is its influence on how we communicate based on the who, what, when, where, and why of communication
* Describing all the services that are within the communications domain along with which services communications needs to interface with
* Building communication services that are modular and vendor/product independent
The benefits of communications architecture will be improving the speed, efficiency, and effectiveness of how a business communicates. This will be accomplished by building communication services that are modular so that adding, changing, and integrating functionality is faster, easier, and cheaper. All the advantages of going to a Services Oriented Architecture (SOA) in IT apply in treating communications as a set of defined services.
Just like a building blueprint is the master architecture around which the electrical, HVAC, landscape and other designs are built, a business has its own business architecture. Any change to the business architecture has an impact on the other IT architectures. By defining communication as its own domain, the questions of how communication will occur will be tied closer to the business objectives. Also, a building architecture is built upon a bunch of commodity components (steel, concrete, glass, wood...), which means a business should not have to worry about the technology, vendor, or product in order to meet their objectives.
Today, within most IT organizations, communication services are spread across many different organizations and platforms. The network group will have telephony, conferencing, voice messaging, and contact centers. The desktop group will own internal email, chat, presence, file sharing, and collaboration. Application development teams will own web portals, external email/chat, and forms for the business unit that they support. Each group uses a different vendor/product to provide their communication services. Integrating communication across all parts of the business (internal & external), across all channels (voice, video, email, web, text), and all processes (sales, supply chain, manufacturing, service, support, billing, and administrative) is a challenge. Communication Architecture needs to stand on own, which starts with defining what it is.
Personally, I am very interested in your feedback to this post and the associated 3 page definition (available as a PDF here). Communication Architecture is the title of a book that I have started. The idea for the book started when Irwin Lazar wrote "Creating a UC Reference Architecture" on NoJitter last fall. I will also be at VoiceCon and could host a Birds of a Feather session, if there is interest.
