一、前言
在阅读了王概凯的一系列博客之后笔者对软件架构有了进一步的认识，现就阅读之后产生的感悟总结如下。
二、什么是架构？
随着软件开发的工程化思想的兴盛，软件架构也成为了热词，人人都喜欢聊聊软件架构，但是没人能说清楚这到底是什么。一说起架构，很多人就想要往建筑学上靠拢，而事实也的确是这样的，架构一词确实是伴随着建筑业而出现的。但是我们要想的是为什么会出现架构？也就是说，架构是为了解什么问题的？随着人们对生产力发展的需求变化，人们需要在有限的时间范围以及人的能力范围之内提高工作效率，同时生产质量更优的产品，而单个的人是无法实现这一目标的，这就是架构出现的动力源泉。由此我们就可以对架构进行一个更合理的定义了：首先根据要解决的问题，对目标系统的边界进行界定。其次是对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。接着对这些切分出来的部分，设立沟通机制。在这个基础上使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。综上所述，架构实际上解决的是人的问题。
三、要发现问题的本质
按照我们的理解，做好架构首先要做的就是发现出问题的所在，那么如何才能发现真正的问题呢？这里似乎与软件需求分析有一些相通之处。博客中作者用土豆这个例子来说明了架构师在听取客户表达需求时常常会犯的错误。有时候客户会就自己的业务实际来给出一个解决方案来，而软件架构师要做的就是从这个解决方案中找到用户真正的需求，而不是单纯的受客户的摆布。总而言之，找出问题的主体，是做架构的首要问题。我们要解决的问题，一定都是人的问题。更进一步，架构师要解决的，基本都是别人的问题，不是自己的问题。再进一步，我们一定要明白，任何找上架构师的问题，绝对都不是真正的问题。因为如果是真正的问题的话，提问题过来的人肯定都能够自己解决了，不需要找架构师。架构师都要有这个自觉：发现问题永远都比解决问题来的更加重要。
四、对于软件的进一步理解
软件出现之初是为了模拟人的各种行为，从冯诺依曼结构的提出到图灵机的计算模型，都是以模拟人为目标的。随着计算机科学的发展，计算机的能力越来越强。所以人们越来越依靠计算机来进行工作，由此进一步导致了计算机工作能力的提高以及软件种类的丰富，这也必然导致了软件的成本越来越低。接着随着软件行业的逐步扩大，软件的规模越来越大，逐渐形成了一套工程化的开发思想。有了软件之后，实际上，我们是把我们日常生活中所做的事情，包括我们自己本人都一起虚拟化到了计算机中。而人则演化成了，通过计算机的输入输出设备，控制计算机中的自己，来完成日常的工作，以及与其他人的沟通。软件架构的出现也是同样的。一开始是懵懵懂懂的去写软件，后来慢慢的就有意识的去切分，演变成了不同的架构。这个背后的动力也是一样的，就是提升参与的人的利益，降低成本。导火索也是软件工程师的任务太重，我们需要把很多工作拆分出来。拆分的原则也是一样的，如何让权责一致。同样，这个拆分也是需要组织架构的调整，来保证架构的落地。
五、技术、业务和架构
技术总是在人类解决对业务的要求不断提高的情况下产生，目的也是为了获取更大更好的利益。所以技术是为了解决业务的问题而产生的，没有了业务，技术就没有了存在的前提。另外，有了更好的技术，效率更差的技术，就会慢慢的被淘汰，消失，一切都遵从人类的利益诉求——也就是业务。在发展过程中出现的新技术可能会解决不一样的问题。而新旧两种不同的技术合理结合起来，会更好更有效率的解决业务问题。在解决同一个业务问题的前提下，更高效，更低成本的技术，会淘汰低效，高成本的技术。这是人类利益诉求所决定的。一般刚开始解决根本问题的技术的效率是比较低的，只是把不可能变成了可能。然后就会有提高效率的需求出现，要求改进这个技术。这个技术的低效率部分就会被其他人加以改进，这部分就会形成新的技术。这就说到架构师对项目技术的选择上了。当技术所解决的问题和分拆出来要解决的问题，完全匹配的时候是最完美的情况。但是如果不匹配的话我们应该有不同的选择。当技术所提供的能力远远超过需要解决的问题时，往往掌握技术和维护技术会成为瓶颈。因为越复杂的技术，成本越高。如果自己实现一个仅仅是解决当前问题的方案，可能成本反而更低。我们是否需要造轮子，如果不需要的话自己选用的轮子是否合适？当技术所提供的能力和我们所要解决的问题部分匹配时，还是要看成本。