架构师是业务和技术之间的桥梁,架构师不能只顾技术,不懂业务,架构师很容易两头不讨好
三个核心能力:
判断:1业务理解力2.技术能力3.沟通能力
拆解:1技术深度2.技术宽度3.技术广度
宽度与广度 不是一会事,你熟悉Redis跟memcache 是宽度,了解前端与运维是广度。
取舍:1设计理念2.说服能力3.决断能力
这块综合能力要求高,得有理有据,有能力有担当。
确定性思维:消除模糊、不确定的说法和信息,例如“大量用户”应该明确为“XX万用户”
创造性思维:通过排列组合创新,得到更多的方案。
系统性思维:系统思考,有逻辑和推导过程,例如“为什么不用Native而要用H5”
影响系统结构的设计是架构设计,方案设计不影响系统的架构设计。
Rank:改变系统分层的设计属于架构设计,例如将支付宝提升到和淘宝同级别
Role:修改(增删改拆合)角色属于架构设计,例如微服务拆分
Relation:修改角色关系属于架构设计,例如用消息队列代替接口访问
Rule:修改角色之间的运作规则属于架构设计,例如MongoDB将选举算法从Bully改为Raft
主要任务:
澄清不确定性1.明确利益干系人的诉求;2. 消除冲突的诉求;3. 诉求优先级排序
识别复杂性1.识别核心场景;2.明确或者预估质量需求;3.识别复杂
工作模式:1.与业务方交流2.与利益干系人交流(就是相关人开会)
输出 :1.总体业务架构图2.核心场景流程
主要任务:
设计备选方案1.头脑风暴;2. 筛选方案;3. 设计备选方案;
选择备选方案1.360度评估;2. 明确选择标准;3. 选择最终方案,并汇报
工作模式:1.架构小组讨论2.架构小组写文档3.向利益干系人汇报
输出:1.备选方案2.方案评估结论3 方案汇报结论
细化架构:按照4R架构定义来细化架构
完善架构:可维护性、可测试性、可运维性、成本、安全
工作模式:1.写架构设计文档2.给技术团队宣讲架构
输出 :完整的架构设计方案
主要任务:
收集架构意见1.开发人员意见2.测试人员意见3.运维人员意见
跟进架构落地效果1.性能测试结果2.压力测试结果3.线上运维情况
工作模式:1.总结复盘2.收集吐槽
输出: 架构优化建议、架构迭代计划
架构师工作评价,除了架构项目落地情况,相关人员的架构意见反馈也是老板考量因素。
架构师团队本身是小而美的。多数是虚拟团队项目制,没有职级汇报的。
后面是展开架构设计
包含:1理解架构设计常见利益干系人和诉求
2.掌握利益干系人诉求排序技巧
这个跟PM的很类似,毕竟有人的地方就有江湖。郭东白老师的顺应人性也是不同侧面来讲。
换位思考,从对方利益视角去考虑,才能寻求肯能的合作方案。
投资人:出钱的“爸爸”,【利益诉求】1.成本2.时间3.竞争力 例如:1.你的上级2.业务负责人
监管者:通常是法律要求的组织。利益诉求:合规,处理投诉。
构建着、维护者:开发、测试、运维、运营
使用者,评估者:用户、甲方等
分组、排序、沟通
时间、成本、范围、质量这些也跟项目管理关注的类似。
取舍原则:无法做到面面俱到,需要根据业务目标决定哪个优先
按照影响力大小排序,监管者>投资者>评估者>使用者>构建者>维护者
差异性、冲突性 就需要做排序。差异性:安装影响力点对点沟通,谁权力大听谁的。
冲突性需要开会,一起讨论PK,老板来拍板。要发挥影响力,引导正确的方案,不是简单的听老板的。自己不管只等最后的结果,这个锅后面就得自己背。
复杂度分析