下载掌阅APP，畅读海量书库
立即打开
企业架构实践中的关键角色是
架构师
。架构师在组织中充当首席信息系统规划师和业务及IT相关计划的整合者。理想的架构师是有效的沟通者、团队合作者、创新者和系统思考者，在业务和IT方面均有丰富的知识。这些特性使架构师能与各种业务和IT利益相关者沟通，了解其关注点，并提出最佳的规划决策，满足所有各方的基本利益。尽管架构师通常来自IT部门，并有IT背景，但他们并不完全属于IT专家或业务专家的阵营。相反，架构师是连接业务和IT的“T型”专才，即寻找满足业务战略和需要的最佳IT战略和解决方案的专家。
架构师是EA工件的主要拥有者，是业务和IT之间对话的促进者。他们在组织、建立和运行企业架构实践中起着关键作用。即使架构师本身不能成为企业架构实践的发起人或最终受益者，他们也是大多数EA相关过程的主要参与者之一。架构师的典型职责包括：
● 分析外部技术环境。
● 研究内部组织和IT环境。
● 与各种业务和IT利益相关者沟通，了解其关注点。
● 促进不同利益相关者群体间的对话和交流。
● 在不同的利益相关者间充当中间人。
● 寻找、提出并讨论最佳的规划决策，以满足所有利益相关者的关注。
● 开发和更新EA工具，以支持讨论和文档化所达成的协议。
● 确保执行反映在EA工件中的商定的规划决策。
● 同行评议和批准其他架构师开发的EA工件。
● 建立和维护EA库。
● 设置必要的软件工具以处理EA工件。
● 建立、运行和优化EA相关流程。
● 参与其他需要架构师专业知识的特殊活动，例如，供应商合同谈判和并购的技术尽职调查。
由于企业架构与传统架构不同，因此企业架构实践中的架构师也与传统架构师不同
。他们并不像古典架构师设计建筑那样设计组织或技术景观，而是与相关的利益相关者讨论并就其期望的演变达成协议。传统的架构师往往被认为是孤独的策划者或独具慧眼的远见者，能创造出宏伟的设计，而企业架构实践中的架构师首先是积极主动的关系建设者和充满活力的团队成员，能够找到折中的方案并协商出双方都满意的规划决策。做个比喻，他们在组织环境中的角色最合适被描述为沟通者，而非设计师或工程师。
重要的是，架构师的职位是专家，而非管理岗。架构师通常没有直接下属，也未被赋予任何行政权力或决策权。架构师必须用他们有说服力的意见柔和地影响决策过程，且他们对大多数组织决策没有最终决定权。架构师的建议必须通过明确的论证和说服以“推销”给真正的管理者——他们被授权代表组织对技术的采用、资金的分配、项目的启动或取消做出正式的决定。
尽管架构师在组织中的职责是多样化和多层面的，但所有架构师的最关键职责之一是开发必要的EA工件，以支撑企业架构实践。
架构师是企业架构实践中所有EA工件的关键开发者。他们亲自负责让相关的利益相关者参与进来，收集必要的数据并完成开发EA工件所需的所有其他活动。然而，由于其不同的含义、目的和性质，决策型EA工件和事实型EA工件的典型开发和更新过程有很大不同（见表2.1）。
一方面，决策型EA工件的开发和更新是一个复杂的、创造性的、棘手的过程
。由于对决策型EA工件的所有修改，包括其初始开发和可能的后续更新，均需所有相关的利益相关者就未来的行动方案达成共识，因此这些工件总是由架构师和他们的利益相关者合作开发
。多个利益相关者群体行使不同的权力，代表着不同甚至冲突的观点，这往往使决策型EA工件的开发成为高度政治化的过程。从本质上讲，合作开发决策型EA工件就是规划的实际过程。尽量架构师通常作为其发展的促进者或推动者，但从本质上说，决策型EA工件是团队集体工作的产物。这些工件通常以主动方式创建。
开发或更新决策型EA工件通常始于对具体规划决策的需要。首先，架构师组织与这些决策的所有相关利益者的非正式初步对话。在这些讨论中，利益相关者和架构师就可行的规划决策达成基本共识。然后，架构师将建议的规划决策正式发布为新的或更新的EA工件，并与相关的利益相关者合作，用必要的细节详细说明这些工件。在此合作过程中，所产生的EA工件会被最终完成，并与所有的直接利益相关者达成非正式的协议。最后，已完成和最终确定的EA工件需经过正式的集体批准程序，并最终成为代表所有参与其中的利益相关者和架构师共同做出的规划决策的正式文档。从这一刻起，所有参与方都承诺按照这些决策行事。例如，为了制定原则或解决方案设计（见图2.6），架构师可能会安排一系列与利益相关者（分别是业务高管和IT项目团队）的会议，讨论其观点和关注点，根据收集到的意见提出EA工件的初始版本，与利益相关者一起组织研讨会来详细说明和完成这些工件，然后将这些工件的最终版本分发给所有利益相关者，供其正式批准和签署。EA工件被签署后，所有参与方都承诺将他们的决策与新建立的原则保持一致，或完全按照开发的解决方案设计中的描述来实施IT解决方案。
重要的是，EA工件的主要价值是在开发过程中实现的。多个利益相关者在开发决策型EA工件上的集体合作有助于这些利益相关者的沟通，实现相互理解，并在考虑到所有各方的基本利益的情况下产生最佳的规划决策。当实际的EA工件完成时，这些工件中正式的关键规划决策已经做出。基本上，最终决定的EA工件只是记录了利益相关者在开发过程中达成的协议。从这个角度来看，利益相关者开发决策型EA工件的合作努力要比实际产生的工件作为有形的正式文档更有价值。换句话说，对于这些工件，过程比产品本身更重要。最关键的成功因素是所有利益相关者及时参与开发过程。
另一方面，事实型EA工件的开发和更新是一个更简单、更常规和更直接的过程。与所有利益相关者合作开发的决策型EA工件不同，事实型EA工件通常是由个别架构师单独开发的，或者只有极少的其他参与者参加（见表2.1）。这些工件通常是在必要的基础上被动地创建。
事实型EA工件的开发或更新通常始于对特定文档化事实的需求。首先，架构师从所有相关来源收集必要的原始数据，这可能包括研究可用的文档，询问有能力的人，以及从现有的IT系统或库中提取数据。当收集到足够的所需事实信息时，架构师会创建新的或更新现有的EA工件，详细准确地记录所发现的事实。由于事实型EA工件只描述了“是什么”，并不意味着任何规划决策，也对其无任何影响，因此完工的事实型EA工件通常不需要由任何其他参与者批准。尽管如此，架构师仍然可以做出决定，回到提供原始信息者处，以验证所生成的EA工件并确保其正确性。在这些工件被创建后，所有的参与者都可使用其进行规划。例如，为了开发或更新景观图（见图2.6），架构师可以阅读最近IT项目的可用文档，采访IT支持部门的成员，搜索中央配置管理数据库，然后制作景观图，将所有收集到的事实描绘在一页紧凑的图纸上。架构师还可以回到IT支持团队处，仔细检查并确认所生成描述的准确性。从这一刻起，任何人都可以把新的景观图作为当前状态的参考基线，用于决策。
与决策型EA工件不同，事实型EA工件的主要价值是在开发后实现的。事实型EA工件的开发过程在本质上是高度机械的，没有任何内在价值。然而，在事实型EA工件开发完成后，这些工件的价值体现在作为支撑决策型EA工件开发的信息基础。从这个角度来看，实际生成的事实型EA工件作为有形的正式文档，要比架构师开发这些工件付出的努力更有价值。换句话说，对于这些工件而言，产品比过程更重要。与事实型EA工件相关的最关键的成功因素是描述的准确性和更新性。图2.7总结了上面讨论的开发或更新决策型和事实型EA工件的过程及其比较。
图2.7 决策型和事实型EA工件的开发
理解决策型EA工件和事实型EA工件之间的深层区别很重要。对决策型和事实型EA工件使用适当的开发流程对企业架构实践的成功绝对关键。虽然将事实型EA工件作为决策型EA工件来开发没有任何意义，但将决策型EA工件作为事实型EA工件来开发，很容易被认为是开发这些工件以及实践企业架构的“捷径”。然而，所有试图以类似于事实型EA工件的方式来开发决策型EA工件的做法都具误导性，并且极其危险，且可能对企业架构实践产生灾难性的后果。
以类似于事实型EA工件的方式来开发决策型EA工件（即仅通过采访相关的利益相关者，然后为他们创建决策型EA工件），不可避免地会用一厢情愿的想法、善意的幻觉和理想主义的想象来取代真正的实际规划。组织中所有重要的规划决策都必须与利益相关者讨论并达成一致，而无法由其他人代表他们做出
。此外，由于架构师没有正式的管理权限，因此他们无法执行任何决策，而只能说服他人相信其合理性。因此，架构师在很少或没有真正的利益相关者参与的情况下创建的决策型EA工件通常会被忽视，且从未付诸应用。因此，在开发决策型EA工件时，如果只代表真正的利益相关者来制作这些工具，就会把整个企业架构实践从沟通的驱动力变成无用文档的工厂。将利益相关者排除在相关决策型EA工件的讨论之外，消弭了使用企业架构作为沟通工具的本质（见图2.1）。简单而言，把决策型EA工件作为事实型EA工件来开发，很容易将企业架构实践毁掉。此外，在没有事先与其他利益相关者讨论并得到他们同意的情况下，即使架构师对决策型EA工件的格式进行“无害的”改进，也会造成严重混乱，应予以避免。
企业架构实践包括架构师和其他组织参与者，他们通过创建和使用EA工件进行沟通。然而，从决策型EA工件和事实型EA工件的角度来看，架构师和其他参与者的角色，以及他们在企业架构实践背景下的沟通和互动模式大为不同（见表2.1）。
一方面，作为所有决策型EA工件通用开发过程的一部分（见图2.7），架构师不断与各种业务和IT利益相关者沟通，分析其利益和需求，提出满足所有利益相关者需求的最佳规划决策，将这些初始决策正式化为EA工件，然后经过反复循环，进一步讨论、完善和澄清这些工件，直至利益相关者达成最终协议，并由所有参与方正式批准已提议的规划决策。即使架构师仍然是决策型EA工件的主要开发者，但提供意见并批准所生成工件的各种利益相关者本质上充当着该类工件的共同开发者。
另一方面，作为所有事实型EA工件的通用开发过程的一部分（见图2.7），该类工件唯一的开发者（架构师）从各种来源收集所有所需的数据，然后创建或更新相应的EA工件。图2.8显示了EA工件、架构师和上述企业架构实践的其他参与者之间的关系。
图2.8 EA工件、架构师和其他参与者之间的关系
通过领导与利益相关者的持续讨论，架构师提出在决策型EA工件中表达的最佳规划决策，并使这些决定得到批准，并在每个规划决策中实现所有关键利益相关者的利益平衡。由此产生的规划决策考虑到了所有相关业务和IT利益相关者的关键利益，从而改善了组织中业务和IT的对齐。由于关键利益相关者的积极参与对开发出代表相应的IT相关规划决策的决策型EA工件而言绝对必要，因此企业架构实践从根本上说无法在其他利益相关者
不参与的情况下由架构师单独进行。因此，组织信息系统规划的有效性并非架构师一人之事，而是事关整个组织。