关于架构师的一点思考

架构，是一个很高大上的名字。

但对于真正去做架构的人来说，确是一个很繁琐很屌丝的日常。

从来没有一个架构能一劳永逸一直服务于某个产品，除非这个产品已死。

在IT与CT不断融合的今天 （其实IT与CT的融合早已经开始，只不过开始是精神上的共享交流，如今是肉体上的替代和结合），做通信软件和互联网软件在本质上已经没有太多的区别，只不过由于最终用户的不同，在具体的实现/流程/发布等等环节有所差异，而间接的造成了不同的技术侧重和选型（妥协）。而正是由于这一点的差异使得通信软件略显保守，通信架构师显得不那么“时髦”和“激进”。

作为一个在通信行业干了N年的老兵，一个“老”的架构师来说，面对如今IT特别是互联网如火如荼的架构演进厮杀的红海，该何去何从呢？

首先，需要回答一个最基本的问题，什么是架构呢？

在回答这个问题之前需要回答另外一个更基本的问题，什么是软件？在我看来，软件就是一种用来解决某种特定问题的一个工具和方法。软件设计人员就是来制造这种工具的人，而架构则就是这个工具的设计图。

打过凯撒大帝或者模拟城市的人都知道，在建造一个城市之前，一个好的游戏人员都会考虑很多的规划，哪里用来作为工业区，哪里用来作为商业，哪里用来作居民区，水管怎么排，公共建筑放哪里，等等等等。其实这就是一个城市的架构设计。

软件架构也如此，在设计软件之初，我们就需要充分的了解我们的软件是干什么的，被谁干的，用户的兴趣点在哪，用户的痛点在哪。知道这些之后，我们就需要进行业务的模型化和抽象，进行逻辑上的架构设计和接口定义，然后细化到具体的实现层次的技术选择和架构设计和实现。

等等，这里提到了逻辑上的架构设计和实现层次的架构设计，why（what）？

是的，在我看来，架构事实上是有不同层次的，对于一个大的软件系统来说，一个high level的架构设计更倾向于逻辑的考虑，在这个层次更多考虑的是业务的逻辑，比如我这个系统要分成几个模块/服务，每个模块的特点（有无状态，扩展性等），之间的接口和业务调用流程，可能的瓶颈，对老系统的兼容要求，等等。

其次是实现层次的架构设计，在定义了逻辑的架构后，我们需要对不同的模块的实现进行设计，基于不同的模块的特点选择不同的实现方式（包括选择什么框架，语言，部署方式等）

架构就是业务逻辑在现实的投影！

当然，在实际的操作中，往往我们并不会严格的划分不同层次的架构设计，更多的会“agile”的方式先进性一个粗略的high level设计，然后在实际的架构设计过程中又同时反馈一些业务/技术的细节而对high level的架构进行优化重构。

现实中有更多的复杂性，不同的stakeholder会有不同的要求，而且很多时候是对老的系统的重构或扩展，需要考虑对老系统以及周边系统的兼容，因此要设计一个好的架构并不是那么容易的事情。

那么就到了第二个问题，什么是好的架构。

什么样的架构是个好架构？

一个好的架构，在我看来，就是适合当前的业务，能很好的解决当前的业务并且能不需要伤筋动骨就能解决未来N年新业务的一种设计。

就像前面什么是架构提到的，一个好的架构必然对于业务的理解非常的透彻，能够把不同的业务放到应该的模块中去实现，而且在每个不同的实现都基于业务的特点采取了比较适合的技术手段。

说来容易，但事实是很难去评判的。不同的人对于业务对于需求都有不同的理解，对于未来的业务需求也有不同的假设，对于不同的技术实现都有不同的见解和偏好，而业务本身有其不确定性，技术也有其优缺点，因此一个“好”的架构永远都不能是最优的，套用一句话，没有最好，只有更好！

而架构师面对这种情况，该如何设计一个“好”的架构呢？

