通常，我们大量从事软件研发的人群面临的软件任务都是为某个领域的企业服务的。也即是企业活动IT化的一部分。那么，企业软件架构的目标是什么？
按照一般性的辨析方法，我们将这个问题分为根本问题（essence）和次要问题（accident）。这里面根本和次要的是相对企业软件的存在合理性前提而言的，不能简单判定次要问题就是不重要问题。
根本问题
把软件当作这个企业生产发展的一项投资的视角，从审视这个软件能够为企业解决什么问题出发。来分析软件需要面临的问题，思考引入了软件后这些问题如何能够更好的解决。从而归纳提炼得到软件核心问题域以及各域之间的联系，决定如何通过IT手段来提供帮助。这是企业软件架构的本质问题。对应于架构方法论，应该是业务架构。
次要问题
次要问题具有一些通用性了，或者说跟通常理解的软件技术更加接近，它们是应用架构、技术架构、信息（数据）架构等等。
重要声明
根本问题之所以根本，是它决定了这个软件是否有存在的必要，以及应该呈现出什么样的轮廓，虽然其是总体上的，但是是精确的。
次要问题只是相对根本问题而言，次要问题同样决定了一款软件的好与坏。
矛盾的业务架构
往往在一个软件团队，尤其是大型团队中，大量的人员从事具体功能开发，看不到业务架构全局，而业务架构涉及的概念基本面上相对容易掌握和理解（毕竟接近现实世界），容易导致团队整体上认为自身已经掌握了“业务”。导致不能对业务架构进行深层次推敲看不到问题域精要从而真正影响了软件内在一致性。这是业务架构“容易”掌握之处，也是认识上的误区。相对于交付的实实在在的眼前困难，业务架构的本质是否掌握显得并不那么紧迫。因此重要不紧急的事情就这样被忽略了。
同时，业务架构因为是真正对问题域的总结和提炼，level相对较高，基本上也只有高级别架构师能够识别精要。这是业务架构的“复杂”本质，但是大部分团队成员并不能很好的认识到。
大量成员过于聚焦次要问题，认为复杂问题简单，这就是业务架构本身的矛盾现状，也是导致一些即使技术精湛的团队始终做不出特别成功的产品的根本原因。同时，一款成功的软件产品往往是业务架构有效承载了企业的IT化本质诉求，团队理解并采用恰当的软件技术实现了这个架构；一言以蔽之，业务与技术实现了良好的结合，这是一款优秀企业软件的气质。
结言
忽略根本问题，等于是向存在意义挑战；忽略次要问题，等于空想。
企业软件架构设计的战术建模两个观点：
充血模型本质上是把数据和逻辑的解耦依靠个人的经验来解决的，好处是代码复用度非常高，领域聚合度非常高，属于企业代码里面的奢侈品；
贫血模型本质上是数据和逻辑的强制解耦，数据是稳定的基础，由经验SE来控制，逻辑相对变化，通过框架等等约束技能一般的团队来完成。是企业代码里面的大规模工业产品。
