最近要多带一个架构团队做一个新版本，我写一些基本逻辑来给团队建第一层策略建模，以便我们后面的讨论有基础，由于这种问题是普适的，也不会涉及什么具体的保密问题，所以我公开来写。
架构是一个充满了自由度的工作，是一个最不适合用过去的成功指导下一波策略设计的领域，无论你过去的领域和这个领域有多相像，你过去的成功经验都只能拿来参考，不适合用来拷贝。
因为即使是完全相同的领域，时间已经不同了，行业生态，技术发展已经不同了，你面对的人不同了，业务的瓶颈已经不同了，生态的各个利益体的投资已经不同了，成熟的领域人员可能减少，当初的绩优股可能已经失败，你面对的是一个新的领域，我们做架构，永远不能被过去的“定义”，左右了我们的判断。所以，做新的架构设计，你可以参考过去的成功pattern，但你的分析，必须建立在现在的条件上，不能离开对现在问题的调查，直接打算使用过去的模式。
这是我对我们进行产品战略设计的第一个建议。
架构设计是一个非常微妙的设计领域，它是完全建立在形而上的逻辑上的，它是抽象的，非具象的。但这种抽象必须要以可以实施为底线，否则就沦为纸上谈兵了。所谓高以下为基，贵以贱为本。所以，我们不要出现“架构上我们应该如何如何，但我们现在人力不足啊”这样的思维角度，这是废话，架构就是建立在准备实施这个角度上的，你不能把架构设计和实施隔离，说一堆“我们要如何如何，只是某某条件不成熟。”这样的鬼话，如果某某条件不成熟，你就不该做出这个设计来浪费我们的时间。
架构设计是实施团队的一部分，没有独立于实施的架构设计。架构设计90%的工作是辅助实施团队实施架构战略和挑战架构战略，不是实施之外的独立设计。把人分离出来是为了保证投入，不是为了让这个团队成为实施团队的竞争者。
但反过来说，你不能说我们现在只有多少多少人，我们就做一个基于现在有多少人的方案，因为事情是变化的，在架构设计初期，给你很多的人，你也用不了，人力多了是个累赘，看在财报上每个月花出去的钱就让人害怕，但如果你的设计只是现在有多少人，那后面开始展开了，你根本就发展不了。没有准备，未来有可能给你补人你也接收不了。如果人力不是这样从小到多的一个变化过程，我们也不需要架构设计，架构设计必须可以响应这种人力，资源，市场等各方面的变化。
所以，我们从一开始就做好了做这种多步的策略的打算，考虑整体目标的时候，要用整个市场域的机会作为我们发展的上限，在实施的时候，要考虑好怎么一步步增强投资者和市场的信心，从而可以有序扩大整个业务，不要用“我的架构没有错，错的是市场，错的是人力资源没给够人，错的是……”来给自己做理由。架构设计包括对这些“别人的错”的预判。架构设计和实施是和整个产品的所有其他力量（开发，销售，维护，财务，法务等等）融合在一起的，没有独立于这些开发力量的架构设计。
这是第二个建议。
但对于这个建议，我有个直接的工作技巧可以分享。当我们确切落笔写一个架构设计的时候，要考虑：以客户为目标，以工程为准绳。
什么意思呢？就是说，你在架构设计的第一个部分，要明确说你打算卖一个什么样的东西到市场上去，你的客户打算买你的东西，这个决定的控制要素是什么？有这样一个标准在最前面，我们中间的所有变化，遇到的障碍，我们都知道往哪里绕。也知道我们绕完了，应该继续向什么方向走。
而在你的架构设计的最后一段，你要把你的所有设计落实为“版本”和“项目”。所有的人力管理，都是以项目为基础的，因为项目有确切的目标和人力资源投入，而不是“小李你去帮帮他们”这种尽力而为的东西，架构策略一旦展开，所有人都会面对无限的要求，没有确切的资源分割，凡是长远的东西都会被忽略和放弃。所以，要把架构策略得以实施的希望建立在人力资源管理上，不要建立在“期望”，“正义”，“道德”，“道理”这些依赖上。所谓子非不辨也，老子忙起来谁都不认也。
当然，我这里说的项目，是广义的项目，不一定是你流程中说的那个项目。
而项目，要输出确切的版本，你有硬件，有软件，有插件，这些都是有版本的，不要说什么做一个my-wonderful-app，里面支持这特性，那特性的。
你的软件上了市场，遇到一堆的客户，这些客户的要求都会不一样，你是用一个版本还是用多个版本去响应他们？产品是会有Bug的，是要有新特性开发的，修复Bug和增加新特性是会引入新的Bug的，所以，客户可能可以接纳升级你修复他的Bug的版本，可不一定肯接纳你发布的修复其他人问题的版本的。
这样，你在市场上就会有很多版本，这是天然的，版本一多，开发，测试，维护，管理的成本会大幅上升，这是一个重要的工程控制要素。你用my-wonderful-app这一个概念来考虑你的设计，你实施的时候就会怎么搞怎么不正常，因为你以为你开发的是my-wonderful-app，其实你开发的是my-wonderful-app-v1、my-wonderful_app-v2、my-wonderful-app-v2.1、my-wounderful-app-v2.1-without-tso-llvm_v7_specific-edition……你对人力和项目的预判都是错误的，当然执行不下去了。
所以，很多人其实不明白“开源交付”是个什么东西，开源交付其实是一种减少版本的方法，一个源代码树是可以编译出很多二进制版本的，我给你源代码，编译产生多个版本的的维护成本就是你的了，很多人以为交付源代码是对用户友好，是为行业做贡献——那得看客户是想当你的竞争对手，还是想解决他的问题了。（但即使你用“源代码交付”，如果是商业交付，你的测试还是需要落实到一组二进制版本上的，而且你必须很清楚，这些二进制版本都是会升级的，死版本支持的生态是死的生态）
但无论如何，架构设计一个基本的要求，高以下为基，不要离开你的工程成本想得天花乱坠，只要涉及工程，什么美好想法都得给我从天上掉下来。
第三个建议：调查和设计也是要结合起来的。架构设计初期，我们有无数的“未知”：竞争对手的战略是什么？客户的期望是什么？研究机构有什么新的突破？市场份额的预测是什么？国家政策的走向是什么？……
如果你要调查完这些东西才做决定，你就永远都不用做了。所以，进行架构设计，要勇敢进行“猜”，“预判”，哪怕错了，你也要“猜”，因为这是架构设计工作的基础。你的决策要同时决策：使用猜这个结论和再调查一下，哪个投资收益比更低？然后就要去实施。我在这个专栏中经常强调“守弱”，其本质就是这个：架构本身就是一种猜，我们在猜的基础上执行，如果你非要维护面子，在执行的时候收到当时猜错了的反馈，你死要面子不肯调整，那这个架构执行就失败了。
所以，做架构不能要面子，你眼中只能有产品的最后成功，到成功的时候，你坐在那里，旁边的人说什么，你都可以冷冷看着他，由他讲他的道理，你根本不用在乎。
这样就要提到第四个建议了：你不要指望实施团队会很喜欢你，你做的所有事情，都是为了未来让他们“绕路”走，你的结论他们不会喜欢的。你可以用你所有的个人魅力去尽量soften这种冲突，你可以下去和他们一起分担开发调试的压力，让他们没有那么恨你，但你要知道，如果实施团队很舒服，你的架构设计肯定变成在旁边说胡话了，根本没有设计效果。
所以，你决定来做架构了，就不要期望你有多nice。这是这个工作的特性，不能调和的。不要为了实施团队的一般抱怨就去改变你的设计去迎合，否则产品失败的时候，就没有人跟你抱怨了。吾之所以有大患者，为吾有身，及吾无身，何患之有？你应该多听实施团队的抱怨，但你要分清楚哪些是真正在反馈问题，哪些只是你战略实施的成本。
最后一个建议：架构团队来自不同的领域，不要用“领域代表”看待自己。不要说我只是做芯片设计，我只是做安全的，我只是做内核的，我只是做数据库的。架构团队存在的目的，就是为了设计那些多个模块互相甩锅的Gap，然后所有模块和协同起来，达到最优的效率。你尽然进来架构组了，你就不是某个模块的“甩锅代表”，你就是整个产品。
大部分投资者都是不懂技术的，就算他们来自技术背景，他们对你实施的这个技术也是外行，因为细节只是我们知道，否则他就不用你来做了，他自己做就好了。这些人决策的方式就是“多方确认”。
如果架构组自己都达不成共识，各说各话，那怎么说服投资人（其实包括准备用你的客户），所以，架构组每个人都应该对整个架构策略都很熟悉。我不要求做芯片的人就会写程序，但我需要做芯片的人知道软件部分的构架要求，在解决方案中所处的地位。你不要告诉我你只懂UEFI，不懂Kernel是怎么做的，我需要你知道ACPI表那些信息是给Kernel的哪个模块看的，你不是在做实施，等着别人给要求，你是那个负责知道少给一张EINJ表，Kernel会不会起不来的人。
推广起来说，作为一个产品的架构团队，你也不能只管“我的产品如何如何”，你必须从整个产业生态上开始设计。狼吃羊，羊吃草，你不能说你是狼，不管羊的死活。没有羊了，狼也死了。做架构设计的人，必须知道狼可以吃多少羊，吃到什么时候就要开始收手了。
所以，对于一个产品的架构师，必须知道整个生态链是怎么运作的，要为了整个生态的平衡，不怕把自己部分自己的业务让给其他产品，其他企业，也不怕自己背上别人不肯实施的业务，这样你才会有掌控生态的力量。
大概就是这样一些吧，再往下，就是具体业务怎么做的问题的。但当我们碰到困难的时候，不妨回头来看看我们的总体思路，也许觉得无路走的时候又发现有路了，觉得很顺利的时候，说不定就是危机的开始了。
