【发布时间】:2014-07-22 00:00:44
【问题描述】:
我阅读了一些 TOGAF 文档,看到很多地方提到了“架构”和“解决方案”。例如架构连续体和解决方案连续体、架构构建块和解决方案构建块。但我不太明白它们在 TOGAF 中有什么区别。
【问题讨论】:
标签: togaf
我阅读了一些 TOGAF 文档,看到很多地方提到了“架构”和“解决方案”。例如架构连续体和解决方案连续体、架构构建块和解决方案构建块。但我不太明白它们在 TOGAF 中有什么区别。
【问题讨论】:
标签: togaf
根据 Togaf 9 的 Togaf 文档:
架构 1. 系统的正式描述,或组件级别的系统详细计划,以 指导其实施(来源:ISO/IEC 42010: 2007)。 2. 组件的结构、相互关系以及原则和指南 随着时间的推移管理他们的设计和演变。
它没有提供 SOLUTION 的正式定义。
用外行的话来说,架构是解决方案的抽象视图。它可以是一个超集或一组解决方案。解决方案是问题的更具体表示,而架构则代表系统的更广泛图景。
【讨论】:
Enterprise Continuum 首次提到了两种不同类型的架构构建块,我们有架构连续体和解决方案连续体,我如何看待架构构建块与解决方案构建块之间的差异所以我会根据积木的思路来解释。
架构构建块:这假设是合乎逻辑的,假设是我们想要在组织内实现的概念的想法,这将指导和支持我们的解决方案空间,是的,正如您所阅读的那样ABB 将制定规则并就我们将如何在解决方案连续体(基础、公共系统、行业、组织)的相应级别创建解决方案提供一些指导。这种架构构建块无法部署,甚至不是物理的。
解决方案构建块:我们可以部署物理解决方案,这意味着解决方案可以在部署中实例化,该解决方案代表架构在架构连续体(基础,共同系统,行业,组织)。 我们可以构建或购买解决方案,在我们的组织中构建或从一些供应商处购买。
您可以看到一张很好的图片来描述这些概念之间的差异here。同样在我的回复中,我谈到了你可以看到更多关于这个概念的级别以及描述这个here.的好图片
希望对您有所帮助。
【讨论】:
如果您有编程背景,那么与“接口”及其“实现”进行类比可能是有意义的。在这种情况下,架构将是其实现的接口和解决方案。
将此类比为现实,架构师会设计一个解决方案并将其分解并分解为两个或多个组件(=抽象)。其中一个组件可能表示需要存储例如客户数据。因此,架构师会编写“保存客户数据所需的数据库”。这是建筑设计的一部分——抽象。
在未来的某个时候,架构师可能希望将其具体化。到时候他可能会写“一个Oracle RDBMS或者一个平面文件或者一个In-memory HSql数据库)作为它的具体实现。
【讨论】:
解决方案是可实现/已实现的组件,而架构是描述组件。两者都可以在不同的层次上表示。 卡提克
【讨论】: