搭建一个简易狗屋时,我们不会去设计三维图,做预算,规划施工等,而建个复杂建筑时,缺少架构是不可能能完成的。就像我们程序员做个小功能,可能都不需要做设计就可以实现了,但是当问题复杂了,考虑因素多了,产品关联复杂了,那么还一直摸着石头过河,事前不做架构不做规划,那么最终结果必然是失败的。
盖房屋需要架构,做功能需要技术架构,那么给企业做信息、业务规划就需要做企业架构,那我们如何描述企业架构呢?
架构复杂性
- 设计:
- 为了避免大家的误解,架构师设计时应该采用一种通用的、易于理解的一组词汇,这些词汇不能特定于单一架构领域。
- 提供通用的和组织特定的指导、最佳实践、架构图描述标准和其它能够提高架构质量的方法
- 架构时迭代、反复完成的一个过程,需要支持对架构决策的跟踪和变更管理
- 为了避免大家的误解,架构师设计时应该采用一种通用的、易于理解的一组词汇,这些词汇不能特定于单一架构领域。
- 沟通
- 架构需要同组织内或组织外的不同涉众(如管理人员、设计人员、合作伙伴等)进行沟通
- 能够对不同涉众关注的方面进行精确的描述
- 实现
- 从以往的架构中提供反馈
- 可能的话,还需要集成已存在的设计工具
- 变更
- 架构的变更对组织影响非常大,预先评估变更导致的一系列活动,仔细计划架构演进
4个架构视图
组织的业务流程的目的是实现他们的产品,软件应用是支持业务流程,而技术设施是运行应用,信息是在业务流程和应用中使用。
- 业务架构(business architecture):业务战略、组织结构以及业务流程
- 应用架构(application architecture): 服务、应用
- 信息架构(information architecture):业务对象和数据
- 基础设施架构(infrastructure architecture):硬件、网络和软件环境
模型
为了解决上面这些复杂性,明确的描述架构的核心模型是非常有价值的,而单一架构领域的细节可以不用定义(比如UI模型、主外键设定等),因为这属于特定专业的内容了。在《架构 - 又一个类似与“平台”一样的词汇》中描述了架构的一种定义是:架构是由软件元素、元素的外部可见属性以及它们之间的关系组成。
我们在描述架构时,最重要的就是关注核心元素以及它们之间的关系。在描述企业架构时,我们使用模型(models)。
- 领域(Domain):总体描述中的一个子集概念
- 模型(Model):一种聚焦特定领域内的抽象但很明确概念以及概念之间的关系,UML就是我们常见的一种描述模型的语言
- 建模(Modelling): 对总体概念的部分进行抽象描述的动作
基于符号和语义的模型(Symbolic and Semantic Models)
基于符号的模型
基于语义的模型
以后blog中,如果没有明确提出语义模型,都指符号模型。
架构描述基本概念
View和ViewPoint
没有哪个人会关心架构所有的范围和细节,我们需要针对不同的涉众提供符合他们关注点的特定视图。这里涉及到两个概念:
- ViewPoint: 视图模板,定义了如何看这个视图
- View: ViewPoint的实例,展现模型中的这个ViewPoint包含什么
下图为TOGAF的架构内容框架中的一张图,表明了元模型、View和ViewPoint的关系
建模语言:ArchiMate
企业架构的核心方法就是使用一种集成的、一致的方式来描述多个领域的概念,ArchiMate是一种图形化的企业架构语言,可以参考《架构 - 使用ArchiMate描述企业架构》