购买
下载掌阅APP,畅读海量书库
立即打开
畅读海量书库
扫码下载掌阅APP

4.2 企业架构工件和城市规划文档的六种类型

企业架构是特定EA工件的集合,用于管理组织演变的不同方面。同样地,城市规划文档也用于管理城市发展的不同方面。在成功的企业架构实践中使用的所有EA工件都可以分为六个通用的基本类型:经营考量、(技术)标准、(业务)愿景、(技术)景观、概要设计和详细设计。这六种通用类型的EA工件在企业架构实践中起着关键作用,在城市规划实践中也有直接的类似作用。

在成功的企业架构实践及城市规划实践中,经营考量和(技术)标准描述了定义组织或城市的某些规则,(业务)愿景和(技术)景观描述了组织或城市的高层结构,而概要设计和详细设计则描述了组织或城市的具体计划的渐进式变化。一方面,经营考量、(业务)愿景和概要设计从“可见的”最终价值的角度来描述组织或城市,即从组织的商业角度和从城市的宜居角度。经营考量、(业务)愿景和概要设计被业务高管或城市管理者分别用来管理技术景观或城市景观。另一方面,标准、景观和详细设计从支持主要增值实体的“不可见的”技术基础设施的角度来描述组织或城市,即从IT基础设施的角度和城市基础设施的角度。(技术)标准、(技术)景观和详细设计由架构师或城市规划师用来组织技术景观或城市景观。

六种通用类型的EA工件和城市规划文档中的每一种都回答了关于组织或城市的不同问题,并提供了一个独特的观点。具体来说,经营考量回答了组织或城市如何从商业或宜居的角度来组织的问题。(技术)标准回答了组织或城市如何从信息技术或城市基础设施的角度来组织的问题。(业务)愿景回答了从商业或宜居角度看一个组织或城市的高层结构是什么的问题。(技术)景观回答了从信息技术或城市基础设施的角度看一个组织或城市的高层结构是什么的问题。概要设计回答了从商业或宜居的角度对一个组织或城市提出了哪些具体的改变。最后,详细设计回答了从技术或城市基础设施的角度对一个组织或城市提出了哪些具体的改变。图4.1显示了定义上述六种通用类型的EA工件和城市规划文档的分类法。

经营考量、(技术)标准、(业务)愿景、(技术)景观、概要设计和详细设计是EA工件和城市规划文档的六个通用类型。每种基本类型在EA或城市规划实践中都有其独特的作用、目的、用途和价值。

图4.1 EA工件和城市规划文档的分类法

4.2.1 经营考量

经营考量是定义整个组织或城市的抽象的高阶准则或必要条件。这些总体要求对业务高管和城市管理者很重要,同时也对整个技术景观或城市景观有重大的技术影响。例如,对于城市而言,经营考量可以由定义交通政策的城市化原则、对特定建筑风格的偏好或通用的扩展要求来表示;而对于组织来说,经营考量通常由定义流程标准化和数据集中化政策的架构原则或业务连续性要求来表示。图4.2显示了与经营考量相关的EA工件和城市规划文档的典型例子。

图4.2 与经营考量相关的EA工件和城市规划文档

经营考量代表了规划决策(见表2.1和图2.7),因此,经营考量总是由组织的业务高管和架构师或城市的市长和城市规划师根据整体战略愿景协作制定。经营考量为整个组织或城市阐明了最基本的规则和基本要求,由所有高级利益相关者共享,且不常改变。由于其隐含的双重属性(见图2.5),经营考量向业务高管或城市管理者传达一种与价值相关的含义,但向架构师或城市规划者传达另一种与基础设施相关的含义。例如,架构原则指出“所有业务线都使用共享的客户列表”(见图4.2),对业务高管和架构师有不同的含义。对于业务高管来说,这一原则意味着公司可向同一客户交叉销售不同业务线所提供的产品;而对于架构师而言,同一原则意味着所有支持不同业务线运作的IT系统应使用单一的共享客户数据库 。经营考量在本质上是长期不变的,是永久型EA工件(见表2.2)。它们只为组织或城市一次性建立,然后定期被更新以保持相关性。

