架构上很多东西都是相通的，架构与个人的修行之路随行。
软件架构认知
软件 是一系列按照特定顺序组织的计算机数据和指令的集合。一般来讲软件被划分为系统软件、应用软件和介于这两者之间的中间件。软件并不只是包括可以在计算机（这里的计算机是指广义的计算机）上运行的电脑程序，与这些电脑程序相关的文档一般也被认为是软件的一部分。
架构 是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计，例如架构描述语言（ADL）用于描述软件的体系架构。
软件架构 是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。
软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。
在面向对象领域中，组件之间的连接通常用接口(计算机科学)来实现。 软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。
架构师
很多人把架构师当成一个最终的职业目标或者一个很牛的职业，其实在生活中每个人都是架构师，不分职业，不分种族。
比如，你能把家里的家具摆放的位置能够方便你平时生活起居的使用，那么你也在扮演着生活架构师的角色，而有的人生活用品、家具摆放的一团糟，看起来很凌乱，但是他（她）却很方便的生活下去，反而你帮忙整理好了以后却找不到他想要的东西了，这对于他（她）来说，”凌乱”也是适合他（她）的架构，毕竟这种生活方式适合他（她）。
架构的本质是什么？有人说是管理，对机器和代码的管理，架构师的职责是遵循架构的原则，开发和完善各种开发工具、自动化工作流，设计项目架构，提高整个团队的开发效率，让团队成员可以更好的协同工作。
这两年来，隔三差五就能看到一些关于架构师应不应该写代码的文章，我是属于写代码派，因为我本身就喜欢写代码。
但是，当工作职责发生变化之后，如何保持写代码和其它工作之间的平衡就成了问题。
从个体效率上来看，我自己亲自写代码，和很多人相比没有什么绝对优势，甚至有些人码代码的速度比我还快一些；但作为架构师，参与写代码还是会有一些不大不小的收益。
总结有一下几点：
- 每个系统都有一个架构
- 架构由架构元素以及相互之间的关系构成
- 系统是为了满足利益相关者（stakeholder）的需求而构建的
- 利益相关者都有自己的关注点（concerns）
- 架构由架构文档描述
- 架构文档描述了一系列的架构视角
- 每个视角都解决并且对应到利益相关者的关注点。
而在软件工程上，一个好的架构，就是深入浅出，而松耦合的，它能顺应业务的发展，弹性伸缩，当然，它的出世需要一个好的设计者，抽象出架构中生命周期和非生命周期部分，这无疑需要大量的系统切分经验和精通业务的能力。
架构系统前，架构师的首要任务是尽最大可能找出所有利益相关者，业务方，产品经理，客户/用户，开发经理，工程师，项目经理，测试人员，运维人员，产品运营人员等等都有可能是利益相关者，架构师要充分和利益相关者沟通，深入理解他们的关注点和痛点，并出架构解决这些关注点。
架构师常犯错误是漏掉重要的利益相关者，沟通不充分，都会造成架构有欠缺，不能满足利益相关者的需求。利益相关者的关注点是有可能冲突的，比如管理层（可管理性）vs技术方（性能），业务方（多快好省）vs 技术方（可靠稳定），这需要架构师去灵活平衡，如何平衡体现了架构师的水平和价值，所以一个经验老道的软件架构师，是能够让人员分工合作，且并行工作。
架构师类型
技术架构师
每个产品线都有架构师，在技术平台部门也有技术平台的架构，那么，技术平台和业务产品线的架构互动，就是首席架构师在衔接了。让技术平台架构能够和产品业务系统的架构互相促进和支撑，就是首席架构师的份内之事。
所谓的技术架构师，是从从技术总监和研发 Leader 身上剥离职责了，让技术总监和研发 Leader 偏项目管理（管理族），把各个模块之间的架构设计工作，独立出一个岗位，就是技术架构师。
当你身处于技术架构师这个职位，你会发现，这个阶段你的研发团队已经超过100来人了，需要有人专注来做架构规划、架构设计、日常维护。
而不是让研发总监和 研发Leader 又做管理又做技术一股脑都扔给他们，你就等着总结果产出。
技术架构师的主要职责有以下：
有点:
- 架构分析
- 架构设计与实现
- 业务架构设计与实现
- 重构与架构维护
CTO
所谓的CTO，需要组织制定和实施重大技术决策和技术方案，制定技术发展战略、规划发展方向，全面负责公司技术层面的所有管理工作；
主要参与公司战略讨论，负责技术部整体发展方向，负责团队目标和工作计划的制定和高效执行，确保目标实现；
负责技术攻关与团队技术指导；带领技术团队构架、研发、设计，完成对于平台整体搭建、维护及产品开发、设计、指导关键技术模块，并对系统安全性、稳定性负责。
CTO 的主要职责有以下：
- 团队业绩达成
- 前沿与平台
- 研发过程管理
- 组织与人才建设
基本素养
前瞻性的眼光
业务是架构的核心，技术只是解决业务问题的工具，而架构是让业务长大的组织方法。
软件架构不是立竿见影的去实施具体的项目，而是思考那些东西是被需要的，未来会发展成什么样子，要让团队看到两到三年未来的样子。
尽可能的收集信息、推演发展趋势，一个问题，在当前状态下可能是一个小问题，但是未来，随着体量、行业变化、技术变化等这些的影响，小问题是不是会变成大的问题，需要有什么样的架构和布局来支撑未来的变化。
好的架构要能预知业务的发展，为业务的增长提高更高效的服务。
不要等到两年之后再开始实施，互联网不是大雨吃小鱼，是快鱼吃慢鱼，所以一个优秀的架构师，前瞻性思考能力决定这公司的未来。
系统性的思考
- 从业务、市场，到技术实现
- 从软件的过去、现在，到将来
- 从外部客户，到内部研发
- 从软件研发，到硬件部署
- 从功能实现，到运行效率
开放性的心态
交流 交流和分享对于技术人员的改变和提升是很大的，它提供了一种”社交属性”，在我们自己的技术推广出去的同时，得到多维度的信息和感受，吸收一些好的想法和建议。
对每一个讲师来说，对外分享的过程对于自身和团队都会产生巨大的积极影响，或是思路更加清晰，或是信心更加充沛。同时和用户交流过后，团队的眼界也会得到提升。
开源 开源的本质其实是分享，而且对于技术人而言，开源的益处更大。
在开源过程中，在社区或者平台进行交流，总是能带来新的想法和碰撞。
持续性的学习
新技术永远层出不穷，如果你抗拒变化，或惧怕变化，在心里优势上就落后了一大截。
当然，业界的新技术层出不穷，要去跟踪每一项新技术的变化也是不可能的，我的建议是尽量掌握基础的技术，越是基础的技术越是恒定。
如计算机的体系架构，TCP，HTTP，各类编程范式，OOP，MVC架构等，都是好多年来没有发生过变化的技术了。
许多新技术也是建立在他们上面，当你了解了这些基础的技术，建立在他们之上的新技术也就能很快掌握了，并能迅速而准确地对这些新技术作出“价值判断”。
现代社会，难免的一点就是个人必须置身于群体之中，程序员更是如此。从群体心理学的角度来看，在群体里，个人的才智被削弱，异质性被同质性所吞没。由此，如果一个团队不爱学习，那么，其中的成员也很难坚持学习（个性和意志力特别强的人除外）。
如果你爱学习，请想办法让你的团队也变得爱学习，这样，你对学习的坚持将变得更加容易。
或许你认为建立学习氛围，是团队领导的事情，跟自己无关。领导当然可以来做也需要来做这样的事情，但要明白的一点，学习这事，如果变成从上向下，就难免“政治化”了，容易失去它本身的意义。而从下往上，更能建立轻松和谐的学习环境。
