IT部门在企业里没有话语权或是话语权很弱，因此，IT部门得不到领导的重视，IT部门的工作大都是被动式响应或救火，很难去用IT来引领业务；

  IT部门在企业里没有话语权是一个普遍现象。很多IT同行，在外面被媒体们冠以CIO的称号，而在企业内部，其实只是一个部门经理，有些甚至只是财务或其他管理部门下属科室的科室经理，是操作层面的基层主管。在笔者看来，“权”和“位”的关系，类似于“鸡”和“蛋”，孰先孰后，很难说清楚了。但有一点能确定，如果业务听不懂IT说的话，如果领导听不懂IT说的话，IT部门就不可能有话语权。反观企业的行政、人事或财务等部门，虽然和IT同样都是企业里的支持部门，虽然和IT同样不直接创造价值，但人家在企业里的话语权就比IT大得多，其中的原因是多方面的，但根本原因之一是人家说的话可以让老板听得懂，听得进！

  要让业务和老板听得懂IT说的话，就要提高IT与业务、IT与老板之间的沟通质量，从而让IT与业务、IT与老板之间有共识。哈哈，“沟通”这个词语，看起来非常普通，却又是那么玄妙。说它普通，是因为沟通是管理的基本职能和管理者的基本技能；说它玄妙，是因为很多人都想“直达天听”却又不得其门而入。作为一种实践，沟通不应是成功学的心灵鸡汤，也不应是阴阳家的三寸之舌，而应是人人应会、能会的知识和技能。俗话说，沟通要有桥梁；企业架构，就是IT与业务、IT与老板之间的沟通桥梁；有了这座桥梁，IT说的话就能让业务和老板听得懂，IT的工作就能和业务的期望对齐。而企业架构实践，就是IT人就企业信息化/数字化工作，与业务和老板达成共识的过程。

  首先，企业架构分别从规则（不易）、结构（简易）和变化（变易）等三个层面，把信息技术和IT工作与老板和业务部门的期望进行对齐，依靠的是业务考量、IT标准、业务愿景、IT全景、方案框架和方案设计等六类构件。在企业架构的六类构件中，业务考量、业务愿景和方案框架是站在业务的角度来讲，用的是业务的语言；IT标准、IT全景、方案设计是站在IT的角度来讲，用的是IT的语言；业务考量、技术标准讲的是规则，业务愿景和IT全景讲的是结构，方案框架和方案设计讲的是变化。规则、结构和变化，分别从不易、简易、变易等三个角度，有机结合、层层分解地描述了企业信息化/数字化的演变过程。

  业务考量是企业中全局性、长期性的、相对来说比较稳定的业务规则，主要代表包括业务的原则（企业在多大范围和何种层级保持流程的标准化和数据的集成化）、业务策略（业务开展时的负面清单，即哪些东西不能做，主要从安全、合规、风险等角度讲）、概念性数据模型（企业全局性的关键元数据，比如客户主数据的定义）、趋势变化分析包括（企业对颠覆性技术的应用态度）、方向性说明（业务开展的偏好），等等。业务考量的详细的细节内容，将决定了技术标准、业务愿景、IT全景、方案框架和方案设计的选择。

  技术标准是企业中全局性、长期性的技术规则，包括企业所采用的技术参考模型或技术栈（开发语言、中间件、数据库等）、工作指引或IT行业的最佳实践、逻辑性数据模型（全局性关键主数据的详细定义），等等。技术标准在规则上响应了企业和业务的需求。

  业务愿景从结构上描述了企业是如何做事情的，是业务能力的结构化。业务愿景的具体形式和代表包括业务能力模型或业务能力地图、业务能力的演变图、业务运行的理想状态、企业的价值链和运营背景，等等。业务愿景服从于业务考量的指导，同时指导IT解决方案的设计和实现。以业务能力为例，它是企业中业务流程、角色和岗位、技术和工具的融合，因而可当作IT解决方案设计时的主要输入。

  IT全景从结构上描绘了企业当前的IT全景图（Landscape）。IT全景的主要内容有IT系统组合及其相互关系、IT系统建设路线图、IT资产清单、IT系统与业务能力的映射关系，等等。IT全景既响应了IT标准的一般性要求，又响应了业务愿景在业务期望、IT解决方案、功能和性能等方面的要求。

  方案框架指的是某个IT解决方案的概览，是为了响应企业外部环境、战略和业务变化而出现的、短期性的举措。方案框架包括解决方案概念、解决方案可行性评估和方案建议书。方案框架从变化的角度反映了业务愿景将如何达成。

  方案设计指的是某个IT解决方案在技术变化方面的概念设计和详细设计，是解决方案实施时的具体依据。

  在企业架构中，业务考量、技术标准、业务愿景、IT全景、方案框架、框架设计等六大类构件，从长期到短期，从规则到实践，从一般到特殊，从业务到IT，层层递进，相互嵌套，系统而动态地反映了企业信息化/数字化建设的目的和过程。其中，业务考量、业务愿景、方案框架等内容，虽然采用的是业务语言，但也可以轻松又有效地被IT人员理解并转化为相关的IT要求。这样，从战略到执行，从业务到IT的沟通桥梁就搭建起来了。

  企业架构实践的真正意义不在其构件或输出物，而在于IT和业务就企业架构构件做讨论并达成共识的沟通过程，其本质是跨专业的团队学习。为了达成相关共识，IT和业务可以从如下六个沟通点来展开：运营模式、业务策略、业务能力、关键业务痛点、业务流程和业务需求。

  运营模式指的是企业在何种层面和多大范围上要求业务流程的标准化和数据的集成化。如果是企业全局的流程高度标准化和数据高度集成化，那这个企业的运营模式是“一体式”。如果是企业全局的流程高度标准化和数据的较低集成化，那这个企业的运营模式是“复制式”。如果是企业局部或本地的流程标准化和全局的数据高度集成化，那这个企业的运营模式是“协作式”。如果是企业局部或本地的流程标准化和局部或本地的数据集成化，那这个企业是运营模式是“分散式”。

  业务策略指的是企业各业务部门和支持部门的业务计划、经营目标和主要KPI。正如战略地图和平衡记分卡所述，内部流程是企业达成客户目标和财务目标的能力依据，而以技术、数据为主要内容的学习成长，则是流程得以高效运行的保证。因此，对业务策略的讨论，必然会推导出业务对流程、技术和数据等方面的具体要求。

  运营模式和业务策略的选择，将决定了企业中规则的设定，也就是业务考量的详细的细节内容和对技术标准的具体要求。

  运营模式和业务策略的选择，将对企业要提升的业务能力提出建议，而关键业务痛点则是就具体领域或具体能力提出明确性要求。IT和业务对业务能力和关键业务点的讨论，有助于推导和完善企业架构中的业务愿景和IT全景。

  前文说过，企业的业务能力是业务流程、角色或岗位、技术和工具等三者的融合体。企业中的业务流程设计，是IT解决方案设计的主要输入。换言之，IT解决方案的目的是将业务流程、角色和岗位等能力要求予以信息化/数字化。以需求说明书、业务场景、系统原型等为表现形式的业务需求，则是IT系统开发实现时的主要输入。

  如上所述，IT和业务可以就运营模式、业务策略、业务能力、关键业务痛点、业务流程、业务需求等内容展开不一样的层次的、广泛的讨论，从而在IT与业务之间达成尽可能多的共识。在讨论的过程中，企业架构既是输入，也是输出。说它是输入，是指企业架构可当作讨论的框架和指引，这样就能有序、丰富、有层次地展开讨论。说它是输出，是指讨论的结果可用于企业架构的更新和完善。

  在企业中，IT与业务就企业架构的讨论、开发和完善的相关工作，应该是日常性工作，是持续迭代和不断演变的过程。其中，有些工作是业务触发的，有些工作是IT触发的，有些工作是围绕IT项目的策划和实施来展开的。大体上，从内容和性质而言，上述工作可大致分为三类：战略计划、方案交付和技术优化。

  战略计划是对企业架构中的业务考量和业务愿景进行解读和开发。企业架构实践中的战略计划是企业战略管理的基本组成部分。企业架构实践中的战略计划应该每年回顾一次，一旦有变化，比如企业整体战略发生变化，或者外部环境发生变化或颠覆性技术出现时，业务考量和业务愿景也应做相对应的调整，以响应企业战略或环境的变化。

  方案交付指的是企业中某个信息化/数字化解决方案的交付，它是业务能力发展路线图和IT系统建设路线图中某个节点的具体实现。方案交付与信息化/数字化项目全生命周期管理相匹配，包括方案（项目）策划和方案（项目）实施在内的两个子过程。在方案交付中，企业架构主要作为方案和项目参考来发挥其指引性作用。

  企业的IT系统同样遵循生成法则，有生、长、衰、老、死的生命周期管理要求。在某个时间点，随技术的发展或系统使用年数的限制的增长，有些新的技术要导入，有些老旧的系统要淘汰，企业架构实践中的技术优化就是要通过不断的迭代和演变，以确保企业中IT系统和IT全景的稳定、健康和可持续发展。

  有历史研究表明，世界上各种战争的原由往往是交战方所持有的偏见。有些偏见是历史或文化导致的，有些偏见则是双方沟通不当所致。大到国与国之间的战争是如此，小到企业中IT与业务之间的冲突也是如此。IT部门要想拥有更大的话语权，要想在信息化/数字化建设中发挥更积极的作用，要从消除IT与业务之间的认知偏差做起，而企业架构和企业架构实践可以在其中起到沟通桥梁的作用。换言之，通过企业架构和企业架构的实践，可以推动IT与业务的有效融合和相互理解。