敏捷团队使用迭代的、需求驱动的、务实的方法来实现IT实施、变更和运行。这些团队的业务范围如果是有限的，效果则很好。这有助于团队以灵活和富有成效的方式执行任务。
但是带来副作用是：增加了生产率和灵活性的同时也增加了相互配合的节拍越来越大。没有软件架构上的指导机制，传统的长期业务目标最终将越来越难实现。例如，允许每个敏捷项目仅根据短期需求选择自己的实现，毫无疑问，这将在整个企业提出的合规性和其他要求方面造成问题。
如何才能使敏捷团队识别并弥合企业业务目标与个人开发计划之间的差距，而又不会失去他们的重点、灵活性和生产力？
约翰·A·扎克曼（John A. Zachman）在80年代中期提出了类似的问题，他最终通过创建所谓的“扎克曼框架”（Zachman Framework）回答了这一问题。
基本上，Zachman框架被定义为一个本体图，它使任何人都可以描述涵盖所有（可能相关的）业务观点的任何设计。今天，Zachman框架提供了整个企业的一目了然的概述。
Zachman图是六乘六矩阵图，在横轴上显示“ 5W1H模型[1] ”。基本上，5W1H模型会强迫您一遍又一遍地问6个问题（什么，如何，哪里，谁，什么时候，为什么），以便对潜在动机有最佳的了解。
在垂直轴上，该图区分了六个不同的（业务）透视图（上下文，概念，逻辑，物理，信息/数据，可用性）。面对这些关键要素中的每一个，都会产生36个观点，在这些观点中，可以描述，解释和正确理解任何给定的设计。下图显示了Zachman框架的图形表示。
令人遗憾的是，对于Zachman框架存在一些误解。最常见的一种方法是将Zachman框架视为一种方法，因此可以将其与诸如TOGAF，IEEE1471或EA 等架构框架进行比较。我认为，这是将方法论（如何实现目标）与本体（如何进行分类）进行比较的错误比较。
另一个误解是Zachman框架不再适用的观念，因此应该忽略。我认为这是一个应该拒绝的概念。Zachman框架中使用的组件没有规定，也没有时间限制。我的猜测是，例如回答：“什么业务模型，为什么我们要实现这些业务目标”将持续很长时间。
Zachman的有效性也得到了各种架构框架的认可，其中Zachman在其工具集中被积极采用。例如，当查看TOGAF “开发体系结构视图”时，您可能会注意到该参考。最终，已经提出了采用行动研究方法，在较小的环境中采用Zachman的新研究建议。
Zachman亲自帮助我计划，观察，反思和挑战设计及其实现。一个很好的例子是在欧洲引入了新的GDPR法规。在不确定从何处开始实施有关隐私以及这将如何影响其业务的新监管要求的地方分配我的客户。在这些情况下，Zachman帮助我指导客户确定受影响的域并讨论它们如何受到影响。
总之，Zachman框架提供了一个参考框架，可以帮助任何规模的组织：指导，组织，关注，跟踪和审查其高级设计工作，并有助于提高团队对更广泛的业务需求的认识。