canonical

   由于各个公司的领域，规模，人员配备等差异很大，形形色色的公司中顶着架构师头衔的诸般人等所从事工作的内容以及所承担的责任也是大相径庭。务虚者有之，务实者也有之, 难以一概而论。甚至关于架构一词的具体含义在不同语境下也是很难达成共识的。然而作为架构师，他应该做什么，能够做什么，却是我在自己的职业生涯中需要加以回答的问题。
    软件公司中的工作大致分为销售，技术，财务，打杂这几类。架构师所从事的工作大致上属于技术这一摊，应该是一种高度专业化的技术工作。在我看来，一般所谓架构师的工作主要是负责设计规范整个软件项目/产品/产品线的整体结构，他所摆弄的是各种相关的技术元素。虽然作为公司的技术利益的代表者，架构师会在某种程度上参与到公司的商业活动中（在某些巨型公司中，架构师甚至可以通过标准规范对整个产业结构施加影响），但是他更多的是接收商业需求将其转化为技术约束，而很少是商业目标的制定者。业务架构方面的设计更理想的是由业务专家进行，这个工作多半只需要技术的常识，而不需要对于技术本身的深刻洞察。在另一方面，虽然架构师对于技术实现所需的技术/人力等资源需求会提出自己的估算和建议，但是他一般并不具备相应的手段和责任来具体管理整个实现过程。因此在我看来架构师的管理职责并不是很大。当然，有些架构师会更加接近商业和管理而远离技术，将他们称之为"资深架构师"可能更加合适。在某些大型系统的建设过程中，总体设计人员可以只负责收集各个子系统的技术要求，汇总后制定整体技术规范，所起的作用类似于协调人员，在这种情况下倒是对技术要求较低而对管理素质要求较高了。
    关于架构的一个有趣的事实是，技术架构本身其实很少存在设计问题。大部分问题只在于业务问题如何分解到既定的技术架构上，一般的技术架构也只是现有技术元素的简单组合而已。所谓的架构设计工作并不是在真正的系统全景下进行，它往往是基于已有经验所作的短暂延伸，是对业内其他类似结构的复制变形。我们所面临的大量问题是选型问题，不是创造性问题，而是选择性问题。架构师最富技巧性的工作不是现在确定什么，做出选择，而是确定现在可以不确定什么，可以将哪些选择延迟。
    在一般人看来，架构师对于系统成败必然起着关键性作用，否则他们凭什么属于“活少钱多”的那伙人呢。但真实情况是，商业上的成败很少是由技术架构直接决定的。因为技术开放和快速传播等原因造成了技术的趋同性，在技术层面上，大多数公司很难依靠技术形成差异化优势。竞争优势主要来源于业务理解和与用户的接触性，来自于历史形成的业务格局。而在中国这样一个营销制导的商业世界中，架构师的工作更难说是在构造某种与众不同的东西。只有少数大公司依靠把握标准才形成技术的话语权，大部分人不过是在技术的大潮中随波逐流罢了。“不求有功，但求无过”应该是架构师基本的工作精神。技术失败最常见的原因除了不够专业以外（在中国，“专业”的标准也许是不同的），就是过于自信，试图去创造些新的结构，或者试图全面应用某种不熟悉的技术。架构建设应该是一个逐步改进的过程，不要激进盲动。
    国内的架构师多数是从高级程序员发展而来，在工作期间多半是学习掌握外部知识，以掌握知识的细节程度和广度为优先。因为总是在别人搭好的平台上活动，即使是参与过众多大型系统的建设，对于系统整体结构一般也没有提炼出自己的认识观点。而有些大学设置了专业，宣传培养架构师，但是实际上缺乏系统的实践训练，学生所学到的多半是高举高打的套路，在实战中的表现往往更差。掌握技术细节和自主的整体性思考对于架构师而言都是不可或缺的。
    虽然创新的技术未必是商业中核心的元素，但是真正的创造性仍然是每一个设计师的希冀。作为一名实践者，我们都在某种程度上期望超越所经历的偶然，达到某种普遍的真理，在外部的物质世界中留下自己的精神烙印。在这种意义下，架构师的工作便不是简单的技术背景或者技术理解可以涵盖的了。我相信，在业务层和基础技术设施之间存在着物理性的厚重的通用技术层，其中存在着大量的结构规律等待我们的探索，这也正是Witrix平台一直努力的方向。