企业架构设计方法论

2,904 阅读16分钟

写了几年代码,发现写代码的能力好像越来越不是那么重要,或者开发能力好像重要性低了一些。技术人员喜欢追求技术深度,技术深度虽然也很重要,但是工作中关于技术上考虑的可用性,可扩展性,稳定性等有流程保证,中间件团队在攻克这些问题,有专门的同学在攻克技术的难题。

会写代码,技术源码熟记于心,自己负责的业务指标也未必会见长。

  • 纯碎的写业务代码,满足业务需求,好像自己的主业就会有所生疏。
  • 如果是想研究源码,技术深度,工作中延误了业务需求,就有点折本琢磨。

技术也要进步,业务也要发展,作为业务开发,新的方向是什么?

在工作中听到老板说要做架构师,每个同学对自己都要有架构师的要求,自己也是很早就听到过架构师这个词汇,架构师和开发人员有什么区别? 我们做什么才能成为架构师?

浏览了一些资料,发现TOGAF(The Open Group Architecture Framwork)挺接近当前的工作状况,也给自己的疑惑提供了一些参考。这里将框架的内容做一些梳理,也希望能对读者也有所帮助。

问题

开始之前,心中有几个想要回答的问题:

什么是架构师?

架构师是做什么的?

开发的下一方向是架构师?

如何画架构图? 看到一些同学画图功夫了得,画图的能力也是想学一学。

基本概念

TOGAF是企业架构的一种,了解TOGAF首先要知道什么是企业架构,以及架构是什么。

什么是企业架构?

企业架构主要关注业务架构与IT架构,是企业用于实现业务战略的IT的总体规划设计工具。

为什么需要架构?

搭建简易狗窝不需要架构,但是搭建大厦必须需要经过设计阶段,对于不复杂的东西,怎么做都不会出差错,但是一旦业务复杂,规则复杂,还涉及变革时,必须有一个清晰的架构才能保证做出来的东西是正确的。

企业架构的目的是在整个企业范围内优化通常分散的流程(手动和自动)遗留到一个集成环境中,该环境响应变化并支持业务战略的交付。

企业高层们都知道,有效管理和利用信息以及数字化转型是企业成功的关键因素,也是获得竞争优势不可或缺的手段。企业架构通过为数字能力的演变和范围提供战略环境来满足这一需求,以响应业务环境不断变化的需求。

例如,社交媒体、物联网、云计算的快速发展,从根本上扩展了企业创造新市场机会的能力。

此外,良好的企业架构使您能够在业务转型和持续运营效率之间取得适当的平衡。 它允许各个业务部门在追求不断发展的业务目标和竞争优势的过程中安全地进行创新。同时,企业架构使组织的需求能够通过集成战略得到满足,从而在企业内外实现最密切的协同作用。

简言之:企业架构可以为企业带来价值

  • 提升业务与IT效率
  • 降低未来的风险

什么是TOGAF?

  • TOGAF 标准是通过整个社区的共同努力制定的,可以开放使用
  • TOGAF是目前最流行的企业架构框架,并且一直在维护中
  • TOGAF框架可以帮助企业快速有效性的实施IT战略

TOGAF结构

上面知道了企业架构是实现业务战略的IT规划设计工具,是从能力到目标之间的一个设计过程。那么TOGAF是如何设计的?官方给了一张参考图:

  • 业务需求决定了业务上要具备哪些能力
  • 业务运营通过学习业务能力,提出新的能力需求
  • 在业务目标和业务能力之间,TOGAF的主要结构:
  • 架构能力:关注人; 有没有架构师?大家的架构能力如何?有没有人员具备架构能力?
  • 架构方法:关注方法论; 架构设计的标准流程,标准方法是什么?有没有一些参考?
  • 架构产出内容:关注最终结果; 架构设计的输出内容是什么?架构设计的结果有哪些?
  • 架构演化:关注过程; 不同发展阶段的企业或者架构应该是什么形态,针对每种形态的企业应该如何做?

下面依次介绍TOGAF结构中的主要模块:

架构能力框架-组织阵营

为确保架构功能在企业中能够被成功运用,企业需要通过建立适当的组织结构、流程、角色、责任和技能来实现其自身的企业架构能力。

能力框架,对应到真实的场景中,我理解它就是组织阵营,人员分配;如果只有自己一个人,也不存在能力的框架。在项目组有一定规模的时候,怎么分配大家的角色才是最高效的,最有助于业务实现目标的。

官方提出了一些基本元素:

  • 培训:技能、知识培训
  • 不同的角色和责任:如PM,一线开发,专门的架构师
  • 不同的项目与项目成员:角色为项目服务,参与到项目中。 项目与项目成员通过契约在一起。(比如设置某个人为业务owner,为结果负责)
  • 业务运营:给项目提需求,输入业务优先级;而项目为运营交付解决方案。

项目与项目成员是核心,即架构能力中人是核心。

