架构过于重要，以至于无法放心委托给框架或方法。但别担心:没有方法不是问题，反而恰恰是一种解放。
想在不增加技术负担的情况下降低IT成本?企业架构是一个很好的起点。想要改进业务或者IT集成吗?企业架构有望成为***工具。如何建立一个更精简有效的业务?你应该先看看你打算走向何方。
这其中存在一个矛盾：虽然改善架构可以推动改革，但是本应该帮助您改善公司架构的框架和方法却很少能够兑现其承诺。相反，他们将EA功能转变为象牙塔式的白皮书工厂，过度强调对实际行动进行深度的抽象概念化。
经过30年的努力，为什么失败率依然这么高呢?原因是一些很少有人愿意承认的黑暗秘密。有多么黑暗?出于度量标准的考虑，我将使用Ansel Adams的区域系统，其范围从0(黑色)到XI(白色)。
一言以蔽之：最黑暗的秘密终于将在这里被揭示。
秘密1:EA没有成功的标准
区域系统评级(ZSR): IV
TOGAF是企业架构中***和使用最广泛的方法，因此我们将它用作跟踪对象。如果您不熟悉它，只需要知道TOGAF代表The Open Group Architecture Framework。根据Open Group的说法，“TOGAF®是一个开放的标准，是一个***组织为提高业务效率而使用的经过验证的企业架构方法和框架。”
这就引出了一个问题:TOGAF的权威性是如何被证明的?我在谷歌上搜索“TOGAF成功率”，结果一无所获。据我所知，开放集团或其他任何人甚至都没有定义TOGAF的成功指标，更不用说跟踪其效率了。
秘密2：EA追逐着错误的目标
ZSR：III
TOGAF声称它能提高业务效率。但是，任何拥有一大堆指标的人都知道，“高效”总是一个比率 - 每单位其他事物的单位数，例如每加仑英里数，每服务器处理美元的交易数或每个程序员每小时的故事点数。
“效率”在不知道分子和分母的情况下是没有意义的，而TOGAF既不知道分子也不知道分母。
这不仅仅是语义上的狡辩。当你从事大量交易时，效率很重要，因为明天的市场看起来就像昨天的市场。
大多数企业***都明白，变化是他们唯一不变的东西，这意味着灵活性和适应性不仅仅关系到效率。 TOGAF的瀑布性(下一个黑暗的秘密)使得它在获得灵活性和适应性方面是一个糟糕的选择。
秘密3:EA进行瀑布式的重复操作
ZSR：II
EA框架和方法论经常失败的一个原因是，它们在本质上是瀑布式的。他们通过记录当前状态(一项耗时的工作)，设计理想的未来状态(另一项耗时的工作)，并绘制路线图，以缩小两者之间的差距。
然而，当世界发生变化时，重新绘制所有内容同样耗时。在实践中，这意味着EA的参与根本无法推进业务变革的发展。
它拖累了变革。
秘密4:虽然重要，但EA并不急迫
ZSR：II
假设您是一个企业架构师。了解当前状态、未来状态、差距和路线图——以及一旦公司达到理想的未来状态之后，进行将节省资金的估计——***您将与执行团队(ELT)会面，以获得资金。
祝你好运。在会议召开前和会议结束之后，业务部门领导人还将会见ELT，为他们的项目寻求资金。 ELT将您的请求与其他机会进行比较。 EA优势的兑现总是遥不可及。这是因为它们是在其他业务定义的项目中实现的，这些项目在得到实现之前不能利用改进的体系结构，因而在完成之前无法收获它们的业务收益。
所以，商业项目现在就可以启动，但架构将不得不等待。
猜猜是什么最终能够得到资助——尤其是当ELT能够轻松理解改进的CRM的价值，而你却只会喋喋不休地谈论架构开发框架、无边界的信息流、企业连续体等等时，你连自己都不知道自己在说什么了。通过将上百个专业词汇和首字母缩略词加入他们的词汇表，EA从业人员便以为他们可以加入炫酷俱乐部了。
秘密5:EA框架不能描述真实世界的架构
ZSR:0
TOGAF的基础包含一个基本缺陷：它按照固定的四个层次来描述架构：业务层，应用层，数据层和技术层。这一直是一种过度简化——每个层都有段和子层。
这就引出了两个***最重要的黑暗秘密:
秘密5.1：平台是应用程序 - 应用程序是平台
ZSR：0
TOGAF的分层模型显然是错误的。因为越来越多的平台也是应用程序和应用程序已成为平台。看看SharePoint。您可以将浏览器指向它，并以一种比共享文件夹更复杂的方式管理文件，如果您愿意，还可以创建博客、wiki和其他有趣的东西。
您还可以使用SharePoint作为开发通用应用程序的平台，包括数据输入、工作流、报表等等。它是一个平台也是一个应用程序。
不喜欢这样的例子吗?那再看看SAP?它和它的同伴ERP系统是应用程序 - 非常大的应用程序。构建它们的目的是让您定义自己的数据元素，并使用它们编成您自己的工作流和事务，同时不会破坏它们的结构完整性。
它们既是平台又是应用程序。
你认为这是一个小问题吗?EA的全部目的是让他们准确而一致地描述架构。如果他们不能做到这一点——如果他们不能描述SharePoint和你的ERP套件是如何与你正在运行的或者将要运行的其他东西结合在一起的——那么他们能提供什么价值呢?
秘密号码5.2:丢失的层级。
ZSR：0
平台是应用程序。应用程序是平台。现代IT不仅仅是实施和运行它们。现代IT将它们整合在了一起。
大多数组织将它们与一大堆自定义编程的批处理接口集成在一起，并依赖于被命名为“spiderweb”，“spaghetti”和“hairball”的接口，具体取决于它们的混乱程度。
TOGAF没有地方来描述这些问题，也没有地方来描述像企业服务总线(ESB)这样的更符合体系结构的替代方案。这是不幸的。因为清理一个混乱的集成架构常常是改善架构的***好处。
这很不幸，因为越来越多的IT部门不会仅使用一个底层应用程序作为平台来构建应用程序。 IT使用ESB从一系列“记录系统”中创建虚拟的“数据源”服务。
使用这些服务构建应用程序，而不是直接使用应用程序API，是无法使用TOGAF来描述它们的。
EA的秘诀是:不要给我带来麻烦。带给我解决方案!
ZSR:9
沮丧?不需要。虽然***的架构框架和方法都很混乱，但这并不意味着您必须忍受糟糕的架构。恰恰相反。这里有五个速成提示。
不要让***成为好的敌人
好吧,这不是原创。这也不是伏尔泰的原创作品。你会注意到，聪明的做法是首先实现IX级别的ZSR，而不是XI。规则是:不要试图描述***的未来状态。对更好感到高兴，并让它发生。
尝试询问IT业的任何人。他们知道答案，也很乐意分享。您可以开始改善您的体系结构，而无需记录当前状态或以任何级别的细节描述您的未来状态。
考虑一下敏捷
敏捷不仅仅是一系列应用程序开发方法。这也是一种思考方式。这里特别重要的是与迭代和渐进主义密切相关的想法。因此，当您设定ZSR IX的目标时，请确定您现在可以采取一些小步骤，以使架构更加完善，而不是完整的步骤集，这些步骤将帮助您完成所有任务。
不要与业务项目竞争——而是将架构集成到其中
您现在可以采取哪些小步骤来改善您的体系结构呢?与其与商业项目竞争资金，不如将体系结构改进到可以获得资金的商业项目中。通过这种方式，每个与IT相关的项目都会使架构比其发现的状态更好，只需要适度增加投资和范围。
由于项目发起人不太可能愿意将自己的预算花在更好的企业架构上，所以您应该向ELT展示。只是现在你要求的是为每一个被批准的项目提供架构补贴，而不是单独的资金。
使用设计原则来定义“更好的架构”意味着什么
通过放弃构建一个完整的体系结构的想法，你就可以自由地去理解什么是“更好的体系结构”。通常，它意味着你只需要遵循一系列核心原则。困难的部分不是制定它们。最难的部分是不假装。
例如，几乎每个人都同意消除冗余(规范化)是良好数据架构的标志。尽管如此，你只能假装将这个设计原则作为设计原则，因为像大多数企业一样，IT部门只会在需要时购买，并且只能在必要时进行构建它。事实上，这只是你可能的设计原则之一。
如果你能买就买，只在必要时才构建，那么你就无法避免数据冗余。没关系。不要假装。在多供应商环境中，相应的原则是记录和同步冗余。
避免固定的架构师
好吧，这有点难。你真正想避免的是需要有***人员配置的EA功能。这样做，你将很难阻止它成为一个象牙塔般的白纸工厂。相反，让它成为一个轮换的任务将使它更加稳定，因为每个人在执行任务时都必须遵守规则，否则当他们再次轮换时，将不得不忍受自己造成的后果。
总之
架构很重要。特别是，技术架构很重要。与那些缺乏简洁架构的企业相比，拥有简洁架构的企业更加灵活和有效。
实际上，体系结构太重要了，将它托付给当前的某些框架和方法兹事体大。这虽然很糟糕，但是至今也没有一个方法值得依靠却并不是问题。
这反而是一种解放。
【编辑推荐】
