架构师的十八般武艺:架构方法论
架构是关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计。听起来是一个很抽象的概念,大家可能希望有一些指导可以参考。这个就是架构方法论。架构方法论有很多,有 TOGAF、Zachman 等,其实本质上都大同小异。架构方法论,提供架构师架构设计的参考流程、常规的动作、标准的产出物,但是不会保证架构设计的交付质量。也就是说,架构方法论决定架构的下限,但不决定架构方案的上限。
Zachman
Zachman 更像一个架构方案的模版,指导架构师需要考虑的方面。
TOGAF
ADM
TOGAF 的核心是 Architecture Development Method(ADM),指导架构师架构设计的流程。
预备阶段
做架构之前,要先了解现状。
了解组织架构、了解在使用的架构框架/methodology、了解已有的架构资产。
Architecture Vision
定义 stakeholders、了解愿景、定义范围。
找准 stakeholders 很重要,架构需要有人买单(buying)。
架构要提现老板们的愿景。
架构要有问题范围,无限的就不是架构了。
问题要具体,比如 3+3、比如 0 配置、比如降低成本 XXbp。
业务架构
这个部分我们一直强调的很少。
业务也是需要架构师的。
组织架构(Organization structure)、功能(Functions)、服务(Services)、流程(Processes)、角色(Roles)、规则(Rules)、Use case,这些都是业务架构的产物。Maybe 这部分是 PD 要完成的范畴。
信息系统架构
这块可能是我们最熟悉的,但是这里又分成两部分:
数据架构(Data Architecture)
应用架构(Application Architeture)
数据架构描述实现业务架构需要的数据模型。数据模型分成概念模型、逻辑模型和物理模型。
数据架构还需要考虑数据安全和数据迁移。
应用架构我们很熟悉了。但是需要注意,应用架构不是单纯的模块图,需要提现应用之间的交互(应用间依赖关系,在业界有统一的 System Context 来定义)。
技术架构
信息系统架构的技术实现,在 18 摸,叫 Operational Model。
包括关系数据库、非关系数据库、缓存选型、软件采购;
还包括云/容器/物理机,网络、存储等。
管控
剩下的就比较虚了。
几点可以关注一下:
需要有从老架构到新架构的迁移方案;
需要对实现的管控;
需要有架构变更管理;
需要有需求管理。
Architecture Repository
TOGAF 里面特意定义了 Building Blocks、Artifacts,就是要有架构需要有 Repositoy 和传承。
对于 ADM,有如下的 metamodel 与之对应可供参考:
同时定义了 ADM 交付件中包括的 Artifacts,这里不详述。
Enterprise Continuum
取长补短,不断完善 Architecture Repository。
版权声明: 本文为 InfoQ 作者【agnostic】的原创文章。
原文链接:【http://xie.infoq.cn/article/c5904e09f258acd42bb1bddb6】。文章转载请联系作者。
评论