我是一名架构师。我设计系统。我专注于返回值。我不断地学习。
在我设计系统时，我不断寻求了解如何使该系统变得更好，或者至少我可以发现哪些要点可以使下一个解决方案变得更好。通常这些不是技术问题——技术是简单的部分——而是本质上更广泛的问题。有时他们在本质上更个人化，比如努力成为更好的沟通者。作为一个内向的人，我敏锐地意识到我的这个弱点。
An Archimate-based Metamodel is a metacognitive tool to visual a complex technology ecosystem.
这些更广泛的担忧是什么？那么如何改进技术交付平台以使其更好地满足业务需求。这些问题通常属于企业架构 (EA) 领域。什么是企业架构？这是一个有很多答案的问题。对我来说，它是跨业务和 IT 协调资源以确保 IT 资产的战略交付的纪律。
在我多年的咨询和创建系统中，企业架构是我看到几乎每个组织都重复出现的一个失败领域。为什么呢？出于多种原因。但主要是因为大多数组织中不存在企业架构的实践。当它被实践时，它被错误地实践或定义为企业级的解决方案架构。我看到的主要错误是：
- 业务不是企业架构的一个元素——EA 的一个主要部分是确保交付业务价值。大多数高管（来自业务或 IT 方面）都不愿意让 IT 进入业务领域。墙仍然存在，我相信将企业架构围在 IT 领域会阻碍 IT 将两者结合起来的能力。
- 感知到的需求就在当下——要做的事情太多了，EA 只是分散了在接下来的几周或几个月内交付软件的注意力。短期思维对于随着时间的推移提高性能或确保您交付业务实际需要的东西没有任何作用。交付的最低价值组件意味着没有交付价值更高的组件，从而降低了 IT 输出实现的价值。
- C 级套件的狂妄自大——世界各地的 CTO、CIO、CFO、COO 和 CEO 都有过成功的职业生涯。大多数人的外表和身高都高于平均水平。他们通过他们的能力和他们的能力达到了他们所在的位置。他们对自己的能力过于自信，因此不愿意支持可能挑战他们非结构化信念的结构化技术。EA 利用元认知工具来构建分析并帮助为有效决策提供信息。
- 过度使用 EA — 最受欢迎的 EA 框架是 TOGAF。这是一个复杂而雄心勃勃的框架，有很多行话。TOGAF 已经过时，源于瀑布思维。在敏捷的世界中，它适合哪里？好吧，有很多东西可以带走，也有很多东西可以留下。EA 本身不应该是一个目标。努力应该集中在为组织带来价值上，尽可能地轻量化和自动化。
如何避免这些错误并有效执行 EA？它是通过使用数据和元认知工具来塑造您分析复杂系统的方式，并结合不懈地敲响为技术执行提供指导的原则。它还需要不懈地关注回报价值。
将来，我将撰写更多关于企业架构以及如何将其引入您的组织的文章。如果您有任何问题或意见，请告诉我。我喜欢反馈！
