对那些明白软件架构很好，却不知道如何将其引入项目的人而言，有一个比较常见的问题：
“我理解对软件架构的需要，但我们的团队没有时间实施，因为大家都忙于为项目编码。话虽如此，我们没有一致的解决问题的方法，诸如此类。我们的经理也不会给我们时间做架构。做架构，就没法编码。该怎么引入架构？”
为了理解软件架构对主动思考的需要，有几个问题值得一问。
1.缺乏软件架构造成了哪些问题？
2.缺乏软件架构在将来可能造成哪些问题？
3.这些问题是否有引发更多严重的后果（比如失去声望、业务、客户、收入，等等）的风险？
4.哪些事已经做错了？
有一件事我会告诉刚接触架构角色的人们，他们确实需要专门花一些时间在架构工作（大局的事务）上，但要与日常开发工作之间找到一个平衡。如果你所有时间都用来编码，就做不了架构。另一方面，“软件架构”花太多时间意味着你没写什么代码，可我们都知道漂亮的图表对最终用户毫无用处！
“我们该如何引入软件架构”这类问题没有一个简单的答案，因为它要求软件团队改变工作方式，只有当你完全了解团队的情况，才有可能。一般来讲，团队改变工作方式大致可以分为两类。
1.被动型 ：大多数团队只会在情况变糟的时候改变工作方式。换句话说，当且仅当有诱因时，他们才会改变。诱因可能是失败的系统部署过程中的任何事，或者严重系统故障之类的事情。在这种情况下，他们知道有些事不太对，可能因为管理层让他们日子不好过，他们也知道必须有所行动，改变这种状况。可惜，这种方式在软件行业里占了大多数。
2.主动型 ：有些团队则积极地改进工作方式。即使没有发生什么坏事，他们也能看到改进的空间，防止陷入上面提到的状况。讽刺的是，这些团队往往很优秀，并不需要改变，但他们非常清楚持续改进带来的好处。
回到原来的问题，团队确实想花一些时间在架构上，但并没有得到管理层的认可。也许管理层并没有清楚认识到这样做的好处或者不这样做的后果。无论怎样，团队都没有得到期望的结果。每当我自己处于这种情况时，我会采取以下两种方法之一。
1.以非常清晰和简洁的方式陈述当前的状况，如果不做出改变，会有哪些问题、风险和后果。通常你会向主要决策者、项目资助人或管理层陈述这些内容。一旦他们了解了风险，就能够判断，是否值得为降低风险付出改变行为所需的精力。这要求很娴熟的技巧，有时候也未必被接受，特别是刚接触到一个你觉得不正常的团队。
2.以身作则，发现并解决问题，包括缺乏技术文档、解决问题的方法不一致、架构层过多、不一致的组件配置等。有时候，在所有人了解付出精力得到的回报之前，最初改变的种子就要到位，有点像大多数人第一次看到自动化单元测试时的反应。
每种方法都有各自适用的情况，这取决于很多因素。回到原来的问题，有可能使用了最合适的方法，但要么消息很弱，要么管理层不认为值得花这个钱去降低没有专门“架构时间”的风险。对于这种情况，我会以积极主动、以身作则的姿态引入软件架构。只要找到并修复一个问题（比如多种配置方法，没有高层次文档，混乱的组件结构，等等）。我不是说要放下工具停工几个星期，因为我们都知道，想要说服管理层同意花三个月来重构太困难了。我的意思是，分解问题逐个击破，一步步改变处境。每天花几分钟在这类任务上，在你意识到之前，可能已经有所改观了。“请求原谅比得到许可更容易”。