企业架构的定义
什么是企业架构?
企业架构是对组织基本要素的整体、分层和抽象描述,以随着时间的推移最大化股东价值。 [1]
企业架构将 IT 战略转变为切实的 IT 解决方案。 IT 治理指导企业架构规划。
企业架构的基本要素
企业架构的基本要素[2]
企业架构定义中的关键方面:(如果企业架构实现了这些点,它就已经履行了它的义务,并成为在组织中创造和传达价值的工具。构建它的过程称为企业架构规划 这包括它在 IT 治理及其自身治理中的使用。)
- 企业架构是整体的:企业架构规划的范围是从上到下,从左到右,即它跨越整个组织及其所有维度。然而,这并不意味着“此时此地”,即企业架构可以 - 应该而且必须 - 逐个构建 - 逐个构建,而不是一次全部构建。
- 企业架构是分层的:企业体系结构按照概括的层次或程度进行分层——从逻辑到物理,以及介于两者之间的一切。
- 企业架构是抽象的:企业架构描述了企业的逻辑,即它是组织的逻辑表示。通过层,这种逻辑描述被翻译成物理的——人、系统、网络等——必须构建以支持企业运营的组件。另一种看待这一点的方式是,企业架构将组织战略转化为运营。
- 企业架构是描述性的:企业架构是组织的书面表示。它通过详细说明组织的各个部分及其相互之间的关系来传达组织的本质
- 企业架构涵盖了本质:简单地说:企业架构远离仅仅有趣的事物,而专注于相关的事物。企业架构的目的是帮助了解地形——而不是覆盖每一片草地——这样人们就可以有效地驾驭它。对什么至关重要?为企业创造价值必不可少。必不可少,因此可以为 IT 降压创造最大的收益。
- 企业架构描述了组织的元素:企业架构描述了组织特征的部分或方面——它们一起描述了组织的本质。这些描述是具体的,因此,它们有助于沟通、消除冗余并创建必须遵循的标准。
- 企业架构是关于一个组织的:企业架构描述了一个组织——为某个目的或目标而形成的一组人员、流程和技术。
- 企业架构提供股东价值:企业架构有一个目的 - 可悲,但真实! - 那就是提供商业价值。当企业架构师忘记一切都与商业价值有关时,他们就会失败——漂亮的图表可以让你忙上好几年,但你的薪水是为了向股东提供价值。
- 企业架构是迭代的:企业架构是随着时间的推移逐步构建的——一次一个域。企业架构的层也随着时间的推移而发展。企业架构需要不断改进,因为没有任何业务在静止的环境中运行。
- 企业架构随着时间的推移描述组织:企业架构随着时间的推移映射组织的旅程,从它所在的位置到它需要达到的位置,以提供最大的业务价值。根据定义,这是一个无尽的旅程。
企业架构定义
企业架构定义[3]
以下是一些企业架构定义的示例。 每个都有有助于理解企业架构的元素,但他们是否错过了完全回答这个问题的关键方面:什么是企业架构? 您根据以上决定
- 1. ANSI/IEEE Std 1471-2000:“系统的基本组织,体现在其组件、它们与彼此和环境的关系,以及控制其设计和发展的原则。”
- 2. Cap Gemini:“企业架构是对给定考虑领域结构的描述和可视化,其元素及其协作和相互关系将愿景、战略和可行性联系起来,重点关注可用性、耐久性和有效性。架构支持构建,定义原则、规则、标准和指南,表达和传达愿景”
- 3. Forrester,Gene Leganza,2001 年:“企业架构由指导企业内技术购买和部署的愿景、原则和标准组成”
- 4. Gartner Group:“企业架构 (EA) 是通过创建、交流和改进描述企业未来状态并推动其发展的关键原则和模型,将业务愿景和战略转化为有效企业变革的过程。”
- 5. Gartner Group,Philip Allega:“企业架构是将业务和 IT 交织在一起的过程”
- 6. 企业架构发展研究所:“企业架构是关于理解构成企业的所有不同元素以及这些元素如何相互关联”
- 7.MIT 信息系统研究中心:“企业架构是关键业务流程和 IT 能力的组织逻辑,反映了公司运营模式的集成和标准化要求。”
- 8. ArchiMate 基金会:“用于设计和实现企业组织结构、业务流程、信息系统和基础设施的一整套原则、方法和模型”
- 9. The Open Group:“通过与所有其他管理框架的包容性,EA 是一门帮助企业定义、开发和利用无边界信息流 (BIF*) 能力以实现企业战略意图的学科。” *无边界信息流是 The Open Group 的商标
- 10.美国联邦企业架构框架 (FEAF):“企业架构是一种管理实践,旨在最大限度地利用机构的资源、IT 投资和系统开发活动来实现其绩效目标。架构描述了从战略目标和目标到整个企业或企业的一部分(或部分)的可衡量绩效改进的清晰关系”
企业架构的上下文图
Figure 1. source: EITBOK Wiki
企业架构的演进
企业架构演进[4]
需要 EA 的原因有两个:
- 第一个原因是技术驱动的。由于计算环境中的额外规模、多样性和连接性,分布式计算在 1980 年代的到来导致 EIT 复杂性增加。这种额外的复杂性导致 EIT 开发、支持和运营成本显着增加。随着成本的上升,来自管理层的压力要求减缓企业所得税预算的增长并提高企业所得税支持的业务效率。 “事半功倍”的指令和提高效率和有效性的无情压力需要新的企业所得税战略方法。在某种程度上,整合、标准化和商品化是企业所得税费用削减策略;然而,它们的有效性存在局限性,因为它们仍然缺乏对业务角色和流程、信息数据元素和流、支持应用程序系统和底层技术基础设施之间的联系的全面和系统的理解。
- EA 的第二个动机是业务驱动,因为外部变化的步伐不断加快,加上许多组织难以成功执行其业务战略。 Michael Porter 估计,超过 80% 的组织未能执行其业务战略,而无效的执行是超过 70% 的失败的原因。 EA 中的原则和实践帮助企业经理将他们的组织从他们现在的位置转移到他们想要的位置。
根据是否仅出于基于技术或基于业务战略的原因来看待 EA,EA 的范围会有所不同,包括其关注点、假设和限制。 James Lapalme 提出了对 EA 定义范围最有说服力的分析之一,他描述了 EA 的三种思想流派:
- 企业范围的 IT 平台——通过 EIT 有效地执行和运营企业战略 - 业务对齐)
- 企业整合——通过执行连贯性有效地实施企业战略
- 环境中的企业——通过组织学习进行创新和适应
Nick Malik 以 Lapalme 的三所学校为基础,描述了三类 EA 应用程序:
- 企业 IT 架构 — 设计 EIT 服务并创建满足企业需求的 EIT 系统
- 企业整合——使业务与其所有能力保持一致,包括 EIT;使用能力分析来了解战略对业务流程和系统的影响,并帮助制定应该创建的计划,并确保在正确的地方进行投资
- 企业生态适应——分析市场动向,与企业领导者密切合作,根据企业的能力和定位,制定可能产生新收入、提高市场地位、提高客户忠诚度和降低成本的战略
EA 可以服务于许多不同的目标(图 3 的纵轴),并且可以为一系列时间范围和企业价值(横轴)提供方向和支持。区分组织需要和想要建立的 EA 类型很重要。通过这样做,EA 和业务主管在执行其业务战略时的界限和交接变得清晰。如果没有这种明确性,可能会产生持续的混乱以及协作和协调方面的问题。 EA 从业者有三个基本假设:
- 企业与企业IT的统一是通过企业IT与企业的统一来实现的。
- 企业的敏捷性是 EIT 职能敏捷性的结果。
- EA 的变革价值通常是通过转变应用程序和技术架构来实现的。 EA 计划产生的变化量在业务层可能很小,但通常会随着设计越来越接近应用程序和系统的细节而增加。
企业架构的范围
企业架构的范围[5]
企业架构的范围确定了它需要解决的范围或程度。 范围有几个维度。
- 企业架构时间范围确定了计划时间范围。通常,这是三到五年,并且与大型组织的预算规划周期相吻合。
- 企业架构组织范围包括组织的那些部分及其业务流程、数据和 IT 将在工作中涵盖。理想情况下,整个组织都得到解决。在某些情况下,该架构涉及多个组织的合作伙伴关系,以完成共同的使命。 EA 工作可能会根据可用资源以及不断变化的业务战略和投资需求,在不同的企业架构阶段强调组织的不同部分。
- 详细程度范围决定了企业架构中需要包含多少细节。有几个因素需要考虑。企业架构应该包含足够的细节来制定主要投资及其生命周期和预计成本。企业架构应该包括足够的细节,以证明企业战略在所需的时间范围内得到企业架构的支持。企业架构应该显示足够的细节,以确保组织之间和 IT 系统之间的所需接口得到充分说明。企业架构应该为正在开发设计和规范以实施特定投资的系统工程师提供足够的指导。另一方面,EA 不应过于详细,以免过度约束企业。它应该足够通用,以便在系统设计决策中提供自由度并响应技术变化。总之,企业架构应该足够详细和具体,以约束和指导战略决策,而不是过度约束战术决策。
企业架构组件
企业架构组件[6]
企业架构组件包括:
- 商业信息系统:商业信息系统是通过元数据库管理的基于计算机的商业信息系统。它以其特征、操作周期(业务和日历)、从属业务信息系统、使用的数据库、视图和相关的资源生命周期节点而闻名。
- 数据库域:数据库域是一组分层组织的名词密集型描述,与任务叶相关联。分析的数据库域导致识别数据库对象类、企业数据元素和属性类。反过来,属性类通常会成为数据库中的表。
- 数据库对象类:数据库对象类是大量数据和流程的集合,这些数据和流程出于基于业务的原因而联系在一起,并且在实例化时会通过明确定义的状态进行。数据库对象可以以两种形式存在:相互关联的数据库表的集合,或表中基于列的嵌套结构的集合。构成对象的行通过数据库对象表进程和数据库对象信息系统从一种有效状态转换为另一种有效状态。数据库对象与一个或多个数据库域相关。
- 数据库对象信息系统:数据库对象信息系统是在 DBMS 域中定义的过程的集合,通常作为存储过程,将数据库对象的一行或多行从一种有效状态转换为另一种有效状态。数据库对象信息系统完成一个或多个数据库对象表处理。
- 管理级别:管理级别是组织环境中命名和定义的官僚管理级别。示例可以是高管、高级、中级和一级。
- 使命:使命是分层组织的文本描述,定义了企业的存在,并且是从不同业务职能和组织内衡量企业成就的最终目标和目标。如果一个企业的使命之一没有被定义,那么它就是不完整的。并非所有企业都同时或在理想状态下完成任务。任务是随着时间的推移完成的,并且可能会进行修订。
- 执行任务的组织:执行任务的组织,即任务-组织是组织与任务的关联。可以有多个组织与一个任务相关联,并且一个组织可以与多个任务相关联。 Mission-Organization 中包含的描述可能比任务或组织中包含的描述更精确。
- 完成职能的组织:完成一项职能以支持使命的组织,即使命-组织-职能是使命组织与职能的关联。一个任务组织可以与多个职能相关联,一个职能可以与多个任务组织相关联。一个或多个任务组织功能可以与商业信息系统相关联。当它们存在时,就会创建业务事件。
- 职位:职位是可以由或更多人执行的命名和定义的工作任务集合。职位通常分配给一个或多个组织。
- 执行任务的职位:任务组织职能职位角色是在组织完成任务时将职位分配给组织内的特定职能。一旦分配了职位,就可以描述其角色。
- 资源生命周期分析节点:资源生命周期节点是资源内的生命周期状态。如果资源是员工,则生命周期节点可以是员工申请、员工候选人、员工新员工、分配员工、审核员工和离职员工。
- 资源:资源是对企业有价值的持久资产。例如包括设施、资产、员工、金钱,甚至像声誉这样的抽象概念。如果缺少资源,则企业是不完整的。
企业架构领域
企业架构域(图 2.)[7]
在 1980 年代,系统设计人员开始使用系统架构的四层划分。该架构分为技术、应用程序、信息和业务领域。堆栈中较高的域建立在较低层之上并依赖于较低层。一些企业架构框架将企业架构的实践分解为多个实践领域或“领域”(也称为视点、层或方面)。将实践划分为多个领域允许企业架构师从多个重要角度描述企业,将描述性任务分配给许多参与者,并允许整个实践充分利用各个领域特定的专业知识和知识.通过采用这种方法,企业架构师可以确保生成对企业设计的整体描述。
至少有两个领域,“业务建模”和“当前系统和技术”,可以进一步细分为“数据架构”、“应用程序架构”和“技术架构”。
流行的TOGAF框架将实践分为“业务架构”、“信息系统架构”和“技术架构”三个领域,然后将信息系统架构细分为“信息架构”和“应用架构”。
战略架构模型允许灵活划分为多达十个领域,涵盖企业的许多方面,从其目标和目标到其项目和程序,再到其软件应用程序和技术。
Figure 2. source: Modeliosoft
企业架构原则
企业架构原则[8]
企业架构原则是指导业务信息管理、信息技术 (IT) 决策和活动的基本价值观的高级陈述,是业务和 IT 架构、标准和政策制定的基础。这些原则是一般规则和指导方针,随着企业重新调整其目标和使命,可能会进行调整。但是,它们旨在持久且不易频繁修改。遵守这些原则可以加强决策和业务案例。例如,如果两个解决方案开发项目之间存在利益冲突,那么这些原则应该指导决策制定。如果提议的更改不符合这些原则,则应根据这些原则重新调整更改。原则建立在所有企业架构领域:
商业原则——为整个企业的决策提供基础
- 原则 1——原则至上
- 原则 2 – 遵守法定义务
- 原则 3 – 为企业带来最大利益
- 原则 4 – 信息管理是每个人的事
- 原则 5 – 业务连续性
- 原则 6 – 常用应用
- 原则 7 – IT 责任
数据原则 - 提供企业内部数据使用的指导
- 原则 8 – 数据安全
- 原则 9 – 数据是一种资产
- 原则 10 – 数据共享
- 原则 11 – 数据是可访问的
- 原则 12 – 数据受托人
- 原则 17 – 数据是可分析的
应用原则 - 为所有 IT 应用程序的使用和开发提供指导
- 原则 13 – 技术独立
- 原则 14 – 易用性
- 原则 18 – 购买而不是开发
技术原则 - 为所有 IT 技术的使用和开发提供指导
- 原则 15 – 基于需求的变更
- 原则 16 – 控制技术多样性
企业架构框架
企业架构框架(图 3.)[9]
企业架构框架 (EAF) 映射了企业内的所有软件开发流程,以及它们如何关联和交互以完成企业的使命。它使组织能够理解和分析要识别和解决的弱点或不一致之处。今天有许多已经建立的电弧炉在使用;其中一些框架是为非常特定的领域开发的,而另一些则具有更广泛的功能。今天有许多架构和架构框架在使用。尽管它们可能重叠或处理相似的观点,但框架也被设计用于解决特定的需求或关注点。以下是最常用的五种电弧炉的简明描述:
- Zachman 企业架构框架:John Zachman 于 1987 年发布了 Zachman 企业架构框架,被认为是该领域的先驱之一。根据 Zachman 的说法,“信息系统实施的设计范围和复杂程度的增加正在迫使使用一些逻辑结构(或架构)。” Zachman 框架基于经典架构的原则,这些原则建立了一个通用词汇表和一组用于描述复杂企业系统的视角。 Zachman 框架有六个视角或视图:Planner、Owner、Designer、Builder、Subcontractor 和 User。扎克曼框架的第二个维度涉及六个基本问题:什么、如何、在哪里、谁、何时以及为什么。该框架不提供关于顺序、过程或实施的指导,而是侧重于确保所有视图都得到良好建立,确保一个完整的系统,无论它们建立的顺序如何。 Zachman 框架没有明确的合规规则,因为它不是由专业组织编写或为专业组织编写的标准。但是,如果完整使用并遵循所有关系规则,则可以假设合规。
- 国防部架构框架 (DoDAF):国防部架构框架 (DoDAF) 建立在三组“视图”之上:运营、系统和技术标准。第四个视图,“所有视图”,通过提供视图之间的链接来增强其他视图,通过字典来定义术语并提供上下文、摘要或概述级别信息。该框架提供了对最终产品的描述以及一致性的指导和规则。这确保了“用于比较和集成系统系列、系统系统以及互操作和交互架构的共同点”。
- 联邦企业架构框架 (FEA):联邦企业架构框架由美国联邦首席信息官 (CIO) 委员会开发和发布。政府正在追随定义架构框架以指导大型复杂系统开发的行业趋势。 FEAF 是对 1996 年 Clinger-Cohen 法案的回应,该法案要求联邦机构 CIO 开发、维护和促进集成系统架构。 FEAF 的首要目标是为整个联邦政府组织和促进联邦信息的共享。架构部分是在结构化的指导方针下单独开发的,每个部分都被认为是联邦企业中自己的企业。 FEA 允许各联邦机构灵活使用方法、工作产品和工具。
- 财政部企业架构框架 (TEAF):财政部于 2000 年 7 月发布了财政部企业架构框架 (TEAF)。财政部由多个作为个体企业运作的办公室组成。因此,其企业架构需要映射组织之间的相互关系,以便管理 IT 资源。 TEAF 旨在促进“跨部门的整合、信息共享和共同需求的利用”。与 DoDAF 类似,TEAF 包括用于记录和建模企业架构的工作产品的描述。 TEAF 还明确声明这些工作产品与 FEAF 模型和 DoDAF 产品一致。
- 开放组架构框架 (TOGAF):开放组架构框架 (TOGAF) 于 1995 年首次开发,基于国防部的信息管理技术架构框架。 TOGAF 专注于使用开放系统构建块的任务关键型业务应用程序。 “TOGAF 的一个关键要素是架构开发方法 (ADM),它指定了开发企业架构的过程”。 TOGAF 解释了制定良好原则的规则,而不是提供一套架构原则。三个层次的原则支持整个企业的决策;提供 IT 资源的指导;并支持开发和实施的架构原则。
企业架构框架 - 视图/视角比较
Figure 3. source: Eastern Michigan University
企业架构的好处
企业架构的好处[10]
企业架构的好处是通过其对组织目标的直接和间接贡献来实现的。已经发现,企业架构最显着的好处可以在以下几个方面观察到:
- 组织设计——企业架构在合并、收购或一般组织变革期间为与组织结构的设计和重新设计相关的领域提供支持。
- 组织流程和流程标准——企业架构有助于加强业务流程的纪律和标准化,并支持流程整合、重用和集成。
- 项目组合管理 (PPM) - 企业架构支持投资决策和工作优先级。
- 项目管理——企业架构增强了项目利益相关者之间的协作和沟通。企业架构有助于有效的项目范围界定,并有助于定义更完整和一致的项目可交付成果。
- 需求工程——企业架构通过发布企业架构文档来提高需求获取的速度和需求定义的准确性。
- 系统开发 - 企业架构有助于在系统开发和测试期间优化系统设计和高效资源分配。
- IT 管理和决策制定——企业架构有助于加强 IT 规划活动的纪律和标准化,并有助于缩短与技术相关的决策制定时间。
- IT_Value - 企业架构有助于降低系统的实施和运营成本,并最大限度地减少跨业务部门的 IT 基础设施服务的复制。
- IT 复杂性 - 企业架构有助于降低 IT 复杂性、整合数据和应用程序,以及提高系统的互操作性。
- IT 开放性——企业架构有助于提高 IT 的开放性和响应速度,这体现在增加了数据的可访问性以实现法规遵从性,以及提高了基础设施变更的透明度。
- IT 风险管理——企业架构有助于降低系统故障和安全漏洞带来的业务风险。企业架构有助于降低项目交付的风险。
企业架构挑战
企业架构挑战[11]
- 适合目的。将 EA 作为一门学科的一致定义和理解增加了挑战。大多数组织都支持 EA 来“修复”一个组织,而不给它任何目的。通常,顾问/承包商在证明帆船可以漂浮之前就试图出售 EA 的泰坦尼克号。这通常会导致客户烦恼,并导致 EA 被视为货架软件。
- 高级管理人员支持并持续关注和支持 EA 计划。这就像鸡和蛋的问题。如果 EA 能够提供价值,高管将得到持续的支持,但 EA 需要持续的高管支持来展示价值。 EA 所在的领域是您找不到太多快速获胜的领域。此外,成功的 EA 往往会导致企业文化发生变化。如果没有强有力的高级管理人员的承诺,企业文化变革就不会发生。许多人认为时间和金钱被浪费了,直到他们开始看到结果。
- 了解管理和所有权的差异。 EA 经常试图获得业务流程的所有权并最终受到指责。 EA 是实践战略 EA 领导力和运营管理的管家 --> 执行与战略的一致性对于 EA 的成功至关重要。
- EA 成熟度:EA 参与模型和治理。这针对公司流程、政治和人员问题。如果 EA 参与和治理模型效率不高,企业架构对很多人和项目来说只是一个沉重的负担。不知何故,分散的 EA 参与模型和治理流程在工作场所非常普遍。精简似乎需要很长时间。换句话说,内部治理和合规性极为重要。
- 组织成熟度。成熟的组织是启动成功 EA 计划的基础;另一方面,有效的 EA 程序可以提高组织成熟度。当组织不准备这样做时,太多的组织试图建立 EA 程序。通常,领导层听到或得到了 EA 将挽救局面的说法,他们启动了一个程序,而不支持该程序,认为“做”EA 会解决所有问题。 EA 需要广泛的准备和积极的参与。
- 业务/架构对齐 --> 这必须由 EA 团队赢得,不应被视为空白支票或权利,因为这需要关系管理和交付透明度以匹配业务优先级。 PMO 和架构团队对于赢得和建立信任至关重要。
- 从以供应商/集团/机构为中心的 EA 转变为以客户为中心的 EA。从仅仅是 DNA 或“企业基因型”(企业工件的完整命名法)到提供与“企业表型”(一组可观察的特征,如绩效)和业务生态系统的正式联系。
- 不断地与“战术项目节省”与“可持续战略优势”的争论相提并论……(项目团队目标与架构团队目标的经典错位!)。开始太大,以至于 EA 计划没有像最初预期的那样取得成功。从小处着手并产生结果以赢得信任非常重要。规划和优先考虑一些快速的胜利,以展示完整的 EA 可以为企业带来哪些变化。虽然这非常困难,因为它有时会适得其反。尽管如此,EA 仍需要证明可直接量化的 ($$$) 价值 - 对公司底线的贡献或直接节省的成本
- 成熟的EA团队:EA团队不仅相信框架和技术,而且有能力随身携带业务,并且拥有厚脸皮在政治和政策中航行的员工。此外,这不是关于“首席架构师”,而是关于架构师/支持人员团队,一个成熟的 EA 团队。
- EA 技能/才能:架构其说是科学,不如说是一门艺术,需要的技能多于认证。 Enterprise Architect 需要广泛的知识,包括业务领域知识、技术项目管理经验和组织技能。有很多渠道可以让企业架构师成熟。具有不同成熟路径的企业架构师可能会看到同一个组织面临截然不同的挑战。
See Also
- Enterprise Architecture Framework
- Enterprise Architecture Management (EAM)
- Enterprise Architecture Value Framework (EAVF)
- Business Systems Planning (BSP)
- Zachman Framework
- Federal Enterprise Architecture Framework (FEA)
- Department of Defense Architecture Framework (DoDAF)
- The Open Group Architecture Framework (TOGAF)
- IT Capability
- IT Strategy Framework
- IT Transformation
- Application Architecture
- Business Architecture
- Architected, Model-Driven Development (AMD)
- Architected Rapid Application Development (ARAD)
- Architectural Pattern
- Architectural Principles
- Risks in Architecture
- Architectural Style
- Architecture Description Language (ADL)
- Architecture Development Method (ADM)
- Architecture Driven Modernization
- Architecture Tradeoff Analysis Method (ATAM)
- Enterprise Architecture Governance
References
- ↑ Definition of Enterprise Architecture by Sourabh Hajela of CIO Index
- ↑ Essential Elements of Enterprise Architecture based on Sourabh Hajela's Definition of Enterprise Architecture
- ↑ 10 Definitions of Enterprise Architecture Aris
- ↑ Evolution of Enterprise Architecture EITBOK Wiki
- ↑ The Scope of Enterprise Architecture EABOK
- ↑ What are the Components of Enterprise Architecture? Michael M. Gorman
- ↑ Enterprise Architecture Domains Modeliosoft
- ↑ Enterprise Architecture Principles Plymouth University
- ↑ Enterprise Architecture Frameworks Lise Urbaczewski, Stevan Mrdalj, Eastern Michigan University
- ↑ Benefits of Enterprise Architecture Wikipedia
- ↑ Top Ten Enterprise Architecture Challenges Future of CIO
Further Reading
- A timeline of key enterprise architecture events Bespoke
- Two IT gurus face off on value of enterprise architecture frameworks Techtarget
- On Layers of Enterprise Architecture Tetradian
- The Place of Business Architecture within Enterprise Architecture Daniel Lambert
- Why enterprise architecture maximizes organizational value Peter B. Nichol
- Enterprise architecture tools: Fake and real Svyatoslav Kotusev
- 登录 发表评论