在中国的同行中经常看到：要么不重视软件架构，要么过分重视乃至捧为天书。如果要是碰到一个不懂技术的项目经理强行推行新技术有会有何种效果呢？
其实在做系统架构时，有时候会常常忽略以下几点：
1：软件的架构在大的方向上是固定的。
这种固定依据某些基本固定的软件模式（包括设计模式、编码模式或者某些特定的约定）来强化和固定。这使得软件开发在某种程度上具有某些可以明显看得到的风格，这个风格被整个的项目贯穿和坚持，这样当我们进入通常可怕的维护或者调整的时候，我们不会害怕我们在很多种不同的实现中常常迷失了方向。
2：软件的架构在具体的应用中可以适度的可控灵活。
毫无疑问，软件设计开发不可能没有例外，在某种程度上保留一些适度的灵活时必要的。一方面，它符合软件开发的实际；一方面，适度的可控灵活体现了一种对实现者的尊重和信任。然而，如何实现可控的灵活呢？通常，我认为可以考虑有限种类的设计选择并通过有色彩的图形来表明这种可选择性。但即便如此，设计者很重要的要考虑这些不同选择之间的关系，以及这些选择和整体设计的兼容性，这个时候，面向接口的设计和适度的“粘合”设计是必要的。
3：架构设计的支撑。
架构设计通常会涉及到一些支撑设计，这些设计和实现水准直接的体现了系统的最有价值的部分，更细的划分我们应该可以看到性能和结构相关的部分，以及必要的基础类。通常，作为设计人员，我们应该能够设计并实现系统的性能、结构、扩展、粘合等部分的工作，这部分的工作通常不应该离开设计人员的控制和把握，这些代码的书写或者至少积极的关注是设计人员必要的素质：我们不应该让更多的看到我们无法写出代码来（我也反对没有分工什么都做的设计人员！），实际上，这是软件最困难也是最有乐趣的地方。特别是在测试结果中发现这些设计实现带来的性能的极大提高的时候是非常有成就感的事情。至于基础类，应该是尽可能的减少依赖和耦合的。架构设计的支撑要尽可能的对客户程序员隐藏不必要的中间细节，对基础类要尽量简单、稳定并真正需要。
通常，新兴的技术会用在架构设计的支撑设计里面并被封装以隐藏具体的实现，而通盘应用新兴技术的风险是巨大的，并且对人员的获得也是问题。有些技术是可以提供替代技术的，一些新兴的技术实现也是可以参考的（但未必采用她的实现）。要记住软件开发是需要速度、质量、可维护而不是技术表演，这个度应该由分析设计人员负责任的来把握。
4：面向业务还是面向页面的。
也许这种说法会招致一些人的反对，认为自然而然的应该是前者，然而，实际的情况是，我们常常看到打着业务的幌子实现为面向页面的系统，原因很简单：后者更加的“简单”并似乎有更少的代码和工作量。这在某种程度上是对的。然而，区分这两种不同的设计是必要的，尽管你也可能使用了MVC2的架构，但你可以做出面向页面的设计的。观察我们的软件开发，最先提交的代码未必是最少的代价的代码：我们常常可以发现一些项目总是在那些不起眼的地方不断的“修改”，我们的程序员因此好像很忙，但对我们的项目对公司来说这是糟糕的不必要开销。因此，考虑这两种可能的情况，在做出选择之前加以思考是必要的。
5：用团队和别人的眼光考虑问题。
实际上，每个项目都是有所差异的，特别是人的差异。很糟糕的是，我们通常不得不面对人力资源的极大压力，特别是这些人之间常常都没有共事的经验也就是常常是临时组成的，而这些人员也通常也缺乏一个软件开发的基本共识：对标准的遵从哪怕是最简单的Java编码规范和对自己提交的产品的简单备注和测试都是缺乏的而通常又没有达到代码就是文档的水准。在这个时候，用团队和别人的眼光考虑问题就是必要的，这实际上就是取技术上的“交集”，也就是走简单的路线。如果没有选择的时候，培训工作就是非常必要的。
用团队和别人的眼光考虑问题也会有其它的问题，特别是当项目压力如进度压力等来临的时候或者项目成员根本不考虑公司整体和长期利益的时候，这个问题很突出，有时候作为分析设计人员你甚至很难解决，特别是你面临刚才我所提到的“没有Java开发实际经验甚至缺乏软件开发经验的项目经理试图控制技术的时候”更加如此。
软件架构的设计说起来简单，也可以说起来复杂，然而，如何把事情做到简单并且把其中的针对性能、分层、粘合、扩展等处理好，并提供可控的灵活性不是容易的。通常，只有多一些经验和教训并能够在软件代码上加以实现核心的才可能成为好的分析设计人员。