在达成共识后,经营考量为所有的进一步讨论提供了一个共同的基础,并影响所有的规划决策。经营考量的双重属性使业务高管和城市管理者能够潜移默化地塑造技术或城市景观,尽管经营考量通常没有明确提到任何技术或城市基础设施。

4.2.2 (技术)标准

(技术)标准是高度专业化的底层技术准则,规定了技术或城市景观应该如何组织和建设。这些准则对于架构师和城市规划师而言非常重要,但对于业务高管和城市管理者来说基本毫无意义。例如,对于城市来说,标准可由建筑标准来表示,它规定了用于特定目的的特定建筑材料、对某些类型建筑的特殊要求或交通车道的宽度;而对于组织而言,标准通常由技术标准来表示,它规定了使用特定的应用平台、特定的数据库管理系统或成熟的集成模式。图4.3显示了与(技术)标准相关的EA工件和城市规划文档的典型例子。

图4.3 与(技术)标准相关的EA工件和城市规划文档

(技术)标准代表了技术规划的决策,是由架构师或城市规划师据其对业务高管或城市管理者的最佳利益和关注点的理解而集体制定的。与双重属性的经营考量——它总与业务高管或城市管理者达成一致——不同的是,(技术)标准对于业务高管和城市管理者来说几乎不可见,因为它们反映的是高度技术性的规则,难以理解且不相关。(技术)标准是永久和相对稳定的。它们随着有前途的新技术或更好的方法的出现而定期更新,代表了IT系统或建筑施工中公认的最佳实践。

(技术)标准在建立后,会影响所有单独的IT系统或建筑设计,以及技术或城市景观的整体结构。它们有助于降低复杂性,实现技术或城市景观的同质性,重复使用经过验证的技术最佳实践,并确保其符合现有的监管规范。此外,(技术)标准可加速新的IT系统或建筑的建设,减少建设成本并降低相关风险。

4.2.3 (业务)愿景

(业务)愿景是抽象的,通常只用一页图就提供了整个组织或城市的高阶视图。通常,它们描述了组织或城市在未来3~5年内的战略发展计划。(业务)愿景中所反映的长期战略对于业务高管和城市管理者而言至关重要,同时从技术角度来看也对技术或城市景观有直接影响。例如,对于城市来说,(业务)愿景可用城市分区图来表示,显示未来应建设城市的哪些区域;而对于组织而言,(业务)愿景通常用业务能力地图来表示,显示未来应提升哪些能力。图4.4显示了与(业务)愿景相关的EA工件和城市规划文档的典型例子。

图4.4 与(业务)愿景相关的EA工件和城市规划文档

(业务)愿景代表了由业务高管和架构师为组织(或由城市管理者和城市规划师为城市)根据长期战略合作制定的规划决策。(业务)愿景与“经营考量”一致,反映未来的总体方向,并建议为执行业务战略或执行城市发展战略应该做什么。特别地,(业务)愿景通常阐明了具体的业务能力或城市区域。基本上,它们代表了所有高级利益相关者所认可的对未来的看法。由于其隐含的双重属性,(业务)愿景对业务高管或城市管理者传达的是一种意义,而对架构师或城市规划师则是另一种意义。例如,对于业务高管来说,图4.4所示的业务能力地图表明,他们的公司将提升某些符合业务战略和目标的业务能力;而对于架构师来说,同样的业务能力地图表明,他们的IT部门应该专注于提供新的IT系统,改善这些“热图”的业务能力 。(业务)愿景虽是永久性的,但本质上是不断发展的。它们只为组织或城市一次性建立,然后根据战略计划的最新变化持续更新。

