随着互联网的发展,软件的体量越来越大,这就要求每一个产品在设计之初就需要设计相应的架构以适应产品长期的发展以及升级。作为产品经理——一个产品最主要的负责人,也应该知道一点软件架构的知识。
软件架构师的首要关注点不是系统的功能,而是软件的品质,软件品质关注点指明了功能呢必须以何种方式交付,才能被系统的利益相关人所接受。作为一个架构师,你应该了解软件产品利益人以及他们的关注点:
技术支持人员,他们关注帮助平台电话呼入的数目和复杂性。
架构师第一项任务,就是与利益相关人员协作,理解这些品质关注点和约束,并为它们排列优先级。为什么不从功能需求开始呢?因为通常有许多可能的系统分解方式。例如,从数据模型开始可能得到一种架构,而从业务处理模型开始则可能的得到不同的架构。在极端的情况下,系统没有分解,被开发成单一的软件。这可能会满足所有功能需求,但是可能不会满足品质需求。
一个项目通常情况下会有以下关注点:
产品向它的用户提供哪些功能?
软件将来可能需要哪些改变?哪些改变不太可能发生,不需要特别容易进行这些改变?
产品将达到怎样的性能?
多少用户将并发使用该系统?该系统将为用户保存多少数据?
在部署的生态环境中,该系统将与其他系统进行哪些交互?
如何将编写软件的任务分解为工作指派(模块),特别是这些模块可以独立地开发,并能够准确而容易地满足彼此需要?
如何将软件构建为一组组建,并能够独立实现和验证这些组建?哪些组建应该复用其他的产品,哪些应该从外部供应商出获得?
如果产品将以几种变体的形式存在,如何开发一个产品线,并利用这些变体的共性?产品线中的产品以怎样的步骤开发?在创建一条软件产品线时,要进行哪些投资?开发产品线中不同变体的选择,预期会得到怎样的回报?
特别是,是否可能开发最小的产品,然后再添加(扩展)组建,在不改变以前编写的代码的情况下,开发产品线的其他成员?
产品是否需要用户认证,或者必须限制对数据的访问?数据的安全性如何得到保证?如何抵挡“拒绝服务”攻击或其他攻击?
到这里是不是有点熟悉啊,这其实就是产品经理写的PRD文档中的一份,PRD文档中有关于产品性能指标,安全的指标等等,而架构师很大部分工作就是在拿到PRD的时候把项目进行分解,让其在架构上符合产品设计基本要求。