从架构看架构师

一、背景

    最近大项目一个负责人找我，他碰到一件头疼的事情，有个团队的sm（团队负责人）不太擅长组织协调工作，准备把他进行转岗，但是该转到哪个岗位呢？一个思路是考虑该sm是个老员工，考虑他以往的贡献能否让他做sa(架构师)？

    我说别急，我来帮你梳理下目前团队的角色和职责，看完后也许让他做什么岗位你可能就清楚了。

   下图是我们目前的研发过程各角色流程和输出图：

    上图看似清晰，其实融合了CMMI流程、敏捷以及历史遗留的各种角色，有的缺乏职责全景和明确定义；有的时候职责早发生了变迁而没有修订；还有各个阶段职责交织、输出物存在耦合的，更说不清各自所需的能力，总之，各种各样的原因导致没法根据设计开发中所需职能诉求进行明确的角色建设和岗位轮动。

二、根因

    问题的根因其实还是康威定律，职责和角色不正交导致的。

    现在我们从4A架构和RUP4+1架构的角度对上图中所需能力进行一下解耦和分析。

 ：对应4A架构的业务架构，业务架构主要解决业务分析的不丢不重，还有就是把功能设计到用户心坎里，真正做到价值端到端流动，产品的客户和用户的价值高效实现了，软件才是真正成功了。

    纲举目张，业务架构保证做正确的事，重要性不言而喻。

    业务架构重点是业务目标和业务流程，其包含的内容也较多：愿景、目标、场景、流程（阶段、活动、任务、步骤、业务规则、业务实体）、业务身份、解决方案、业务服务、业务能力、基础能力。对于其中的关系和方法论有兴趣可以参加我们的业务架构战训营。

：这一块对应的内容就比较多了，比如：

1、应用架构

    来自4A架构，代表软件组织架构和模块。体现为对业务架构的支撑关系。

    它的作用可以实现拟康威定律，根据应用架构反向塑造团队组织结构。

2、运行架构

    来自于RUP4+1，包括：

a、核心数据结构和关键算法

b、进程/线程模

    并发or并行

c、通讯结构

    主从、p2p、主从+p2p

d、通讯机制

    同步or异步

    共享内存、信号量、锁。。。   

    协议：二进制（传输效率高）、文本、json（易读、传输效率低）

e、持久化

    schema：关系型、nosql

    access：read more、write more、random more

    consistence：实时一致性、最终一致性、因果一致性

    data sharding：数据分库分表（数据路由）、分布式数据库

f、可靠性

    主备，主从，多主，跨机房多活

g、容量估算

    估算两年后数据容量，并发量。。。

3、技术栈

    来自于4A架构的技术架构，包含前后端开发语言、开发框架、数据库中间件、内存数据库、消息中间件等选型。

4、部署架构

    来自RUP4+1

    组网结构：管理面、数据面

    硬盘扩展：本地硬盘、分布式存储、云盘

    内存：本地内存、分布式内存

    微服务：单体、单机、集群等

    解决扩张性和高可用性问题。

1、开发架构

    来自于RUP4+1，代码的上下分层和左右分模块，也是领域模型存在的架构，往往也是我们研发活动中最薄弱的环境。

   清晰的目录结构，清晰的上下层依赖关系，清晰的模块划分，整个系统易于理解易于维护易于扩展非常关键。

   轻视开发架构，很容易被困死，见下图：

clean code+TDD

    代码有TDD测试用例保护、同时满足clean的要求，容易懂容易改。

    梳理完成各个研发阶段和各个架构的对应关系，这样各个阶段能力要求跃然纸上。

    另外，其实4A架构和RUP4+1有对应之处。

    业务架构-》RUP4+1场景

    应用架构-》RUP4+1逻辑架构

    技术架构-》RUP4+1开发架构+运行架构+部署架构，技术栈包含在上述三个架构中。

    数据架构独有。

从变化频率来看：

    开发架构变化最频繁，特别是遗留系统架构，基本都是大泥团，需要能力最突出。

我们再来看看这张图：

• 总工/MBA网元/子系统级业务机构、应用架构、运行架构、部署架构、技术栈-》全量新增，总工维护跨网元变更，另外还负责创新和竞争力；MBA维护跨子系统变更。
• SE/BA

    1、子系统内应用架构变更维护

    2、开发架构变更维护，这块相对薄弱

• TL/DEVTDD+clean code

三、方案

    根据上述分析，我们重新定义职责：

     听完上面的分析，我的那位同事豁然开朗，自己就说出了答案：那个sm代码能力强，但作为架构师还不够格，去做tl挺合适的。

      能看到这里说明你有耐力，确实具备架构师的稳字当头的要诀。

      只有把上述框架全部打通，就能hold住领导，镇住同事，唬住下属，再深入理解点业务，那还不场面全控，自信满满，升职加薪。。。。。。

四、小结

    古人常说名正言顺，只有通过架构视角把各阶段的职责梳理清晰，才能更好的做好能力建设，依据逆康威定律的原则，由系统的特性来决定组织和角色的定位和建设，才能理清关系和职责，做到事半功倍。