软件架构师必备的职责、技能和知识(DSK) 作者(Len Bass、Paul Clements、Rick Kazman和Mark Klein)认为“职责、技能和知识构成了支撑其它个人架构能力的铁三角”,并根据从大量原始数据中得出的相当可观的研究成果,列出了每个领域的属性。 确认的职责包括: * 架构——创建架构;架构的评价和分析;文档;现有的系统和改造;还有不能明确归类到上述类别的其它架构职责 * 架构之外的生命周期阶段——需求;编码;测试;未来技术;工具和技术的选择 * 与利益相关方的配合——与一般意义上的利益相关方相配合,或者说是除客户或开发人员之外的利益相关方相合;客户;开发人员 * 管理——项目管理;人员管理;辅助管理 * 组织和相关业务知识——组织;业务知识 * 领导力和团队建设——技术领导力;团队建设 确认的技能包括: * 沟通技巧——对外沟通的技巧;通常的沟通技巧;内部沟通技巧 * 人际关系技巧——团队内部;团队外部 * 工作技能——领导力;有效管理工作量;专长于团体环境;处理信息 * 个人技能——个人素质;处理未知因素;处理突发的事态发展;学习技能 确认的知识面包括: * 计算机科学知识——架构概念知识;软件工程知识;设计知识;编程知识 * 技术和平台知识——特定的技术和平台;全面的技术和平台知识 * 组织背景和管理的知识——领域知识;行业知识;企业知识;领导力和管理的技巧和经验 报告建议个人可以通过以下三种方式来提升自己的DSK能力: 1. 获取执行职责的经验:做学徒是获取经验极富成效的方式。单靠教育是不够的,因为没有实际应用的教育仅仅能强化知识。 2. 提高非技术技能:这方面的提升包括参加专业的发展课程,比如领导力或时间管理方面的。 3. 掌握知识体:称职的架构师必须要做的一件重要事情就是掌握知识体并保持掌握最新的知识。参加课程、取得认证、阅读书籍和期刊、访问网站和门户、阅读博客、参加面向架构的会议、加入一个专业的协会、与其他架构师沟通,这些都是提升知识的有用方式。 人类绩效技术,一种适用于提高个人能力的工程学方法 在本节中,作者论述了如何利用由Thomas F. Gilbert创始的人类绩效技术(HPT): 我们期望工程师有价值的绩效;也就是以合理的成本创造价值的绩效。绩效=价值/成本。 绩效提升潜能(PIP)是模范绩效与标准绩效之间的比率,其中模范绩效表示能合理预期的最佳绩效。PIP=Wexemplary/Wtypical。如果最好的工人在最好的环境中用10单元的成本创造出了价值75单元的绩效,那么这个工人的绩效是7.5。如果中等能力的工人创造了2.5的绩效,那么我们的PIP是3,这表示通过提升步骤,中等能力执行者产生的绩效能增至3倍。 高PIP 值预示着很大的改进机会,也应该是重点努力的东西。低PIP值(接近1)则需要为更进一步的改进做大量的投资。在竞争异常激烈的领域,PIP值往往很低,对高重复性的任务来说,PIP值也是这样的。这个推理(Gilbert明确做出的)假设“低绩效通常有较大的潜力。”或者说,“一个人或一组人的能力越欠缺,提升他们的绩效会越容易。”这个比率要想有意义,必须用可识别的成绩来表示,因为没有“能力的一般质量”。 绩效提升的关键是找到能准确反映绩效价值的合适的度量标准。 (HPT的一个现代演化可参看六盒模式)。 作者确定了应用HPT的两个问题——如何度量架构师的绩效价值?计算这个价值需要什么基础设施? 到现在为止,我们只是初步思考了第一个问题,第二个问题还没有相关的报告。我们建议使用DSK模型中的职责来分离出架构师工作的各个方面。 组织协调,研究人和小组如何在组织中共享信息报告的这一部分侧重于多地开发。报告提议,在每个小组都在处理同一个模块的前提下,依赖结构矩阵(Dependency Structure Matrix,DSM)可用来揭示模块之间的交互。DSM可以度量组织内需要多少协调: 满足协调要求的协调能力,架构施加给组织的这一能力是架构能力的一个方面。 报告接着讨论了协调的方法,包括讨论了架构师如何在各团队之间扮演一个协调者: 举例来说,有一位架构师在两组开发人员之间做协调,其好处就是可能获得额外的背景信息,并能在对前景做决定时利用两组的决定。协调者的损失则会包括瓶颈的可能性、引起延迟的可能性、以及在开发人员之间传递时信息丢失的可能性。 组织内学习,组织如何获取、吸收、利用知识来提升绩效的方法学报告宣称,具有架构能力的组织有能力通过被称为“内观(mindfulness)”的方式把经验转化为知识: 比如在完成模块或子系统之后,架构团队对其进行评审或架构分析,以意识到什么进行得很好、什么进行得很糟,这样的架构团队就可做为使用用心学习的团体的范例。 结论 报告最后面的几章重点概况了模型的主题,比如: 指导其他架构师很有可能产生高质量的架构。因为接受辅导是获取真实世界经验的有效方式,从而成为一名更有能力的架构师。 此外,报告论述了能力评价的一些问题该如何实行,比如在考虑职责的时候: 职责:创建一个架构 问题:如何创建一个架构? * 如何确保架构与业务目标是相匹配的? * 架构创建过程的输入是什么?提供给架构师的输入是什么? * 架构师如何验证提供的信息?输入不充分/不适当的情况下,架构师该怎么做? 作者没有推出一套堂皇的“能力统一模型”,相反,提供了一些利用多个模型来改进的策略,最后总结道: 四个模型合起来能用多种方式提供强有力的覆盖。它们提供了对过去绩效和当前活动的一种基本度量方法。它们覆盖到的可观察的可能性有:工件、过程、人和组 织。最后,它们能以一组的方式很好地应用于个人、团队和组织。这样的覆盖给了我们信心,相信这四种模式合起来将产生有价值并可靠的结果。