Question

不管别人怎么说，软件架构都不是一个“后技术”或者“非技术”的工种。在白板上画一堆框、线和云，交出这种“软件设计”，可不是软件构架师所为。

进一步的技术能力

“T”指的是技术，这也正是优秀的软件构架师应该懂得的。作为软件开发者，我们倾向于去搞懂编程语言语法、API、框架、设计模式、自动化单元测试和其他所有日常使用的底层技术。对一个软件构架师来说，这些也是基础知识。为什么？因为扮演软件构架角色的人要懂技术，这样他们至少能如实回答以下类型的问题。

该方案是否有效？

我们要这样去构建吗？

然而，从熟练掌握不同编程语言的学习曲线来看，软件专业人员常常只精通一到两项技术。最后，这些人都会被叫作“Java开发者”、“Oracle开发者”什么的。我本人曾是如此，也在很多组织中目睹这种情况。如果你还对编程语言的宗教战争感到困惑，看看有多少这样的前缀吧。

尽管我们努力保持开放的思维，但还是受困于单一的技术栈。其实这也没什么错，但你不得不小心地保持开放思维。俗话说，“如果你只有一把锤子，一切看起来都像钉子”。获得经验是学习之旅的重要组成部分，但不要被经验束缚。比如说，并不是每个软件都需要一个关系型数据库，但在团队勾画候选的软件架构时，往往第一个就会画它。

知识面宽

这让我想谈谈为什么技术知识面宽对软件构架师来说也很重要。当然，他们可能是Java或者Oracle专家，但软件构架角色的要求更高。例如，他们要能够回答以下类型的问题。

和其他可选技术相比，我们所选的是否最合适？

对该系统的设计和构建，还有哪些选择？

是否应该采用一种通用的架构模式？

我们是否明白所做决策的利弊？

我们照顾到了品质属性的需求吗？

如何证明这种架构行之有效？

软件架构师是通才型专家

我所知大部分最优秀的软件设计师都有软件开发背景。这并不意味着他们是团队中最好的程序员，但他们能够在底层细节和大局之间切换。他们还有着深厚的技术积累，以及从多年软件构建的经验中获得的广阔的知识面。但他们不能（也不会）总是知道一切。再加上也很难找到一个只使用单一技术栈的软件系统。我在职业生涯中，见过一些采用混杂技术栈的系统，包括：

针对多个Oracle数据库的微软.NET桌面客户端；

通过一组Java EE网络服务从Oracle数据库拉取数据的微软ASP.NET网站；

从Java编写的REST服务拉取数据的iOS和Android移动应用；

用微软.NET或Ruby编写的多个服务构成的微服务架构；

从微软Dynamics CRM系统拉取数据的微软ASP.NET网站；

通过微软.NET/Windows通信基础服务拉取数据的微软SharePoint网站；

与SAP集成的Java EE 网络应用程序；

……。

虽然一般性的设计知识、技巧、模式和方法通常适用于许多不同的技术，但不明白如何将其成功应用在底层细节上可能会导致问题。这是否意味着对任何特定软件系统中使用的所有技术，软件架构师都应该是专家？不，合作才是关键。找到那些知你所不知的人，与他们紧密合作。没有谁说软件构架的角色不能分享，而且欣然认识到你的知识差距往往是创造更和谐的工作环境的第一步。结对编程有好处，那么为什么不能结对架构？

软件架构是技术活

支撑软件架构角色的技术知识需要深度与广度并存的知识组合。如果设计软件、画架构图的人回答不了该架构是否行之有效，那他们可能不是这项工作的正确人选。软件架构绝对是一个技术工种，但光有技术还不够，良好的软技能也至关重要。