第19章 软件架构咨询师

我的职业生涯大部分都是在IT咨询公司工作，在那里我要么在外包合同下为客户构建软件系统，要么是客户-供应商混合团队的一份子（通常被称为“劳务派遣”）。在咨询的语境中担任软件架构的角色，基本上和在其他语境中是一样的，然而也有一些潜在的问题需要注意。

领域知识

对业务领域的了解必不可少。如果在金融行业工作，对行业内跟你相关的部分（比如，基金管理、投资银行、零售银行等）是如何运作的，你应该有所了解。大部分业务领域都比它们应有的样子更复杂，即使看似简单的领域也会让你吃惊。我记得第一次看到渡轮和酒店领域，就惊讶地发现并不只是预订渡轮座位或酒店房间那么简单。对业务领域的了解可以帮助你更好地理解目标和建立成功的软件产品。

这提出了一个有趣的问题。对业务领域的深厚知识，只来自于在这个领域内长时间的工作，但大多数咨询师跟不同的客户、团队和业务领域打交道是很常见的。因此，期望咨询师们具备深厚的领域知识算公平吗？

我见过一些方法。首先就是把自己的咨询工作限制在单一的业务领域，这样就能获得这个业务领域深入的工作知识。举个例子，我工作过的许多IT咨询机构都专注于投资银行业，它们的咨询师在各个投资银行间游走。这肯定是确保咨询师了解业务领域的一种有效方式，但我不是特别喜欢。向我过去合作过的一些咨询师提供投资银行的外部咨询工作时，他们实际上很生气。在跟其他咨询师做比较时，这些人通常会认为他们深厚的业务领域知识是关键差异或者说独特卖点。

看看我的书架就会发现，我对技术的兴趣远远超过任何业务领域。如果我想在一家银行工作，我会为银行工作，而非咨询机构。因此，我很高兴能定期更换业务领域，这提供了一定程度的变化，很少能在单个领域中工作获得。我也发现观察其他行业如何解决相似问题很有意思，这本身也带来了很多思想碰撞的机会。当然，缺点就是我对任何特定领域的知识都不如在那个业务领域中全职工作的人。

为了防止这一问题，我相信，有一种技能可以让我们能够快速精通一个新的业务领域。这正是我的方法。如果以咨询的身份从事软件架构，你需要敏锐的分析能力来理解业务领域的关键部分，而不陷入分析瘫痪的恶性循环。

权威

软件架构角色需要引入多少控制，取决于和你一起工作的软件开发团队的类型。然而团队通常会提出另一些挑战，特别是如果你以软件架构咨询师的身份和客户的内部开发者团队一起工作。

如果你负责一个软件系统的软件架构和技术交付，就必须有决策权。如果有责任却没有权力，并因此不断为决策寻求许可，那就像是在一条崎岖不平的道路上行驶。

软件架构的角色意味着技术领导力，也就是你要让整个团队朝着同一方向前进。如果你不是一队软件开发者的直接上司，口述指导不太可能很有效。如果你是客户团队的补充，这种情况经常发生。这就是施展软技能的地方，特别是建设关系、建立信任和激励团队相关的软技能。我发现要做一个写代码的实践派架构师，取得成果也要走很长的路。