在转变成软件设计师角色之前，我一直认为软件架构师和系统设计师的角色和职责是一样的，只是不同语境下的不同叫法。在向系统设计这个角色扩展时，才感觉到或者说发现到两个我色是有差别的。软件架构师应该是偏向于软件的设计开发；系统设计师相对软件架构师而言在软件整个体系结构中应该更上层一点，关注的范围相对要宽广一点。
工作以来的岗位一直是软件开发工程师。多年工作过程中，大部分时间是基于需求来设计和实现软件产品。所以在能力的扩展方面，更多地关注在软件架构师这个层面，初期是借鉴前人的代码，再慢慢地尝试抉择运用合适的设计模式，再到后来的软件架构。这一系列动作，都是为了实现软件源码的复用，让软件结构的层次分明，易于后续的功能扩展和产品维护。可以看出，使用软件架构主要从一个开发者的角度，让自己的源码（注意，还不是最终产品）看起来优美：没有冗余代码，结构层面分明；舒心：个人觉得，使用了良好的架构/设计模式，自身能力价值呈现了出来；质量高：结构的分明便于后期问题的排查、后来人的学习，以及新功能的扩展。这一系列动作，映射到项目上的价值是，复用已有源码和设计模式，可以降低产品的开发周期；基于好的架构/设计模式，提高了产品的性能，可修改性等；好的源码质量，也降低了产品后期的维护成本。
基于上面的总结和工作体验，个人对软件架构师的理解和实际运用，更多地是在整个产品生命周期的中的实现和维护阶段，没有涉及整个产品的生命周期。
在向系统设计师扩展的这三、四个月里，总体感觉就是，系统设计需要用比软件架构更高的层面去看待整个产品，是大而广的，但不会太精细地去关注具体的细节。就如软件实现阶段的实现细节，系统设计师不应该去关注的这些细节的，软件架构师却更多的关注在上面。
两个角色的主要职责是不一样的，有时候还会出现对立和冲突的情况，由于各自处于的出发点不一样。系统设计师，可能为了满足客户的时间需求和快速占领市场的期望，希望较快地生产出产品，所以产品能满足基本功能就符合期望了，不一定是一个完善的优美的产品；而软件架构师，当得到功能需求时，更多地考虑是软件如何实现地比较完善，对原有产品代码复用或不产生不利影响，考虑到后期可能会有的新需求和功能扩展，这样必然需要更多的时间去分析，设计和实现。这种冲突，经常会发生，最后只有两者相互妥协，看似双赢，但问题还是可能在某个时候暴露出来。
理想状态下，需要两者相互理解对方的痛点，减少冲突。但大家都知道，站在自己的角度去理解对立面是比较困难的，所以最好的方法是，让两者相互学习，融合成一个角色；但两个角色有各自的特点和侧重点，软件架构师并不能被系统设计师代替。或者说，当一个人从软件架构师转变成为系统设计师之后，其软件架构师的能力会慢慢被实际工作所弱化。在实际工作中，相互学习的最后，基本都转变成了系统设计师，也许这就是软件架构师到系统设计师的成长过程。