在我看来，首先架构师要对现有的业务非常熟悉，对于不同的未来业务可能性有一定的理解，然后对于现有的系统有充分的了解，能广泛的和不同的人员进行沟通，在自己的心目中要形成一个high level的架构设计，能完美解决现有问题并有可扩展性。然后基于此架构再结合实际的情况和不同的stakeholder的要求设计一个“balanced”的架构。

是的，balance！架构设计不是仙女，不能不食人间烟火，很多时候我们都需要妥协和调整，不能去追求更好和最好，往往能够“刚刚好”才是”好“。

什么是架构师的核心竞争力呢？

或许每个公司，每个部门对于架构师的要求都不一样，而我们每个人也许一生都会在不同的公司和产品间切换。

不管是哪种情况，一般来说，架构师都是从软件开发人员不断的成长起来的，很难想象一个没有经过真正的coding熏（折）陶（磨）过的人如何能够成为架构师。

那么什么才是一个架构师的核心竞争力呢？怎样评价一个架构师是一个好的架构师呢？

在我看来，架构师有“硬”和“软”的两方面的竞争力。

硬的一面说来，就是架构师对于业务的熟悉程度，对于技术的熟悉程度，对于软件工程的理解和经验。

我们很多时候评价一个架构师都会去看他/她对于技术是否熟悉，是否用过各种框架和各种开源的软件，然后做过什么项目，因为这些方面的确是比较容易评价的，特别是对于面试来说，也最看重这些，而至于架构师对于原来的业务的理解往往并不那么受到重视。而在我看来，也许对于一般的开发人员来说，技术的熟练程度是很重要的，但对于架构师来说，最最重要的是他对于业务的熟悉程度，或者说，他/她对于业务的逻辑分析模块化等high level架构设计的能力。一个架构师能够在纷繁复杂的业务中精锐的把握主线抽象业务/接口的能力以及经验应该是核心的竞争力之一了。

IT行业发展变化很快，毫无疑问，对于技术特别是新技术的理解和热爱不可或缺，只有对各种技术框架都了解了才有可能选择最适合的架构。因此对技术的掌握和快速学习能力是另一个核心的竞争力。

软的一面说来，架构师需要和不同的stakeholder进行沟通。沟通能力，表达能力，合作精神都不可或缺，最重要的一点，架构师要能在不同的压力下，坚持必须坚持的，妥协可以妥协的，并让不同的部门人员能理解与配合，为同一个目标协作开发。不追求最好，但面向最好，使事情发生，“平衡”之道也是非常重要的一个技能。

所以总结来说，一个架构师的核心竞争力在于：

    快速的学习能力（业务和技术）

    强大的业务分析，抽象，模型能力和经验

    善于沟通的成熟的合作能力

最后，“老”架构师该如何成长？

一般来说，老的架构师都有着比较丰富的实际架构设计经验，对于架构设计的方方面面都有了一定的了解，但并不是每个架构师都有机会尝试不同的产品，甚至有些架构师十年如一日的在同一个产品上开发新的功能，只是对系统的架构做一些小的改进。对于方兴未艾的技术来说可尝试的机会并不多，那么这些“老”架构师（包括本人）该如何拥抱新的世界，如何继续成长呢？

热情，对于技术的热情永远是第一位的，失去了激情我们就真的老了。

所幸我们生活在一个开放的信息时代（我们自己参与造就的信息时代），信息的分享让我们能有更多的机会去了解其他的架构师们在做什么，业界新的技术有什么，各种不同的渠道（论坛，峰会）我们要积极的参与进去，结合自己的经验吸收不同的养分构建自己的知识库。

同时把我们的双手从ppt中解放出来，抽一些时间玩玩coding，玩玩docker，保持一个程序员的本色。

---------------------------

键者（古人用笔故称笔者，今人用键盘故称键者）主要从事通信BSS/OSS以及Media相关的软件设计开发，从业16载，突有小感，或无聊或浅薄或偏激或井蛙，权当灌水一篇。