(业务)愿景在制定后为指导未来投资和优先考虑拟议的IT或建设项目提供了合理的基础。尽管(业务)愿景中往往没有明确提到任何技术或城市基础设施,但(业务)愿景的双重属性使业务高管和城市管理者能够潜移默化地朝着正确的方向发展其技术或城市景观。(业务)愿景有助于战略规划,帮助所有相关利益方对组织或城市的长期发展重点达成共识,从而提高未来信息技术或建设投资的战略有效性。

4.2.4 (技术)景观

(技术)景观是具有不同范围和阶层的正式模型或图表,从技术角度描述了技术或城市景观。这些图对于架构师和城市规划师来说至关重要,但对于业务高管和城市管理者来说几乎毫无用处。例如,对于城市来说,景观图可以由描述地下高压电线、中央煤气和水管的基础设施图来表示;而对于组织而言,景观图通常由描述主要应用程序、系统、数据库及其连接的景观图来表示。图4.5显示了与(技术)景观相关的EA工件和城市规划文档的典型例子。

图4.5 与(技术)景观相关的EA工件和城市规划文档

(技术)景观代表了文档化的事实型EA工件(见表2.1和图2.7),因此可由个别架构师或城市规划师独立为组织或城市开发和维护。与总是由业务高管或城市管理者共同开发和批准的双重属性的(业务)愿景不同,景观图是纯粹的技术图表,主要关注技术或城市基础设施。它们通常被业务高管和城市管理者认为是毫无意义的技术废话,并不直接反映其任何战略关注。(业务)愿景通常着眼于未来,代表着积极主动规划工作的结果,而(技术)景观则更多是为了准确地捕捉当前技术或城市景观的“原有”状态。从本质上讲,它们提供了现有技术或城市基础设施的基线或清单。(技术)景观是永久的,并且与组织或城市共同演变。在(技术)景观发生变化后(例如,在新IT系统或建筑被建造或移除后),它们会以被动的方式更新,以保持最新状态。

(技术)景观主要由架构师或城市规划师使用,通常有几个不同的目的。首先,它有助于架构师或城市规划师了解哪些技术或城市基础设施是多余的、不适用的或老化的,并据此做出替换计划。其次,景观有助于准备单个IT或建筑项目的设计,并找到将新项目与现有基础设施连接的最佳方式。(技术)景观设计有助于技术或城市基础设施的合理化,重新利用现有资产,减少不必要的配套设施的重复使用,加速新IT系统或建筑的规划。

4.2.5 概要设计

概要设计是对单个IT或建筑项目的高阶描述,以便业务高管和城市管理者理解它们。它们为决策者提供了关于拟议的新IT系统或建筑的相关摘要信息,但不包含足够的技术细节来实际执行它。例如,对于城市来说,概要设计可用建筑模型来表示,显示建筑物的草图、总面积、大概成本和完工日期;而对于组织而言,概要设计通常用解决方案的概述来表示,描述建议的IT解决方案的本质、整体影响、估计成本、时间和风险。图4.6显示了与概要设计相关的EA工件和城市规划文档的典型例子。

图4.6 与概要设计相关的EA工件和城市规划文档

概要设计代表着规划决策,且总是由架构师和业务高管为所有拟议IT项目合作创建,或由城市的规划师和管理者为所有拟议建筑项目据其基本要求而创建。概要设计通常由(业务)愿景发起,以让由业务高管或城市管理者批准的整体战略落地。同时,其启动方式与“经营考量”一致,以便与商定的整个组织或城市的通用原则保持一致 。在制定概要设计时,架构师或城市规划师也会利用(技术)标准和(技术)景观来重复使用已有的最佳实践,并规划新的IT系统或建筑与现有基础设施的连接。由于其明确的双重属性(见图2.5),概要设计向业务高管或城市管理者传达的含义有别于向架构师或城市规划师所传达的含义。例如,图4.6所示的解决方案概述对于业务高管来说,描述了拟议的IT解决方案将如何影响业务、哪些业务流程将得到改善、需要哪些财务投资,以及何时可交付解决方案;而对于架构师而言,同样的解决方案概述提供了IT解决方案的高阶描述,若项目得到业务高管的批准,即需要交付。

