:
毕业后我连续的两个五年计划都和系统架构有关系，第一个是开始从事系统架构相关的工作，第二个是成为一名自己认可的架构师。这第一个目标，我算是实现了，这第二个目标恐怕很难完全得实现，虽然我还有一年多的时间。但是，我完整的职业生涯确实都是围绕着成为一名我自己认可的系统架构师而展开的。心路历程，以后有机会整理回忆录再说吧。
系统架构是一个什么过程。这件事情，在早期的我可能只能去查资料来告诉大家。而我现在，基本形成了我最初的粗浅认知。系统架构，我把它看成一个主谓结构的短语，拆分成系统和架构两个词来看待。
首先是，系统。这是个名字，如何定义这个系统很重要。我将之定义为，围绕一个具体问题的解决方案。这个问题可能不是一个原子问题，即他可能是一系列问题的集合。而我们针对这一系列问题，提出解决方案的落地形式，即为该系统。这样的话，这个系统的构成就会比我们想象的软件系统要复杂的多。因为，首先它就不止包含软件，还包含了使用软件的规章制度，配套的线下流程等等。是帮助用户从现有的现状到预想的解决问题后的状态的整套措施。
其次，是架构。在对架构的理解上，一直都有名词和动词两种含义之争。作为名词，取其框架结构之意。在建筑中，我们都是先搭建起其框架结构，再在框架之中填充充当骨肉的各种结构，逐渐丰满。所以，取框架结构之意其含义也算是对的。另一重含义，动词搭建结构或者搭建构建之意。这就在名词的基础上加入了一些动作的意味，这样一个对愿景或者结果描述的名词，就变成了达成或者说实现这个目标的过程。其实在不同的语境下，强调的重点不同，用的词义就不同。比如说，有人会问我，我们的架构是什么。这时他用的其实是名词的词义，而且根据人的身份的不同，问的层面或者说重点也不相同。但是，这其实是存在不小的问题的。因为，由于提问的人的程度的不同以及，对问题的思考和建设阶段不同，我们对这个问题的名词性的回答其实很难代表其名词性的真实含义。于是就出现了各种各样的问题，所以我们就更倾向于将其视为一个过程。只是，这个含义很难进行沟通，所以有时也会用其当做名词来用。
花了这么大的篇幅来讨论架构的定义。那，什么是架构呢？我可能更愿意对其定义为，对解决方案愿景的落地步骤。这里有些循环定义，因为前面的系统我就说它是个解决方案，这里又说是解决方案愿景的落地步骤。不过，表意应该还是清晰的。
说到解决方案愿景，我们应该怎么来解读这个名词呢？你可以把它想象成架构的名词性的含义。而重点是，这个原型是随着过程的不断深入而被迭代演进的。而过程，就是我们所说的落地步骤。事情，一定是以实实在在落地的东西为推进步骤的，空想必不能取得实质性的进展。而这样形成了实践反馈愿景，再依据愿景调整落地步骤的循环反馈。整个架构就能够得以落地和执行。
说了这么多，其实也没有说什么实际的。针对于以软件为核心的系统解决方案，其范围又都需要涵盖什么呢？关于这个，我读过一些书，也经历了多年的填坑和反思。我觉得，主要是要搞清楚这样几个问题：
- 我们要解决谁的什么问题。这其实是两个问题，但是为什么一起说呢。因为他们相互依存，无法独立看待。
- 怎么解决这些问题。这个看似有些大，但是其实是问题真正的核心。这个问题，可以让我们思考，事情应该是什么样子的。
- 都有哪些可用的手段。理想的解决方案总是会受到现实的限制，但这不是我们要避免的事情，而是要面对的现实，然后承认它们，找到可行的解决方案。
- 现在，问题有了，用户主体有了，解决方案有了，落地方案也有了，那这个方案有什么问题呢？好不好呢？怎么才能解决方案中存在的核心问题呢？这似乎是又一层思考的迭代，是对解决方案提出者的质问，也是对方案本身的验证。
而中间涉及到的知识层面、资源层面、技术层面的问题，不要给自己设限，减少本位思考带来的限制，以开放的思维，顶层的视角，落地的姿态将相关的资源整合协调，将解决方案落地。这是我对做系统架构的认识。
而系统架构师，是主导这一切落地的人，是只有强者才能够胜任的角色。
