哲学家常思考的问题：” 我是谁？”” 我从哪里来？”” 要到哪里去？不只是哲学家，我想每个人都有自己对这三个问题的认知。
如果我们要成为架构师，我们自己要面临的三大问题：
找准自己定位：我是谁？在哪里？
怎样做好架构师：我要做什么？
如何搭建架构师知识体系：我该怎么做？
这里面就是做事方法论：目标（我要做什么），方法（计划）（我该怎么做）, 执行/行动
1、架构师定义
什么是架构师，这个聊架构话题时永恒的问题。每个公司对架构师的定位也有所不同，因为不同公司所处的阶段，业务模式，应用场景也都不一样。对架构的要求也不一样。
在初创公司的野蛮生长阶段：业务场景和需求边界很难把握，有时候根本不需要架构师，产品需要快速迭代和变现，需求频繁更新，这个时候需要的是快速实现。当然如果公司成长以后，这个阶段就是欠下很多技术债，埋下很多坑，如果人员流动很频繁，后期系统维护成本是非常巨大的。
在公司成长稳定阶段：业务模式和应用场景边界都已经比较清晰，这个时候最需要架构师需要架构师能对线上业务进行模块划分，系统拆分重构，并做好相关高可用的措施，以保证系统的稳定，安全、高效地运行。
不同的行业，对架构师的要求也不同，比如电商业务和AI领域，从架构到业务场景，完全是两个物种。
在百度百科里面这么定义： 系统架构师是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导任务。具体来说是一个确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点的技术人员。主要着眼于系统的“技术实现”。因此架构师应该是特定的开发平台、语言、工具的大师，对常见应用场景能马上给出最恰当的解决方案，同时要对所属的开发团队有足够的了解，能够评估自己的团队实现特定的功能需求需要的代价。系统架构师负责设计系统整体架构，从需求到设计的每个细节都要考虑到，把握整个项目，使设计的项目尽量效率高，开发容易，维护方便，升级简单等。
架构师实际上就是软件的总体设计师。打个通俗的比方比如某个工程总设计师，类似三峡工程的总设计师。
架构师的形成一定是在实践中积累起来的，而并非上了几次培训班，读了几本书就可以成功的，架构师是在工程实践中培养出来的!
2、架构师作用/职责
架构师在整个软件系统开发过程中都起着重要的作用，并随着开发进程的推进而其职责或关注点不断地变化。
1）、按软件开发过程维度来说：
需求阶段：软件架构师主要负责理解和管理非功能性系统需求，比如软件的可维护性、性能、复用性、可靠性、有效性和 可测试性等等，此外，架构师还要经常审查和客户及市场人员所提出的需求，确认开发 团队所提出的设计;
架构设计阶段：架构师负责对整个系统架构设计，制定开发规范、开发计划，指导整个开发团队完成这个计划。
开发阶段：架构师则成为详细设计者和代码编写者的顾问，并且经常性地要举行一些技术研讨会、技术培训班等;
测试和交付阶段：协调做好相关测试和部署。
维护阶段：软件架构师就开始为下一版本的产品是否应该增加新的功能模块进行决策。
2）、按职能维度：
1 确认需求
架构师要懂得用户需求，理解用户真正想要什么，这使得架构师必须要和分析人员不断沟通，反复确认需求规格说明书，以此来保证他精准清楚用户需求。
项目经理刘先生在受访时说：「架构师会与很多人沟通，例如开发人员，例如我们项目经理，有时甚至是用户本身。架构设计的目的很明确，目的是什么呢？挖掘用户需求。」
2 系统分解
在架构师认可需求规格说明书后，架构师已明确用户需求是是什么，这时候便看架构师的分解能力了。
系统分解包括纵向分解和横向分解：
横向分解是对系统分解成不同的逻辑层，确定层与层之间的关系。是指基于技术架构层次进行的人员角色分工和任务分解。常见的分层：
应用层：主要负责具体的业务逻辑处理
服务层：提供可复用的服务
数据层：负责数据的存储和访问
分层注意事项：①必须合理规划层次边界和接口；②禁止跨层次的调用及逆向调用。
纵向分解是将不同的功能和服务分割开来，包装成高内聚低耦合的模块单元，有助于软件开发和维护，还便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。
3 技术选型
在系统分解后，架构师会最终形成软件整体架构，接下来，架构师的职责是技术选型。
前端到底用瘦客户端还是富客户端呢？数据库是用MySQL还是MSSQL又或是Oracle呢？架构师张先生在接受采访时说，在了解用户需求后，分解完系统后，技术选型是非常重要的环节，提出各个方向，我再进行评估。不过，很多人都以为架构师是有决定权的，其实不是，架构师没有拍版的权力，决定由项目经理来做。
架构师在技术选型阶段会提供参考信息给项目经理，项目经理再从预算、进度、人力、资源等各方面情况来权衡，最终确认。
4 制定技术规格说明
如前文调查显示，架构师在项目开发过程中是「灵魂人物」，并且要具备协调组织能力和懂得人员分工。
在制定技术规格说明阶段，架构师要协调起所有的开发人员，架构师通常会用技术规格说明书与开发人员保持沟通，让开发人员能从各个视角去观测、理解他们负责的模块或者子系统，确保开发人员能够按照架构意图实现各项功能。
3）、关注点：
•方向规划：有想法和技术展望目标，制定短期目标
•架构设计：集思广益来设计，归类总结，根据讨论结果制定规范。设计不仅仅是技术相关（业务流程，业务方向，模块划分组合，框架设计，流程纰漏等），设计出来还是需要实施的。
•技术攻关：疑难技术点攻关，将问题集中化解决，提供平台化解决方案以及选型决策。
•解决疑难问题：发现各类型问题（不仅仅是技术），通过规范，演讲，绘图等方式解决隐患。
•互动沟通：部门之间沟通，开发之间沟通，产品之间沟通，市场沟通，沟通后产出图形化文档及设计。
•关注点：秩序，统一，规范，稳定，高效
架构是要靠团队做出来的
•保持和架构的沟通，架构通过团队的沟通总结出方向
•队员经常提出自己碰到的问题，并分享给大家，思维碰撞促进发展
•产品经常提出设想和规划，能够使得架构符合未来发展需求
•运维经常提出隐患及分析，能使得架构快速拆分模块
•定期做总结归纳以此分析问题，解决问题
•团队成长、就是每个人的成长、每个人成长眼界自然增长
•团队的成功、就是产品的成功，产品的成功就是公司的成功
公司的成功可以给你加光环，但光环不代表自己的能力代表经历
3、架构师分类
其实架构师就是个title，每个公司称呼都可能不一样，和架构概念一样。
软件架构师：
软件架构师是软件行业中一种新兴职业，工作职责是在一个软件项目开发过程中，将客户的需求转换为规范的开发计划及文本，并制定这个项目的总体架构，指导整个开发团队完成这个计划。主导系统全局分析设计和实施、负责软件构架和关键技术决策的人员，比如这些架构师的title可能是JAVA架构师、Python架构师、LAPM架构师等等。
web架构师：
web架构师是网站系统、功能、模块、流程的设计师，架构师，好比是高楼大厦的设计人员，通常一座大厦在建之前，都先由设计师将蓝图描绘出来，包括其形状、结构、尺寸、材料等等，然后建筑工程师带领工人们按照蓝图将大厦一层一层地建起来
架构师也要看在什么样的公司，中小公司很多架构师都是全能的。通常公司规模和体系越大，分工会越细：大体可以这么分类：
解决方案架构师：与客户探讨业务需求，将业务、市场，与技术、产品结合起来，为客户提供解决他们需求的方案。比如阿里云针对大客户都有解决方案架构师。
系统架构师: 也称应用架构师。最终确认和评估系统需求，并将业务转换为技术，为研发人员制订核心框架与技术规范 为研发工作澄清技术细节并扫清技术障碍 。服务器负载，可靠性，伸缩，扩展，数据库切分，缓存应用
平台架构师:这里的平台其实包括两个平台，一个是系统平台，也就是负责搭建多个系统整合的系统应用平台；另外一个其实是基础平台，是专门负责搭建基础技术平台；两者其 实区别蛮大，也经常容易被从业人员混乱。举个简单例子，金蝶有平台架构师一职，但是金蝶BOSS应用和金蝶中间件两者招聘的对象和技术要求是截然不同的。
业务架构师：业务架构其实已经开始脱离技术层面了，但是它要求架构师有跨越多系统的大局观，去整合和组织不同系统的技术平台与交互模式。其实这个职位的未来也就是CIO了。 主要内容：理解业务，梳理模型，设计模式，接口，数据交互。
网络架构师:过去，我们可能听的最多的是网络工程师。不错，一个优秀的网络架构师必须有足够的网络技术基底，并且它的关注点也是系统的基础架构。比如说如果搭建并优化集群环境，如果构建基于云计算的系统应用与部署等等。它对于像淘宝、腾讯这样的互联网公司是极其重要的。
移动架构师:移动互联网的迅猛发展横向和纵向都细分出了很多新的职责和岗位，移动架构师的职责和作用日益重要，既要整体和全局考虑整个前后端的软件系统架构，又要重点深入移动客户端的架构设计的方方面面，既要有跨平台思维，又要拿捏好原生和混合开发的尺度，另外移动应用的特点，导致移动架构师必须要比传统系统架构师更加注重非功能性的质量属性。
前端架构师:这也是移动互联网的迅猛发展而细分出来的新的职责和岗位，这里的前端特指网站开发中的前端，主要考虑前端呈现层的设计（HTML/CSS/JS/AJAX/RIA/…），跨浏览器设计等等。
大数据架构师：比如某些公司做大数据处理，需要理解业务，并通过大数据相关技术来实现。
4、架构师具备素质能力
• 精通某项技术，能够从本质上类比，触类旁通其他技术
• 对等所有技术，只有合适和不合适，没有喜欢和不喜欢。
• 视野开阔，了解不同技术的优缺点。知道使用某项开源技术实现某项业务需求，能够辨别重复造轮子。
• 精通设计模式，但又不泛用。
• 把系统拆分成多个子系统或模块。模块之间尽量松耦合，使得原先串行的开发任务变得可以并行发展。
• 能清楚系统的瓶颈在什么地方， 不断定位技术难度，开发进度，性能，内存等个方面的瓶颈。不断调整骨干力量解决瓶颈，在风险爆发之前消除隐患。
• 能做好前瞻性设计，预判到需求可能产生的变化。
架构师团队内做的事情
•沟通能力：各个方面都要了解，人人想法及规划都要知道，了解产品思想，用了什么方法实现的
•组织能力：组织推动各种技术的改进及功能的完善
•谈判代表：左右两难的时候的调解人
•设计模块及业务：通过图形化设计发现开发后才会发现的业务问题
•成本规划：通过过往经验评估成本及步伐
•愿望收集：不断收集建议及愿望，一步步实现
•传播布道：不断参与行业交流，提高理论及技术知识科普分享团队
5、架构师职场攻略
《大型网站技术架构+核心原理与案例分析》总结：
架构师需要处理好个人、团队、公司的利益。需要不断的在工作中发现问题，解决问题，提升工作经验，知识技能和核心竞争力。扩大自身影响力，达成工作绩效。
1、发现问题，寻找突破
即使在一流的技术团队，也有数不清的问题，团队人员已经习惯这些积重难返的问题，而且解决问题投入产出比不大。例如：
1）数据库线程池存在安全漏洞。
2）版本管理混乱。
作为一个新人，从局外旁观者的视角看待，自然发现很多问题。如果新人急于表现自己，证明自己，往往是事与愿违，四处碰壁。因此新人要先融入团队，和团队共进退，等熟悉情况，了解问题深浅，再寻找突破口，择机而动。
2、提出问题，寻求支持
1) 把“我的问题”表述成“我们的问题”：
人们都不喜欢问题，问题意味着麻烦。当人们听到你说，“我遇到一个问题的时候”，下意识的远离你的问题。 如果需要他们的支持，就想办法把你的问题变成他们的问题，是他遇到了问题，而你来帮忙解决。
既然你也是团队一员，问题表述为“我们的问题”。
1) 给上司提封闭式问题，给下属提开发式问题：
上司一般是做决策，因此给上司提问需要给出建设性的方案或者建议，然后希望得到他的支持，给上司提问：“你觉得A和B哪个方案更好？”
给下属则相反，用开放式的问题启发他去思考，寻找创新的解决方案。“元芳，这个问题你怎么看？”
3) 指出问题而不是批评人:
如果遇到问题，不要责问他为什么出现问题，而是说问题的紧迫性和解决的优先级。
4）用赞同的方式提出问题：
如果人们遇到：“你这里有问题”可能会本能自我保护而拒绝你的建议。
而如果这么说“我非常赞同你的方案，但是我有个小小的建议”。
3、解决问题，达成绩效
在解决我的问题之前，先解决你的问题：
适当的逃避问题：比如我去开个会，回来再的你问题。
做好以下几点，基本离你说的移动架构师不远了
选，Java后台还是客户端开发？
Java跟C、C++、PHP、Python等一直较劲，在当前的现实中，也稳坐编程语言榜首
面向对象的思想在应用开发领域占主导，Java往往成为其代名词
Java技术的人多，一直以来也有大公司资助，所以发展一直不错，进入了良性循环
从企业的角度来说，找Java后台的人相对比较容易
后台被认为是技术核心，而客户端，被认为技术含量不高
贪省事，让Java后台的架构师顺便来一下客户端几个人就好了，这可能是有些企业负责人自然而然的想法
客户端技术和后台技术的侧重点完全不同，连编程语言都不同。Java能统一后台开发；但是从目前的趋势看，虽然客户端也在强调统一，不过语言肯定不是Java
Java后台的人跟用户离得太远，与产品人员沟通，那真是鸡同鸭讲
如果产品真的是为了给用户用，那么选客户端背景的人员做移动架构师要好一点。
客户端是IOS，android，还是JS，根据企业喜好来选吧。根据本人经验来说，当然是IOS啦。智能手机这么热，是谁带起来的？从编程体验，程序美感来说，谁的最出色？只要干过移动开发的人，这几个问题都是不言而喻的
作为移动架构师，要重点注意的三个问题
架构师作为中层管理，直接领导一般是总监了。技术加管理的综合职位，在技术和管理上面的思路，跟总监要保持一致。这方面是最重要的。如果这点做不好，趁早换地方，不让对自己，对总监，对企业都不好。有两种情况需要注意：一种是跟总监合作很好，但是总监自己要换地方；这里，最好和总监一起走，能遇到一个好领导不是一件容易的事。另一种是空降一个总监过来，但是两人想不到一块去。这个时候就有点纠结，离开嘛，感觉舍不得，前面的付出要泡汤；留下嘛，感觉又很别扭。这种情况，需要加强沟通，调整自己，努力使合作更顺利一点。否则，还是要走，毕竟胳膊拧不过大腿，估计大家都懂的。
跟周边部门的合作要做好，特别是产品和测试，运营也要注意一下。否则，将会导致很多稍大公司的部门墙。
跟具体的开发人员也要搞好关系。管理的本质是自己不干活，但是团队的整体效率要更高。这点如果做不好，最直接的影响就是团队的绩效不高，团队缺乏凝聚力，团队气氛压抑。这在很多公司都有发生。
如何与总监CTO合作好？
从思想上认识到，两者是利益完全一致者。总监为架构师拓展上升空间，而架构师将总监的规划切实落地。
保证足够的沟通，可以约定一个固定沟通机制，比如每2周一次。让双方在思想上保持同步和一致。
如果CTO也是客户端技术出生，那么架构师可以多探讨一些技术经验，将CTO的一些技术构想落到实处，同时自己也能在技术上获得提升。
如果CTO是Java后台技术出生，那么CTO尽量授权，架构师侧重在设计思路，技术可行性，技术风险等较高的层面内容。
架构师应该带着方案和CTO沟通，讲清楚AB方案的优缺点。可以让CTO来下决心，就算是架构师下决策，也要获得CTO的认可。
如果意见出现分歧，最好的方式是先搁置，等条件成熟了，很可能意见会趋于一致。如果不能等，只要CTO的意见不是太离谱，还是按照CTO的意见执行比较好。如果有十足把握，自己的方案更好，那么也要得到CTO的许可和谅解，否则千万不要这么做。
如何与周边部门合作好？
产品经理一般不懂技术。架构师的作用就是帮他解决这个问题。在理解了需求之后，要进行技术可行性分析。从技术的角度，提出改善意见。在不改变整体方案的前提下，修改设计，方便实现。这就需要产品经理和架构师的合作。
与后台架构师搞好合作，从后台到实现，整条链路太长，一个人管不过来，需要两人好好合作，共同把好技术关。
测试，要当作开发的朋友看待，是自己人。可以考虑让测试人员在“自测”阶段介入，帮助开发人员提供测试案例。
运营，关系稍微远了一点。关键点是及早介入，不然，到临上线了，要加入一对的运营需求，就可能影响产品投放时间了。
总之，和周边部门，应该以合作为主，及早沟通，将风险消灭在反生之前。
如何与团队成员沟通
移动开发团队人数不多，但是角色和开发语音多。有IOS，android，还有JS和Java网关。
如果一个角色超过3个人，那么就应该设置一个TeamLeader，进行授权
对于自己擅长的技术，要分一两个任务给自己，和兄弟们一起战斗。中层人员需要在一线。
对于自己不擅长的技术，可以采用“结对编程”的方法，逐渐进入角色。程序基本是相同的，还是能够理解和参与讨论的。
对于几个Leader，要重点沟通，在大方向上保证思想一致，给他们空间，协助他们做出成绩。
重点注意团队的正能量以及活跃的气氛，人不是机器。和谐的氛围比冰冷的制度和惩罚要好得多。
记好团队的功绩和成果，提高团队成员集体荣誉感，将奋斗目标引导到“自我实现”上来。
关于技术
整体上是一专多能
以IOS技术为主，跟上苹果的节奏，随时学习新技术。深度技术按照需求来。
Object-C为主，毕竟在用，并且成熟度高。
Swift也要学，这是苹果的未来。
Java要优先学，android和后台都要用到
JS也要学，最近H5势头比较猛
总之，架构师是一个综合素质的体现，打铁还需自身硬，能解决问题，或者能带动周边的人解决问题，才是关键，至于职位、位置，这只是一种职业称谓，你牛逼了，还在乎别人称你架构师，还是其他的吗，技术是硬实力，情商是软实力，君子性非异也，善假于物也。自个体会。
楼上那位已经说的够详细了，我就用一些比较通俗易懂的文字来谈谈我的想法吧。
移动端架构师，我觉得这个词应该是个伪标题，目前没有这一个说法吧？我认为每一个方向安卓或者ios都需要一个架构师，前提是公司都有这么多的app要进行开发。何为架构师呢？我给大家举个简单的例子，当你要做一个计划的时候，你要提前对一些计划做一个总体规划，还要预判可能出现的情况，其他影响的因素，能不能达到最终效果，能不能起到方便，快捷，省事的作用。做程序也是一样，首先，你要对程序的整体架构选型，比如代码层面的架构模式是mvc mvp mvvm等，或者采用什么设计思想，开发一个应用或者系统，在开发之前就要做好一个准备，否则就会出现，遇到一个不兼容的问题，就可能会出现推倒框架，进行重构。。这对于写代码的来说，是一种噩梦。我觉得，一个架构师，一定要对后台有所了解，有些时候，架构的选定，和后台有很大的关系。移动端架构师压根就不存在这一说，除非他能把安卓 ios 前端都玩的很溜，作为一个开发人员，深知能精通三者的人，估计也不会只做一个架构师了。。。