在开发完成后,概要设计为IT或建筑项目的商业案例提供信息,并作为这些项目的主要讨论点。一方面,概要设计允许业务高管和城市管理者了解具体的IT系统或建筑的价值、时间表和成本,而无须深入了解实施的复杂技术细节。另一方面,基于概要设计,业务高管和城市管理者可确保所有拟议的IT或建筑项目与经营考量相一致,并与(业务)愿景中反映的总体战略方向保持一致。因此,概要设计有助于做出明智判断,并能对所有拟议项目的资金进行合理的决策。这帮助业务高管和城市管理者根据战术和战略利益的平衡来批准具体的IT或建筑项目,并确保资金得到合理使用。概要设计的性质是临时的和短暂的(见表2.2)。概要设计在IT或建筑项目的早期阶段被创建,用于支持决策,但在这些项目启动或被拒绝后即被丢弃。即使概要设计仅简单地提到技术或城市基础设施,但其双重属性使得业务高管和城市管理者能够控制所有的IT或建筑投资。概要设计有助于确保每个新IT或建筑项目以可承受的价格提供合理的战术和战略价值,最大化成本效益比,从而提高所有投资的效率。

4.2.6 详细设计

详细设计是对单独IT系统或建筑的细致技术描述,以供实施者操作。详细设计为IT或建筑专家提供了交付项目所需的精确技术信息,但对于业务高管和城市管理者来说,这些信息基本上无关紧要。例如,对于城市来说,详细设计可用正式的建筑图纸来表示,并对其几何形状进行精确测量;而对于组织而言,详细设计通常由解决方案设计来表示,详细描述IT系统的所有典型“层”,包括其应用、数据、技术和安全要素。图4.7显示了与详细设计相关的EA工件和城市规划文档的典型例子。

详细设计表示由架构师和IT项目团队为所有IT项目集体开发的技术规划决策,或表示由城市规划师和建筑项目团队为所有建筑项目开发的技术规划决策,其基础是此前由业务高管或城市管理者批准的相应概要设计 。详细设计提供了构建IT或建筑项目所需的详细且具体的技术信息,还精确地解释了新IT系统或建筑如何遵循(技术)标准规定的既定技术准则,以及新IT系统或建筑如何与(技术)景观中描述的现有基础设施相连接。由于其双重属性,详细设计向架构师或城市规划师传达了一种含义,而向IT或建筑项目团队传达另一种含义。例如,对于架构师来说,图4.7所示的解决方案设计描述了IT系统如何遵守既定的组织范围内的原则、标准和方法,重新利用适当的战略性IT资产,并废弃多余的、冗余的或遗留的系统;而对于IT项目团队而言,同样的解决方案设计也会详细说明对IT系统的业务要求以及具体实施计划。

在开发完成后,详细设计为各个项目的项目管理计划提供信息,并由负责按计划实施项目的IT或建筑团队使用。详细设计是临时性的,仅在各个项目的期限内有效。它们在IT或建筑项目的后期阶段产生,以支持其实施,但在这些项目交付后会被丢弃。尽管详细设计通常没有明确描述任何组织范围或城市范围的经营考量,但其双重属性使IT或建筑项目团队能默默地创建全面优化的IT系统或建筑。详细设计有助于保证单个IT系统或建筑的良好技术质量,并确保满足业务高管或城市管理者的所有基本要求。

图4.7 与详细设计相关的EA工件和城市规划文档 zK9CLBA0ReudbTuccffQk7MQdeJd6mtUbv34nC4Ua16Y5walRJIEyGMrVYy9CgKT

点击中间区域
呼出菜单
上一章
目录
下一章
×