在软件和IT领域，我们通常将问题域分解为一个个干净的部件，并分别进行了处理。我们认为，这是处理复杂性的“分而治之”的方法，但是：
“一个系统不仅仅是其各个部分的总和；它是一个不可分割的整体。拆开后，它会失去其基本性能。” ―罗素·阿科夫（Russell Ackoff）
尽管亚里士多德在古代暗示了整体可能大于其一部分的事实，但我们的历史主要是关于通过分解和孤立地研究其元素来理解我们周围的任何事物。至少自科学革命以来，这一直是黄金标准，并且在我们根深蒂固，以至于我们所有人都认为分析是洞察力的唯一途径。
这种方法的成功是毋庸置疑的，通过采用这种简化主义的思想，我们已经取得了所有的创新和进步，但是它建立在一个简单的概念上，即零件可解释整体。
在许多情况下，这种思维方式就足够了，该模型的解释能力足以推动我们前进，但是该模型的实用性与任何模型一样都有其局限性。在某些时候做出的所有简化假设，在种类繁多时假定同质性，还是仅关注某些部分，都将阻碍进一步的发展和更深刻的见解。
复杂性到处都是，特别是在涉及人的任何系统中，例如软件开发，我们都需要更好的工具来处理这些复杂性。
系统思维
系统思维的一个核心思想是在我们的分析方法工具箱中添加综合方法。综合法并不是作为分析法的替代品，而是作为探索可帮助处理复杂性的额外维度。
从某种意义上讲，综合法与分析法的方向相反：它是综合问题，而不是分解问题，然后再解释各个部分并用其来解释整个问题，综合法首先要确定并解释当前所包含的问题，然后看问题如何解决。在哪种环境下并在哪种情况下进行解释。
系统思维从某种意义上说就是：先宽乏再深入。首先进行综合，然后进行分析。
“分析侧重于结构；它揭示了事情是如何工作的。综合注重功能；它揭示了事情为什么如此运转。因此，分析产生知识；综合产生理解。” ―罗素·阿科夫（Russell Ackoff）
在软件和IT领域，我们采用处理复杂性的“分而治之”的方法，但是，在分解的任何层次上，我们首先需要首先了解包含的整体，并了解各个部件在每个层次上的作用、目的和相互联系。部件不仅解释了整体，整体也解释了部件。
在构建新的软件产品时，您需要了解它所包含的上下文，环境是什么，包括客户群，用户个人资料，业务上下文，其目标和目的。您需要获得由内而外的视角 ，只有到那时，您才准备好真正掌握产品必须处理的复杂性，并设计出既适用于目标性，又具有弹性和可持续性的系统。
“每个软件密集型系统都有一个体系结构：一些是故意的；一些是偶然的；大多数是emgent的” ―格雷迪·布赫（Grady Booch）
（参考：康威定律的作者：什么是"涌现"分析建模方法？）
这听起来好像我们必须回到瀑布式设计的前期设计和漫长的交货时间，但是正如系统思维所表明的那样，应该将综合和分析结合起来，并且在这两者之间进行迭代是一个好的方法。最好经常地，缩短学习产品性能的反馈循环。下图摘自Barton和Haslett的论文，很好地说明了这一点。
这样，我们可以将整体自上而下的方法与敏捷设计的自下而上的原理相结合，在其中我们可以尽可能频繁地在综合和分析之间进行迭代。爱德华多·达席尔瓦（Eduardo da Silva）撰写了一篇很棒的文章和演讲，介绍了如何实现此目标：使用社交技术架构发展由技术驱动的组织。