正文
架构是一个建模的过程
对于一个复杂问题，通常会对复杂问题按照能力领域进行分解，其目的是能够找到与现有能力相匹配的映射。这个映射，就是解决方案。它，离不开人的「知识型劳动」，主要分解为三个方面：
-
对于已知问题的抽象和建模
-
对于已知能力的抽象和建模
-
对于解决方案和工具的设计
其中前两个方面，都提到了「建模」。建模本身是对客观事物的一种抽象，客观事物越复杂，那建模的结果变成盲人摸象的概率就越高。
然而，盲人摸象在IT领域其实不能算是个贬义词，因为这个现象十分的常见。究其原因，解决实际问题信息系统，更多程度是面向于典型应用场景，而不是任意应用场景的。
场景即是对客观事物的认知视角，信息系统做不到、也不需要对一个完整的客观事物进行全面（360°无死角）建模。
举个具体的例子：
对于人这个客观事物，银行系统里，可能会关心这个人财务指标，例如收入、支出和存款余额，但在医院的重症监护病房里，可能就会关心这个人的生命指标，例如血压、心跳。
从例子里可以看出，一个面向具体问题的场景化应用系统，都是对一个客体进行片面的场景化建模。
说到底，建模是一种抽象能力
，具体的说，是人对客观事物认知结果的理性提炼和总结，不可否认感性的部分太难以刻画和描述。很符合《庄子·天道》中所述：「意之所随者，不可以言传也」。
如果要拿数学语言进行描述建模的能力，就是找到一组尽可能少的特征向量去表述这个空间，而找这组特征向量的能力，就是建模的能力。
架构工作的核心是设计
没有软件的计算机，是无法使用的，因为没有办法帮助我们解决任何问题。计算机原本很生硬，无法很柔软的去直接适配所需要解决的问题。
架构的核心工作是设计，设计计算机如何按照预期进行工作。
架构设计中，建模的结果，是模型，它有着结构化、棱角分明的特质，因为这是计算机进行计算的最高效的方式：严格的告诉我们——两个数是相等还是不相等，及其衍生。
正由于严格匹配，所以在很长的一段时间里，解决方案的制定和后续系统的交付运行，都围绕着如何严格按照实际场景进行模拟和落地。 很少以按概率成功对系统的业务功能进行设计和实现，一切都必须绝对正确。因为绝大部分的计算机系统，无法理解自然语意。只能根据人为设计的结构化信息，按部就班地完成重复性劳动。
人工智能、机器学习，在解决自动化建模领域的成熟度还是远远达不到人的能力
，如果达到了，那么软件就不需要人进行架构设计了。简单的从架构设计的结果（当然也是结构化的），生成代码，这方面目前的计算机还是有能力胜任的。
任何不符合实际场景的计算结果，用户都认为是缺陷 ，而在系统中产生此类异常结果，往往需要程序员为此承担相应的责任。呐，回想一下，在没计算机的时代，反而往往都是店小二算错了帐自己赔，没有人会去责怪算盘。
这是为什么，因为算盘足够简单，简单到不需要做任何的监控系统、不需要记录任何的日志，连三下五除二这样的操作规则，都已经被社会化学习消除了使用成本。最终，一切出错的原因只有一个：用键盘的人。
是的，计算机系统生来就是是不可靠的，它不可能像算盘一样在运行期不依赖任何的自然资源。断电了，会引发故障；光纤断了，会引发故障；磁盘满了，会引发故障。。。一系列的不确定因素，导致分布式系统架构设计比主机系统的架构设计复杂的多，原本不需要操心的事情，都需要从更上层的软件层加以解决了。
所以，当前架构工作的很大一块，都随着分布式系统规模的增大而加大了比重。也许，导致世界上最聪明的一伙人都去解决计算机的问题了。