架构开发方法-ADM(Architecture Development Method)

TOGAF ADM(Architecture Development Method) 是大量架构从业者不断贡献的结果,它描述了一种开发和管理企业架构生命周期的方法,是TOGAF标准的核心。

  • ADM是用来指导企业如何建立和维护其企业架构的一套流程化的架构开发步骤;
  • ADM采用了自上而下的原则通过逐步细化的方式将企业高层的策略过渡到详细的技术实施,从而涵盖所有干系人角度的企业架构
  • ADM将架构过程看做是一个循环迭代的过程,并且此迭代是可以分层级的,即企业可以使用一个小组负责整个企业架构的迭代开发,也可以由多个架构小组针对每一部分进行开发,并最终归为一体。

架构生命周期

1、ADM架构工作由需求进行驱动,需求管理贯穿整个架构生命周期。

2、ADM一共有8个标准的阶段,每个阶段都有该阶段具体的:目的、输入、输出、步骤、和方法。 可根据ADM中参考步骤和方法进行架构工作。输入输出,其也有具体指定。

3、ADM是通用的架构开发方法,但是实际中可以进行扩展或者裁剪相关的阶段适应特定企业的需要。

架构阶段结构

ADM划分了8个阶段,每个阶段都有相同的结构,每个阶段,官方都给出了一些要进行的输入,输出,目标以及步骤,让我们明确要做什么事情。 另外在工作中也可以问自己:

  • 我当前处于架构的那个阶段?
  • 当前阶段的目标是什么?每一步应该是什么?要寻求那些输入?要有什么产出?

下图为架构生命周期的预备阶段:当前阶段的目标,做事的步骤,寻求那些输入,输出什么内容?

每一阶段详细官方都有详细的描述,可参考:pubs.opengroup.org/architectur…

调整&定制ADM

ADM是一种架构开发的通用方法,它是用来处理大多数系统和组织情况的,一些场景未必完全适合,中小企业、团队可对其进行裁剪,适应较低的资源和复杂度水平

实际应用ADM过程中,也未必要严格的按照其顺序一步步来,官方列出了几种可能的情况:

  • 项目团队贯穿整个ADM周期进行迭代,按照标准化方法进行
  • 多个项目团队可以并行的开展各自的ADM周期,中间保持一定的联系。一个架构团队可以对另外一个团队提出架构工作请求
  • 项目在ADM的某几个阶段,不断进行迭代,有计划的进行循环;也可以在某个阶段时,退回最开始的阶段,进行信息的更新。

业务架构&IT架构

因为这里讲的是架构开发方法,最重要的主要是对架构的描述,在ADM中有4种类型的架构(业务、数据、应用、技术)架构,又可细分为业务架构与IT架构(其中数据架构、应用架构、技术架构可以统一看做为IT架构)。在ADM中架构定义如下:

  • 业务架构: 定义了企业战略,管理,组织和主要的业务流程。
  • 数据架构: 基于业务架构,从系统数据的角度去准确定义数据分类,数据来源以及数据部署,以实现数据的标准化、一致性、准确性和可靠性,充分发现和挖掘数据价值。
  • 应用架构: 从系统需求的角度清晰准确的定义应用范围,功能及模块等,它们之间的相互作用,以及它们的关系
  • 技术架构: 从系统实现的角度提出系统总体的技术实现方案,描述了需要支持的业务,数据和应用服务部署的逻辑软件和硬件的能力; 这包括 IT 基础设施、中间件、网络、通信、处理、标准等。

通过下图对业务架构与技术架构的关系可以有比较清晰的认识

业务架构决定了我们要做哪些事,为什么要做这些事情,做那些做有效果?

IT是做这些事情需要的数据,技术,应用有哪些,怎么去支撑目标。

感觉技术架构更像是一种工具存在,所以呢技术人员不仅要懂IT架构,还要懂的业务架构,才能更好的支撑企业的战略目标。

关于架构,这里还有一些概念定义可以参考:

什么是业务架构?

业务架构是企业治理结构、商业能力与价值流的正式蓝图。

业务架构明确定义企业的治理结构、业务能力、业务流程、业务数据。其中,业务能力定义企业做什么,业务流程定义企业怎么做。

业务架构就是对企业的业务流程,进行根本性的再思考和在思考的彻底性再设计,从而获得成本、质量、速度等方面业绩的巨大的改善或提高。


业务架构是从战略到实施过渡的桥梁;

万般需求皆业务,万般业务皆流程;管理无止境,流程出效益;


什么是应用架构:

应用架构描述了设计和构建应用的模式与技术。该架构可以为您提供构建应用时应遵循的路线图和最佳实践,帮助您构建一个结构合理的应用。

IT架构就是企业方向设计好了,谁来干,怎么干,用多少人,花多少钱,用哪些技术,收益多大,要花多少时间实现...这些方方面面在做事之前就定好规矩了,但具体执行过程中发现或遇到什么问题那就不关架构的事了,因为定规矩时没人说那就被认为一切是认可的,架构只在执行过程中具有指导和把握方向的作用。IT部门的每个成员的都会以不同的职责参与进来。

