Architecturerepresentsthesignificantdesigndecisionsthatshapeasystem,wheresignificantismeasuredbycostofchange.
翻译为中文就是，架构表示对一个系统的成型起关键作用的设计决策，架构定系统基本就成型了，这里的关键性可以由变化的成本来决定。这句话是GradyBooch说的，他是UML的创始人之一。
进一步展开讲，架构的目标是用于管理复杂性、易变性和不确定性，以确保在长期的系统演化过程中，一部分架构的变化不会对架构的其它部分产生不必要的负面影响。这样做可以确保业务和研发效率的敏捷，让应用的易变部分能够频繁地变化，对应用的其它部分的影响尽可能地小。
架构的迭代和演化性
我是属于老一代的架构师，99年参加工作。职业初学了很多RUP，统一软件过程的理念。RUP的理念对我的架构有很深的影响，RUP总结起来就是三个特点：
RUP很注重架构，提倡以架构和风险驱动，该开始一定要做端到端的原型prototype；通过压测验证架构可行性，然后在原型基础上持续迭代和增量式开发，开发->测试->调整架构->开发，循环，如下图所示：
从上图可以看出架构师要尽可能写代码，做测试，纸上谈兵式做架构而后丢给团队的作法非常不靠谱（除非是已经非常清晰成熟的领域）。另外，做技术架构的都有点完美主义倾向，一开始往往喜欢求大求全，忽视架构的演化和迭代性，这种倾向易造产品和用户之间不能形成有效快速反馈，产品不满足最终用户需求，继续看下面两个图：
第一个图是讲最小可用产品（MinimumViableProduct，MVP）理念，做出最小可用产品，尽快丢给用户试用，快速获取客户反馈，在此基础上不断迭代和演化架构和产品。第二个图是过度工程（OverEngineering）的问题，其实也是讲产品架构和用户之间没有形成有效的反馈闭环，架构师想的和客户想的不在一个方向上，通过最小可用产品，快速迭代反馈的策略，可以避免这种问题。注意，在系统真正地投入生产使用之前，再好的架构都只是假设，产品越晚被使用者使用，失败的成本和风险就越高，而小步行进，通过MVP快速实验，获取客户反馈，迭代演化产品，能有效地减少失败的成本和风险。
构建闭环反馈架构
第一条道路，系统思维，开发驱动的组织机体，其能力不是制作软件，而是持续的交付客户价值，架构师需要有全局视角和系统思维（SystemThinking），深入理解整个价值交付链，从业务需求、研发、测试、集成，到部署运维，这条价值链的效率并不依赖于单个或者几个环节，局部优化的结果往往是全局受损，架构师要站在系统高度去优化整个价值交付链，让企业和客户之间形成快速和高效的价值传递。
第二条道路，强化反馈环，任何过程改进的目标都是加强和缩短反馈环。刚入行的工程师，也是中国学生的普遍问题，就是生产运维意识不足（监控是系统反馈的重要环节）。有两种花这样讲的：
这是一个电商平台的架构，整个体现了闭环架构的思想，右侧是整个平台的反馈监控环节。具体如下：
下面这个图展示了系统提升和改进的一般方法：
收集->测量->调整->闭环重复，在有测量数据和反馈的基础上，系统、应用、流程和客户体验才有可能获得持续的提升和改善，否则没有数据的所谓改进只能靠拍脑袋或者说猜测。
第三条道路，鼓励勇于承担责任，冒险试错和持续提升的文化。这点是最难的，一般和企业人才密度有关。工具，技术，流程只是一个公司的冰山浮出水面的部分，而真正对企业效能影响大的则是冰山水下的部分，即企业的人和文化，架构师作为技术和架构的布道者，有责任义务鼓励和推动试错文化。
这个图讲什么时候该引入微服务。微服务有额外成本的，需要搭建框架、发布、监控等基础设施。初创和小规模团队不建议采用。主要决定因素系统复杂性和团队规模，当到达一个点，单块架构严重影响效率才考虑。另外补充一点，微服务更多是关于组织和团队，而不是技术。
架构和组织文化关系
再谈一下康威定律：
Conway’slaw:Organizationswhichdesignsystems[...]areconstrainedtoproducedesignswhicharecopiesofthecommunicationstructuresoftheseorganizations.
（设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。)
从单块架构到微服务架构是这个定律的很到体现。
团队是分布式的，系统架构是单块的，开发，测试，部署协调沟通成本大，严重影响效率，严重时团队之间还容易起冲突conflict。
将单块架构解耦成微服务，每个团队开发，测试和发布自己负责的微服务，互不干扰，系统效率得到提升。
可见，组织和系统架构之间有一个映射关系（1~1mapping），两者不对齐就会出各种各样的问题，一方面，如果你的组织结构和文化结构不支持，你也无法成功建立高效的系统架构，例如集中式和严格职能（业务，Dev，QA,Deployment,Ops）的企业，很难推行微服服务和DevOps，推行Docker/PaaS平台也会比较困难，这样的组织职能之间都倾向于局部优化（localoptimization），无法形成有效和合作和闭环。
反过来也是成立的，如果你的系统设计或者架构不支持，那么你就无法成功建立一个有效的组织；作为系统架构师，一定要深入领会康威定律，设计系统架构之前，先看清组织结构，也要看组织文化（民主合作式，集权式，丛林法则式，人才密度），再根据情况调整系统架构或者组织架构。
架构师心态和软技能
空杯，或者说开放心态（openminded）是一个成熟架构师的应有心态，stayhungry，stayfoolish，心态有多开放，视野就有多开阔。来自《高效能人士的七个习惯~史蒂芬~柯维》的一句话送给每一个架构师:
如果一位具有相当聪明才智的人跟我意见不同，那么对方的主张必有我尚未体会的奥秘，值得加以了解。与人合作最重要的是，重视不同个体的不同心理、情绪与智能，以及个人眼中所见的不同世界。与所见略同的人沟通，益处不大，要有分歧才有收获。
另外再推荐一个本书《软件架构师的12项修炼》，这书中三个观点很值得每个架构师学习领会:
政治指的是和他人协作将事情搞定的艺术，架构是一种社交活动，在技术的世界里，个人主义很容易被打败，即使你的目的是好的技术是最优的，技术决策是政治决策（technicaldecisionsarepoliticaldecisions），一个技术产品，一波人可以做，另一波人也可以做，到底谁做的好，真不好说，不管谁做，都给业务套上了一副手铐。
我对一些架构师争议主题的看法
主要争议是两个话题：
架构师怎么回答这类问题？一个成熟架构师的口头禅：视情况而定，不一定，是也不是，itdepends。技术和业务，架构师要理解业务吗，看产品和客户，如果是业务性产品，肯定要理解业务，如果是技术型产品，就不一定。
最后
我想说中国现在的互联网发展趋势很好，越来越多的人加入架构师这个行业，这个行业正在“万物生长”。但是我们现在还没有马丁·福勒，adriancockcroft这样的架构牛人物，我辈需不断努力，期待中国10~20年后出现超过十个马丁福勒，adriancockcroft这样的大牛神级人物。我们必不可停止探索，而一切探索的尽头，就是重回起点，并对起点有首次般的认识。