在研发人员做研发的架构搭建阶段，采用哪种模式的平台与展示方式，对于日后的产品产出及未来产品的后续规划有较大影响，如果选择不当会受到根基的制约与掣肘限制等。
系统架构选型
释义（什么事？）
系统架构选型，以产品的视角来关注，主要指跟进系统在搭建的过程中采用什么样的系统架构来实现。
认知（怎么做？）
系统架构选型，作为产品人员不需要关注细节，只需要知道我们的产品需求在短期规划及“既定”的长远规划会受到选型多少程序的影响。
关注点：研发采用的系统架构，是否支持当前的产品业务形态，适当地给予建议。
示例（打个样！）
【案例分析】产品经理小南同学在构建某地方旅游服务平台产品时，在详尽的规划后，提供的产品近期规划需求如图51所示：
图5-1 某地方旅游服务平台产品的近期规划
研发同学建议在初期采用开源的CMS系统，能够快速地搭建出内容输出及电商服务、活动页等，可是该系统对于H5页面不能很好地支持。
小南同学在参与系统架构选型会上，重新拿出经过评审的原型需求及产品规划图，讲出业务的重点，但没有通过研发的技术选型。
在系统架构选型的二审会上，研发团队的架构师同学提出（基于2期的APP端H5需求、H5站需求）新的系统架构的选型将支持以上业务，同时在CMS系统中生成的H5页面支持PC端与移动端的适配，在产品同学及测试同学、PMO对工期无质疑的情况下，评审会圆满通过该架构选型。
市面上存在很多通用的开源架构，但是不能像有些在线课堂的讲师一样，把两个月来传到各个论坛的案例拼凑一下再召集学生来听，愚弄更多的人，有些时候是盖不住的！
架构选型过程中，难点在于能够支持当前及近期规划的业务。(www.xing528.com)
业务架构梳理
释义（什么事？）
业务架构梳理，是在原有业务与选定的系统架构基础上，深度的业务匹配度的梳理。
关键点：在现有业务、选型的架构基础上，梳理匹配度及调整的过程。
认知（怎么做？）
业务架构梳理，是在既定选型的基础上，细化匹配业务需求的过程。在梳理时，如出现微小的差异，可以通过技术来评估调整方案及耗费资源成本；如出现大量不可控与预知的难点时，建议重新发起系统架构选型。
与系统架构选型的差异在于，该梳理过程是基于已选定的架构来进行更细化业务需求的匹配比对的工作。
示例（打个样！）
【案例分析】小于同学在得到参加业务架构梳理评审会的通知后，脑袋都大了，因为他深知本公司这些研发大拿是“拿鼻子看人”的！
小于紧接着向成都产品经理体系群的几个铁杆群友问询，他们参加过的业务架构梳理评审会，研发同仁们在会上通常会拿什么东西跟产品业务细化需求进行比对，然后，小于得到林林总总的答案，基本在EA、Power Designer等输出物上为难点。
通过一天的梳理，小于试着从产品的角度，将细化的业务需求使用EA画出相应的UseCase（用户案例）等，使用Power Designer画出了一些关键业务表及逻辑关系图。
第二天的评审结果可想而知，（作为给予产品意见的参评方）研发同仁至少反响不会太差。
产品工作有些时候就怕认真两字，在认真的过程中会发现自己的不足，从而加以解决。但是上面的例子是希望大家不是在遇到了相应的工作时才想起来去学习软件工程的知识，而是应该怀着谦卑之心虚心去学习一下几十年沉淀下来的软件工程理论。犹如，学武之人学得再高深，蹲马步也是前面必学的基本功……丢下基本功去学成大师的不是奇迹，而是花架子。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