架构原则

在进行架构设计的过程中,有一些要遵守或者进行决策的依据,可以提前指定出来作为参考,在制定原则时,一般考虑如下因素:

  • 企业的使命和愿景:
  • 企业的战略计划:企业的优势,劣势,机会和威胁。
  • 外部约束:市场因素,法律因素
  • 当下的系统和技术,未来的趋势:金融,政治,技术和市场未来的走向。

官方也提供了一些原则参考:pubs.opengroup.org/architectur…

相关方管理

在ADM中,技术是其中的一部分,除了技术之外,想要把事情做成,还有一些软性的素质在架构中需要具备。怎么让相关人员支持项目,让项目能进行下去。

在架构从开始到结束阶段,识别出哪些人,团队可以对项目的进展会有贡献;识别哪些人可能成为阻碍或者投入度低,提前进行准备。

针对不同的相关方,采取不同的沟通,合作策略。对做架构的人来说,相关方的管理是一个非常重要的课题,获得相关人员的支持才能确保项目更容易做成。否则,很容易无法推进而失败。

在相关方支持上:

  • 高层给予一定输入的话,可以让架构模型有更高的质量和形状。
  • 高层支持的话,可以帮助项目获得更多资源,保证项目更容易做成
  • 早期识别相关人员的依赖,可以在事情推动的时候提前做好准备,减少一定的冲突和无效推动

架构内容框架

执行ADM的过程中,会产生很多输出,比如流程图,架构需求,项目计划,项目合规性评估等等,为了能够以一种一致的,结构化的方式来展现这些主要的工作产品,用一个架构内容框架(Architecture Content Framwork)来表现它们。

整个架构过程中,可分为三种类型的产出:

  • 可交付成果: 在架构开始阶段大家约定要产出的内容,一般有契约合同规定,明确的交付内容是什么。
  • 可复用架构组件:在架构设计过程中沉淀的可以给业务或者技术复用的组件,在今后其它的架构设计过程中仍然可以再次使用。
  • 一些过程制品:一般是过渡性的产品,一般分为矩阵(用来展现事物之间的关系)、目录(事物的列表)、图(事物的图形表现),一个可交付成果可以包含多个制品。

在ADM的每个阶段都有对应内容的输出,最核心的原子产出仍然是列表,矩阵,以及图。在每个阶段的可能产出,可以参考文档:

pubs.opengroup.org/architectur…

架构演化

在长期的架构设计过程中,积累足够多的架构内容,这些内容不仅可复用,还可针对企业不同发展阶段的提出针对的解决方案。

可以让架构师能够从广泛的角度阐明企业架构的设计内容,历史因素与未来因素的考虑。可以让业务方明白当前企业架构所处的位置,然后进行沟通。

官方参考图:

关于TOGAF总结到这里,其大多是方法论的内容,还需要在实践中融合贯通。

总结

回到刚开始学习的疑问,给出一些回答:

什么是架构师?

架构师是做什么的?

架构师是开发的新方向?

什么是架构师?

架构师是设计做什么、怎么做能帮助企业完成业务目标的人。

架构师是做什么的?

架构师的工作内容:梳理企业愿景与战略,设计实现企业目标的路径图,协调沟通使目标达成一致,减少项目阻碍,部分时间用于功能实现。

架构师是开发人员新的方向?

听一些人说,反正到哪里都是写代码,看哪里给出的薪水更高。确实如果只是写代码的话,工资提升空间有限,自己没办法做主,要从只会写代码的角色中转变。

根据我的认识:架构师是将自己写代码的时间减少,把这部分时间用来决定做什么才是正确的,有价值的,贴近业务,有方法有套路的解决业务的问题。

这个过程对于有经验的开发来说,并不算太难,成本也不高,但是多了思考什么更重要,什么更有价值,最终结果可能会更好,因此开发往架构的方向发展是一个成本低收益高的选择。

如何画架构图?

关于架构图,架构师好像总是要画各种各样的图,不会画图怎么办?

参考TOGAF中的内容,所有图的目的都是为了沟通和达成一致,针对不同的人要绘制不同的图,其中绘图的要义:

  • 这张图要给谁看的?
  • 列出所有想要表达的内容,如果没有要表达的,也就没有画图的必要;
  • 要表达的内容之间的关系。 层次,还是依赖,还是包含等
  • 内容与关系,通过图表现出来;
  • 上色,强调重点与一般点。

架构方法论上,TOGAf给出了一些参考,在成为架构师上,还需要不断调整自己的动作,不仅仅把自己当做一个技术人员,阿里云有个职位名称叫做“解决方案架构师”倒是挺不错的头衔,在后续工作中提升架构能力,针对不同的业务问题,都能提出自己的解决方案。

参考

  • TOGAF做题网站: