企业架构师 vs 解决方案架构师 vs 技术架构师

前言

本文主要简介一下企业架构师EA, 技术架构师TA, 解决方案架构师SA的区别, 同时探讨各自需要具备的能力和挑战.

企业架构师 vs 技术架构师 vs 解决方案架构师

简单来说, 企业架构师从企业全局的角度出发发现和定义问题, 解决方案架构师把问题转化为一个解决方案, 技术架构师实现具体的解决方案.
网上有一张图描述了EA, TA, SA三者的区别:

上图从软件的生命周期, 细节的涉及度, 关注的程度这三维来度量和区别三者.

**技术架构师Technical Architect(TA)**主要关注在某个技术实现.TA可能在企业中同时负责多个项目, 一般不会关注整个软件生命周期. TA需要有实际的编码能力, 为开发团队提供技术指导, 定义标准和最佳实际.TA的技术能力是考核他的一个关键指标, 所以大部分TA的技术栈比较专注,比如Java架构师, .NET架构师, IT基础架构师. 这些可以从上图的虚线可以看出.

**解决方案架构师Solutions Architect(SA)**一般被分配到企业中的某个项目中, 以确保项目在每个生命周期中保持技术完整性, 目标和方案的一致性. SA一般不写代码, 因为协调各个技术活动是他的主要工作. SA需要参与计划(initiative)的所有方面和活动: 从概念定义, 到需求分析, 到实现, 再到把系统交付到运营和业务单元. 所以SA一般是一个通才, 为所有这些活动做出明智的贡献。当然, 大部分项目不需要单独配备一名SA, 因为如果技术栈唯一, 那么一般只需要TA就能够解决问题. 但是如果和技术相关的风险是巨大的,那么配备一名SA是明智的. 这种情况具体可以被分为: 不确定的需求, 未被验证的技术实现或存在多个技术实现, 外包项目给离场开发团队等.

**企业架构师Enterprise Architect(EA)**负责整个企业。她严格地描述企业的业务实体，它们的属性以及它们与外部环境之间的关系(竞争对手)。EA关心整个生命周期，以及每一项已采用或预期采用的实施技术。同样，她也研究各个项目，以确保整个企业具有完整性和一致性。但是，EA可能需要考虑的详细程度还很低而且很肤浅，因此她必须将除策略级别的决策之外的所有决策委派给特定工作的专家。EA的一个特例是企业IT架构师（EITA），他关注企业内部信息和技术的整体观点。但是，上面提到的有关EA角色的所有内容也适用于EITA角色。请注意，该框架未能在EA和EITA之间做出明显的区分。添加第四维会有所帮助，但是该图将变得混乱。

SA的角色与职责

由于TA, SA, EA的职责不同, 这里主要挑一下介于中间的SA的角色责任.

技术领导

SA需要时一名技术领导, 他需要在如下方面担任职责:

架构设计
开发支持
监督与指导
技术开荒
需求管理

技术顾问

在业务层面, SA还需要作为技术顾问支持不同的业务单元:

管理stakeholders
参与售前
参与架构评估
面试候选人
参与新架构发现
提供高阶成本估算
诊断测试阶段的问题

业务分析/产品Owner

SA还需要担任一部分BA的工作, 根据领域不同, 可能还需要一些行业知识:

行业市场的知识, 如竞争对手, 法务法规的知识
产品知识, 有产品和解决方案路线图, 懂产品策略
懂用户
backlog管理
给BA或PO提供其他建议

部分开发职责

SA的开发属性主要是为了做POC和code review.

SA所需技能

SA所需要的技能比较全面和高标准, 对个人的综合素质有较高的要求.

展示能力

公共演讲能力
白板技能

沟通能力

stakeholder管理
解释能力
协商能力
冲突管理
社交

时间管理

优先级管理
时间管理

思维能力

抽象思维
战术与策略
做决定
评判思维
抗压能力

自我开发

持续学习
自律
个人成长计划
快速学习能力

关系管理

同理心
情商

编码能力

POC
熟悉各个技术栈

分析与设计

能用不同设计解决不同的问题