构建软件的时候，我们经常碰到一些技术相关的约束，特别是在大型组织里。
- 批准的技术清单 ：许多大型组织都有一个允许用于构建软件系统的技术清单，目的是限制组织必须支持，运行，维护和购买许可证的技术。如果你想使用任何不在清单上的技术，通常有一个漫长的例外流程，需要提出正式的申请。然而，我仍看到有团队为了能在Java项目中使用Groovy或者Scala而偷偷引入额外的JAR文件！
- 现有系统的互操作性 ：在大多数组织中，你的软件需要整合已有的系统，而实现整合的手段往往非常有限。除此之外，就是别的系统需要和你构建的系统整合。在这些情况下，你可能会发现，组织性的约束规定了你可以用于整合的协议和技术。一些我合作过的投资银行就有他们自己内部用来在软件系统间交换交易信息的XML结构。我可不会用“简洁”和“易用”来描述它们！
- 目标部署平台 ：构建一个全新的软件系统时，目标部署平台通常是影响技术决策的主要因素之一。这包括嵌入式设备、微软的Windows或Linux服务器的可用性，以及云。是的，即使这个我们称为云的神奇的东西，也有约束。举个例子，每个“平台即服务”（PaaS）提供的都不同，对某些东西，比如本地磁盘操作，你的软件能做什么，不能做什么，大多数都有限制。如果你不明白这些约束，部署时，陪伴你的很可能是焦虑的返工。
- 技术成熟度 ：有些组织乐于采用有风险的尖端技术，拥抱这种进步带来的风险。其他组织本质上则保守得多。
- 开放源代码 ：同样的，有些组织仍然不喜欢使用开源项目，除非它跟IBM或微软这样的名字扯上关系。我曾经在一个高街银行1 的项目中工作，该银行拒绝使用开源项目，却乐于使用来自一个非常著名的技术品牌的Web服务器。那是伪装过的开源Apache Web服务器。这样的组织在遇到问题的时候就喜欢冲人大喊大叫。开源许可证的混乱也阻碍了一些组织完全采用开源项目。如果你曾试图解释GPL和LGPL的区别，可能已经目睹过这种情况。
- 供应商“关系” ：就像生活中的很多事情，不是你知道什么，而是你认识谁。很多合作关系仍然是供应商请CTO（Chief Technology Officer，首席技术官）吃喝玩乐，在高尔夫球场上“达成”的。如果你曾为大型组织工作，也好奇为什么你的团队被迫使用一些明显不合格的东西，原因可能就是这个！
- 过去的失败 ：2000年前后，我带着用Java RMI——一种允许通过Java虚拟机进行远程方法调用的技术——构建解决方案的提案走进一家银行。我遇到了很大的阻力，因为这家银行已经“尝试过它，不管用”。那个设计到此为止，任何讨论都没能改变他们的主意。由于过去的失败，Java RMI在这样的环境下被封杀。最终我们转而构建了一个框架，通过HTTP将序列化的Java对象传给一群Java Servlets（变相重新发明轮子）。
- 内部知识产权 ：当你需要找到一个库或框架来解决所面临的问题，很可能已经有符合你需要的开源或商业产品。然而对有些人来说这还不够好，你必须使用组织自己内部的日志库、持久化框架或通信基础设施服务。这种情况并不罕见，不管它们是否真能正常工作。最近我听说一个组织构建了自己的CORBA2 实现。
1 一般而言，各大城市都有一条或者数条商业大街（high street），街上遍布各种银行、商店、邮局、警察局、超市、快餐店等。在英国，位于这类街上的银行被称为“高街银行”（high street bank），主要是提供便民服务，也称为“零售银行”。因此这类银行允许的贷款额度就比较小。——译者注
2 Common Object Request Broker Architecture，通用对象请求代理架构，是由OMG（Object Management Group，对象管理组织）定义的标准，旨在促进部署于不同平台的系统间通信。——译者注