DIY编程器网

标题: 全新协作的构架方法论 [打印本页]

作者: admin 时间: 2014-10-13 10:10
标题: 全新协作的构架方法论
在当今的企业中，通信与协作越来越重要，随着面向协作的产品和技术能力的不断进步，以传统方式运营的企业将面临一些新思维的挑战。这些新思维包括：

企业无边界化：过去，企业将自己视为孤立的实体，用一个特定的企业边界用来隔离外部和内部活动。而现在，随着企业寻求扩展全球化和公司间协作的价值链、获得更多竞争优势，是否能跨越传统防火墙开展工作已是业务成败的关键所在。
移动办公：全球的移动化劳动力在2010年已超过10亿，并且到2013年将增长到近12亿—超过全球劳动力的三分之一。无论员工在什么地方，他们都应该能够访问企业信息和协同工作应用，这一预期正在改变工作文化和方式对物理办公场所的依赖性。
IT的个人消费化：工作中越来越多的采用个人消费类的技术，正在孕育一个“泛化参与”的新时代。过去只在消费者领域中常见的Web 2.0工具已经应用到企业中—而且很多时候并未得到IT部门的同意。这些工具正在改变信息的创建、发布和使用方式，同时也向CIO提出新的挑战，关乎隐私和信息安全。
信息激增：到2020年，数字数据将增长到35万亿GB—比2009年时多44倍。因为这些数据中绝大多数是非结构化的，所以确定如何管理、定位和高效地使用这些数据成为又一个重大挑战。要利用这一新的通信环境提供的机会，组织必须采用一种“整体架构化”的方法，侧重于如何使IT能适应业务需求。成功的协作计划需要：
根据业务需求而非技术来制定的清晰战略？根据组织需求而设计的架构框架？充分分析和理解文化因素
定义监管方式整体协作架构通常使用术语“统一通信”、“Web 2.0/Enterprise 2.0”和“社交媒体”来描述协作，这些术语可以互换使用。不过，这些术语中没有一个等同于协作，因为每个术语都只是这一宽广领域的子集（参见图1）。

对于要开发和利用全面协作功能的企业，他们必须确保评估流程不仅仅涵盖统一通信或Web 2.0，而是包括所有的协作功能。

不过，企业协作战略和架构未必一定要描绘一个蓝图，用于部署每个可用的协作功能。评估流程应当引导建立这样一个协作战略和架构：它们是有选择性的、仅包括有助于满足已确定业务需求的那些功能。图1描述独立于供应商和产品的概念性协作架构。

它从企业的角度进行设计，并提供一个用于评估协作需求的结构化框架。此图示还标识出协作功能的完整列表并定义在评估协作计划时企业必须考虑的架构组件的整体视图。

图1.概念性协作架构

图1中描述的组件的定义如下所述：

网络/网络服务：通过网络平台，可以在整个企业中和企业外扩展和管理协作功能。
核心协作功能：这些功能是所有协作解决方案的基本构成模块。当有新的核心技术出现时，可以根据需要更新这些功能。
协作套件：这些包含两个或更多核心协作功能的功能集是严格专用于协作的；例如，即时通讯工具应用可以提供下列核心协作功能的某些组合：
-即时消息传送
-在线状态（离开、忙碌、请勿打扰）
-设备状态（挂机/摘机）
-点对点视频-点对点语音
企业服务：这些业务关键型系统和数据用来实施和管理业务，但不一定能够促进协作。示例包括企业资源规划、人力资源管理，等等。
集成协作功能的应用程序：这些工具可将核心协作功能、协作套件和企业服务整合到一个新的应用程序中。比如：将可用性呈现、设备存在状态与企业目录信息和企业搜索功能组合在一起，创建一个专门的位置应用程序。
启用协作功能的应用程序：这些工具使用核心协作功能和套件来扩展具有协作功能的基本应用程序的功能。示例包括在客户关系管理应用程序中提供在线状态功能。
业务流程：正式的和临时的业务流程都用于促进协作性交互。要提供相关性，协作架构必须能够识别并支持所有业务流程的要求。
个性化/定制：这些特征允许架构根据用户的角色来控制协作功能，同时给予用户根据个人喜好定制其协作体验的能力。
呈现/设备层：此架构层提供用于定制可以认识到差异性（例如，移动设备与桌面计算机上的不同协作体验）的协作流程和数据的各种界面，围绕这些差异进行优化。
用户配置文件（企业/外部）：这些配置文件用于解决个别用户的独特通信和协作需求，以帮助确保架构的业务和技术相关性。
监管：对人员和流程的结构化使用，支持协作解决方案的有效的长期管理和扩展。

欢迎光临 DIY编程器网 (http://diybcq.com/)